不會填坑的程式設計師不是一個好程式設計師！

你是否經常遇到這樣的情景：負責開發的專案遇到線上bug，心想這不是我的鍋，先不管了，放著吧；程式碼寫完後，隱隱感覺有問題，可程式跑得通，先用著吧；接手一個老系統，這什麼破程式碼，算了，改吧改吧將就用吧……

今天繞過的坑明天將加倍回來：

下次再改這塊程式碼你仍然遇上它，只能硬著頭皮一行行捋程式碼解決；線上某種場景觸發問題程式碼，造成意想不到的崩潰；老系統改起來太費時間和容易踩坑，不如花時間重構。

測試向你吐槽你寫的bug，你否認道，這是前人挖的坑。PM改需求時說這裡只加了個小功能，等到你開發時剛要挖坑，轟地掉進一個天坑裡。你有沒有發現，每天的工作實則是在填一個接一個的坑。

填坑力，是程式設計師要具備的核心技能之一。

填坑力說到底是解決問題的能力

還記得自己上一次快速成長是什麼時候嗎？是往做了一年的系統上CtrlC,CtrlV？還是去給人講你熟悉的業務框架？

人無法在順境中成長，而是在逆境中成長：新跳槽一家公司學習全新業務和技術框架，一邊闖禍一邊改進；公司想引進某項新技術，你被指定在一個月內完成遷移，於是你捉緊時間下班後扒技術文件，週末在家寫demo……

從坑裡摔倒爬起後才明白，先前遇到的問題，其實是成長機會。

幾年前震驚網際網路的“3Q大戰”，360給騰訊挖了個天坑，騰訊艱難填坑對戰。而後馬化騰給員工內部信寫道，如果沒有360的發難，我們不會有這麼多的反思和感悟。或許未來有一天，當我們走上一個新的高度時，要感謝今天的對手給與我們的磨礪。

隨後騰訊改變戰略發展方向，走向“開放”。

我們似乎一直活在坑裡頭：挖坑的挖坑，掉坑的掉坑，填坑的填坑。可不管樂不樂意，人只有努力把身下的坑填好，然後去下一個坑，如此往復，才有真正的成長。

雖然程式設計師通常主張“我的鍋你來背，我的坑你來填”。但是低階坑請別挖：

1.天坑：不寫註釋

排期緊張，新人海宇匆匆忙忙地將程式碼堆好便申請提測。可他的TL一句話將給他打回去重寫：一行註釋都不寫誰能看懂！

有一位開發說，註釋和程式碼同等重要，註釋要寫的清楚明瞭，讓測試甚至是PM能讀懂你的程式碼，這才算一個合格的程式設計師。

2.山坑：不寫介面文件

有些公司的前後端聯調基本靠吼，“哥們，某引數少傳了”、“這個欄位得大寫”、“你傳這麼多我沒用，算了，放著吧”……

曾見過一個測試reject開發的郵件：前端沒傳某引數，導致流程跑不通，reject。

技術人員通常不愛寫文件或者不願意在文件上花時間，導致前後端各開發各的，沒有規範標準，如需和外部系統對接時，又得捋一遍程式碼找介面引數。介面文件能節約聯調溝通時間和減少bug引入，提高程式碼質量。

3.地坑：不考慮擴充功能

程式碼不解解耦，不考慮未來可能會擴充的設計，無疑是在給隊友挖坑。

除了上面幾個坑外，還有底下的挖坑指南：

不實時容錯，程式只按照自己腦子“理所當然”的軌跡執行；

將判斷放在一層層深不見底的邏輯裡；

一個方法寫了上千行，沒人敢動；

從不自測。