大家好，我是前端西瓜哥。
相信大家有經常遇到這樣的情況，測試給你分配了一個 bug，但你發現 bug 涉及的模組並不是自己負責的，然後你就要選擇修還是轉給其他同事。
該怎麼做呢？我們不妨好好思考一下，以後遇到的時候就能快速做出選擇。
簡單的直接修了
先簡單看看 Bug 描述，簡單的直接修了。比如一些樣式、文案問題，簡單的邏輯問題。
對於我這種純前端來說，這種通常透過開發者工具從 DOM 元素的類名出發，在專案程式碼中搜索定位到相關的程式碼位置。
通常快速看一遍程式碼邏輯就能理解，修起來很快。這種小問題順手修了就行。
比較複雜，就要考慮一下
因為你不熟悉，修起來費勁，還可能引入其他的 bug。
如何判斷 bug 是否複雜？
首先看描述，描述涉及到你完全沒摸過並且是比較複雜的模組，那大概就不好修。它可能需要開發先了解這個模組的一些底層知識，有一定的概念，也就是需要門檻。
當然這只是初步的判斷，你還可以稍微看一下相關的程式碼實現，看個十幾二十分鐘，看看能不能梳理出邏輯。如果不能，就可以考慮把這個 bug 轉出去了。
當然如果你有空，也對這個模組感興趣，bug 也不緊急，也可以多花點時間去修復的，能對這個模組有更深的理解，對整個軟體架構能有更好的認識。
bug 轉給誰？
轉 bug 的一個老大難問題，就是這個模組是誰負責的，該轉給誰
。
在軟體很複雜的時候，團隊成員負責的模組可能很多很雜，可能多個同事都做過同一個模組的不同方面，這種情況下，找對應的開發也是難事。
這種時候我的做法是，根據平時開發的提交、效果演示大概確定大概是誰負責的，然後悄咪咪將負責人改為他。
你可以選擇是否再和他私聊說一下，這個看你。
因為你和他說這個，他可能會不高興，因為技術通常很討厭別人說自己有個 bug，也有人不在意，比較和善。有些人半天都是未讀，就比較煩，因為你老是惦記這件事，就不能很好地專注其他的事情。
可能那個同事跟你說他也不負責這個模組，你就和他討論下這個是誰負責的，不行再找找測試問問，然後丟出去。實在不行就在群裡問一下。具體操作主要看你們團隊的氛圍，團隊成員的風格。
我是經常試過在群裡詢問然後沒人回答的，所以不喜歡在群裡討論一些問題，都挺內向的哈。
有時候是負責該模組的同事忙著做其他的事情，所以跑到你手上的
。
這個就可能需要負責該模組同事的協助了，讓他說明一些業務背景，提供一些相關文件，好讓自己比較快速地理解該模組。
結尾
bug 這種東西，有時候確實不好劃分歸屬，導致一些週轉的消耗。
或者可以用一個樹狀圖來標識每個開發同事負責的模組，但也是比較粗粒度，因為模組其實還可能做劃分，而且負責的模組可能是變化的，有些負責模組的早期開發，後來被幾乎重寫，後面又去開發了其他模組，又沒有及時更新。
各位如果有什麼想法和問題，歡迎在評論區留言討論一番。
我是前端西瓜哥，多年前端開發經驗，歡迎關注我。
