寫(xiě)代碼不免出點(diǎn)bug，沒(méi)有人可以保證自己寫(xiě)的代碼不出問(wèn)題，而那些沒(méi)有被挖掘出來(lái)的bug，便成了后來(lái)者哭笑不得的坑...

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

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

1. 如何挖坑

挖坑可不是一件簡(jiǎn)單的事情，你寫(xiě)出來(lái)的插件、組件、代碼，很可能被很多人用到了，各種業(yè)務(wù)場(chǎng)景下狂奔你的代碼，一堆測(cè)試人員檢測(cè)你的bug，所以在項(xiàng)目中埋坑可不是一件容易的事情。

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

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

如果這些方案還不夠你挖坑，我想你團(tuán)隊(duì)同學(xué)的技術(shù)水平也真真是太高了。

很多時(shí)候，我們都是不經(jīng)意間留下了隱患。當(dāng)自己寫(xiě)的東西被其他人使用后，程序需要兼顧的場(chǎng)景就會(huì)增多，出現(xiàn)的問(wèn)題也會(huì)變多，這個(gè)時(shí)候我們不得不完善自己的代碼邏輯。結(jié)果就是，邏輯耦合度高了不少，代碼層次深了不少，出錯(cuò)的概率也就增加了不少。

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

2. 使勁踩坑

如果說(shuō)挖坑是一件很有難度的活兒，那踩坑就更難了。其實(shí)可以說(shuō)難的不是踩坑，而是發(fā)現(xiàn)自己踩坑了。

在一堆巨量的文件中找出「因把等于號(hào)寫(xiě)成恒等號(hào)」造成的 bug，這不是輕松的事情，可能你在 debugger 的時(shí)候進(jìn)入了別人的代碼領(lǐng)域，對(duì)著別人巨長(zhǎng)而又沒(méi)什么注釋的代碼，估計(jì)當(dāng)場(chǎng)就暈了，更暈的是，自己卻還在懷疑這到底是不是這堆代碼里頭的問(wèn)題。團(tuán)隊(duì)合作中，我們心里默認(rèn)相信隊(duì)友，隊(duì)友產(chǎn)出的代碼是沒(méi)有問(wèn)題可以直接拿過(guò)來(lái)使用的，所以一旦出現(xiàn)問(wèn)題，我們懷疑更多的是自己，質(zhì)疑別人需要很大的勇氣，尤其是質(zhì)疑那些成熟的框架，用了很多年的代碼。

那么如何踩坑呢？我們可不喜歡踩坑，有的坑踩進(jìn)去就跳不出來(lái)了，***只能選擇其他方案處理。很少有前端同學(xué)寫(xiě)程序的測(cè)試用例，可能還有一部分同學(xué)根本就沒(méi)聽(tīng)說(shuō)過(guò)什么測(cè)試用例。而在后端中（比如nodejs）沒(méi)有測(cè)試用例的代碼就是一堆廢代碼，除了自己可以拿著用用，別人根本就不敢用的。那么測(cè)試用例會(huì)考慮做那些事情呢？簡(jiǎn)單點(diǎn)說(shuō)：

• 寫(xiě)出有問(wèn)題的代碼，讓程序按照期望的出錯(cuò)方式出錯(cuò)，如果沒(méi)有，程序就有bug
• 寫(xiě)出沒(méi)問(wèn)題的代碼，讓程序按照正常的流程返回正確的結(jié)果，如果沒(méi)有，程序就有bug

測(cè)試用例要覆蓋到程序中所有的邏輯判斷，比如 if elseif else 等判斷的邏輯都要覆蓋進(jìn)去。當(dāng)我們的測(cè)試代碼覆蓋了100%的邏輯，那坑位就展露無(wú)遺了。

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

3. 用力填坑

首先，填坑是一種責(zé)任。

發(fā)現(xiàn)問(wèn)題是最難的，解決問(wèn)題只是時(shí)間的問(wèn)題。當(dāng)我們確認(rèn)了一個(gè)坑之后，***件事情就是告訴別人這里有坑，你不要踩了。但是***再多補(bǔ)一句話：你先別踩，等我填好了坑你再來(lái)。我這覺(jué)得這句話真的很暖人心，程序猿之間的關(guān)懷就應(yīng)該這么赤裸裸的。盡管，有的時(shí)候，這個(gè)坑不是你挖的..

當(dāng)我們挖好坑，踩完坑，再埋好坑之后，回頭想想自己在團(tuán)隊(duì)中扮演什么樣的角色，挖坑者還是埋坑者？這必然是有益于成長(zhǎng)的。