這段時間公司全面 https 改造，涉及到域名的遷移，域名的遷移不是 nginx 做個對映就完事兒了，還有各種程式碼的去 schema，各種元件的搬遷，算是一個大手術！我看最近百度主站也升級到了 https，期間應該出過一次問題吧，貌似回滾了一次，他們遇到的坑應該還不算多，只是 www 域升級，而不是全網。公司最近出了不少的問題，大小問題都有，表面看是前人挖的坑，實際是整體架構思考的有欠缺。
當我們放下一個專案轉投下一個時，手頭的東西就要轉交給他人處理，或者..不再有人處理，可程式碼還在那裡，搞不好你就引用了別人的東西，保不準哪天別人的程式碼裡就爆出了個大 bug，當然這裡的“別人”也可能是 你！我們既不希望自己是受害者，更不希望自己是施害者。
1. 如何挖坑
挖坑可不是一件簡單的事情，你寫出來的外掛、元件、程式碼，很可能被很多人用到了，各種業務場景下狂奔你的程式碼，一堆測試人員檢測你的bug，所以在專案中埋坑可不是一件容易的事情。
那麼如何埋坑呢？可以參考以下方案：
- 在一個檔案中放一坨很長很長的程式碼，不加註釋，不解耦程式
- 把判斷都放在一層嵌一層深深的邏輯裡頭
- 程式中臨時加入幾個全域性的標記變數，在很多地方改變變數的值，在很多地方使用變數的值
- 不考慮多變的場景，不實時容錯，讓他按照你腦子的軌跡跑
- 到處散播不同版本的程式碼，不整理統一的文件
如果這些方案還不夠你挖坑，我想你團隊同學的技術水平也真真是太高了。
很多時候，我們都是不經意間留下了隱患。當自己寫的東西被其他人使用後，程式需要兼顧的場景就會增多，出現的問題也會變多，這個時候我們不得不完善自己的程式碼邏輯。結果就是，邏輯耦合度高了不少，程式碼層次深了不少，出錯的概率也就增加了不少。
所以在設計一個功能或者元件的時候，該考慮什麼，不該考慮什麼，一定要理清楚。並不是所有東西都適合往程式碼里加，我們不是在做 ExtJS 這個整體方案，也不是編織一個底層的操作庫，只是用少量的邏輯整合離散化、個性化的業務，這些邏輯越少越好，與核心邏輯無關的內容就必須抽離出來！
2. 使勁踩坑
如果說挖坑是一件很有難度的活兒，那踩坑就更難了。其實可以說難的不是踩坑，而是發現自己踩坑了。
在一堆巨量的檔案中找出「因把等於號寫成恆等號」造成的 bug，這不是輕鬆的事情，可能你在 debugger 的時候進入了別人的程式碼領域，對著別人巨長而又沒什麼註釋的程式碼，估計當場就暈了，更暈的是，自己卻還在懷疑這到底是不是這堆程式碼裡頭的問題。團隊合作中，我們心裡預設相信隊友，隊友產出的程式碼是沒有問題可以直接拿過來使用的，所以一旦出現問題，我們懷疑更多的是自己，質疑別人需要很大的勇氣，尤其是質疑那些成熟的框架，用了很多年的程式碼。
那麼如何踩坑呢？我們可不喜歡踩坑，有的坑踩進去就跳不出來了，最後只能選擇其他方案處理。很少有前端同學寫程式的測試用例，可能還有一部分同學根本就沒聽說過什麼測試用例。而在後端中（比如nodejs）沒有測試用例的程式碼就是一堆廢程式碼，除了自己可以拿著用用，別人根本就不敢用的。那麼測試用例會考慮做那些事情呢？簡單點說：
- 寫出有問題的程式碼，讓程式按照期望的出錯方式出錯，如果沒有，程式就有bug
- 寫出沒問題的程式碼，讓程式按照正常的流程返回正確的結果，如果沒有，程式就有bug
測試用例要覆蓋到程式中所有的邏輯判斷，比如 if elseif else 等判斷的邏輯都要覆蓋進去。當我們的測試程式碼覆蓋了100%的邏輯，那坑位就展露無遺了。
埋坑人的致命弱點就是很少對程式作出異常情況判斷，只要找出程式中的異常點，試圖以另類的方式觸發這個異常，你就順利踩坑了！
3. 用力填坑
首先，填坑是一種責任。
發現問題是最難的，解決問題只是時間的問題。當我們確認了一個坑之後，第一件事情就是告訴別人這裡有坑，你不要踩了。但是最好再多補一句話：你先別踩，等我填好了坑你再來。我這覺得這句話真的很暖人心，程式猿之間的關懷就應該這麼赤裸裸的。儘管，有的時候，這個坑不是你挖的..
當我們挖好坑，踩完坑，再埋好坑之後，回頭想想自己在團隊中扮演什麼樣的角色，挖坑者還是埋坑者？這必然是有益於成長的。
相關閱讀
評論(1)