寫代碼不免出點bug，沒有人可以保證自己寫的代碼不出問題，而那些沒有被挖掘出來的bug，便成了后來者哭笑不得的坑...

這段時間公司全面 https 改造，涉及到域名的遷移，域名的遷移不是 nginx 做個映射就完事兒了，還有各種代碼的去 schema，各種組件的搬遷，算是一個大手術！我看最近百度主站也升級到了 https，期間應該出過一次問題吧，貌似回滾了一次，他們遇到的坑應該還不算多，只是 www 域升級，而不是全網。公司最近出了不少的問題，大小問題都有，表面看是前人挖的坑，實際是整體架構思考的有欠缺。

當我們放下一個項目轉投下一個時，手頭的東西就要轉交給他人處理，或者..不再有人處理，可代碼還在那里，搞不好你就引用了別人的東西，保不準哪天別人的代碼里就爆出了個大 bug，當然這里的“別人”也可能是 你！我們既不希望自己是受害者，更不希望自己是施害者。

1. 如何挖坑

挖坑可不是一件簡單的事情，你寫出來的插件、組件、代碼，很可能被很多人用到了，各種業務場景下狂奔你的代碼，一堆測試人員檢測你的bug，所以在項目中埋坑可不是一件容易的事情。

那么如何埋坑呢？可以參考以下方案：

• 在一個文件中放一坨很長很長的代碼，不加注釋，不解耦程序
• 把判斷都放在一層嵌一層深深的邏輯里頭
• 程序中臨時加入幾個全局的標記變量，在很多地方改變變量的值，在很多地方使用變量的值
• 不考慮多變的場景，不實時容錯，讓他按照你腦子的軌跡跑
• 到處散播不同版本的代碼，不整理統一的文檔

如果這些方案還不夠你挖坑，我想你團隊同學的技術水平也真真是太高了。

很多時候，我們都是不經意間留下了隱患。當自己寫的東西被其他人使用后，程序需要兼顧的場景就會增多，出現的問題也會變多，這個時候我們不得不完善自己的代碼邏輯。結果就是，邏輯耦合度高了不少，代碼層次深了不少，出錯的概率也就增加了不少。

所以在設計一個功能或者組件的時候，該考慮什么，不該考慮什么，一定要理清楚。并不是所有東西都適合往代碼里加，我們不是在做 ExtJS 這個整體方案，也不是編織一個底層的操作庫，只是用少量的邏輯整合離散化、個性化的業務，這些邏輯越少越好，與核心邏輯無關的內容就必須抽離出來！

2. 使勁踩坑

如果說挖坑是一件很有難度的活兒，那踩坑就更難了。其實可以說難的不是踩坑，而是發現自己踩坑了。

在一堆巨量的文件中找出「因把等于號寫成恒等號」造成的 bug，這不是輕松的事情，可能你在 debugger 的時候進入了別人的代碼領域，對著別人巨長而又沒什么注釋的代碼，估計當場就暈了，更暈的是，自己卻還在懷疑這到底是不是這堆代碼里頭的問題。團隊合作中，我們心里默認相信隊友，隊友產出的代碼是沒有問題可以直接拿過來使用的，所以一旦出現問題，我們懷疑更多的是自己，質疑別人需要很大的勇氣，尤其是質疑那些成熟的框架，用了很多年的代碼。

那么如何踩坑呢？我們可不喜歡踩坑，有的坑踩進去就跳不出來了，***只能選擇其他方案處理。很少有前端同學寫程序的測試用例，可能還有一部分同學根本就沒聽說過什么測試用例。而在后端中（比如nodejs）沒有測試用例的代碼就是一堆廢代碼，除了自己可以拿著用用，別人根本就不敢用的。那么測試用例會考慮做那些事情呢？簡單點說：

• 寫出有問題的代碼，讓程序按照期望的出錯方式出錯，如果沒有，程序就有bug
• 寫出沒問題的代碼，讓程序按照正常的流程返回正確的結果，如果沒有，程序就有bug

測試用例要覆蓋到程序中所有的邏輯判斷，比如 if elseif else 等判斷的邏輯都要覆蓋進去。當我們的測試代碼覆蓋了100%的邏輯，那坑位就展露無遺了。

埋坑人的致命弱點就是很少對程序作出異常情況判斷，只要找出程序中的異常點，試圖以另類的方式觸發這個異常，你就順利踩坑了！

3. 用力填坑

首先，填坑是一種責任。

發現問題是最難的，解決問題只是時間的問題。當我們確認了一個坑之后，***件事情就是告訴別人這里有坑，你不要踩了。但是***再多補一句話：你先別踩，等我填好了坑你再來。我這覺得這句話真的很暖人心，程序猿之間的關懷就應該這么赤裸裸的。盡管，有的時候，這個坑不是你挖的..

當我們挖好坑，踩完坑，再埋好坑之后，回頭想想自己在團隊中扮演什么樣的角色，挖坑者還是埋坑者？這必然是有益于成長的。