你是否經(jīng)常遇到這樣的情景：負責開發(fā)的項目遇到線上bug，心想這不是我的鍋，先不管了，放著吧；代碼寫完后，隱隱感覺有問題，可程序跑得通，先用著吧；接手一個老系統(tǒng)，這什么破代碼，算了，改吧改吧將就用吧……
今天繞過的坑明天將加倍回來：
下次再改這塊代碼你仍然遇上它，只能硬著頭皮一行行捋代碼解決；線上某種場景觸發(fā)問題代碼，造成意想不到的崩潰；老系統(tǒng)改起來太費時間和容易踩坑，不如花時間重構。
測試向你吐槽你寫的bug，你否認道，這是前人挖的坑。PM改需求時說這里只加了個小功能，等到你開發(fā)時剛要挖坑，轟地掉進一個天坑里。你有沒有發(fā)現(xiàn)，每天的工作實則是在填一個接一個的坑。
填坑力，是程序員要具備的核心技能之一。
填坑力說到底是解決問題的能力
還記得自己上一次快速成長是什么時候嗎？是往做了一年的系統(tǒng)上CtrlC,CtrlV？還是去給人講你熟悉的業(yè)務框架？
人無法在順境中成長，而是在逆境中成長：新跳槽一家公司學習全新業(yè)務和技術框架，一邊闖禍一邊改進；公司想引進某項新技術，你被指定在一個月內完成遷移，于是你捉緊時間下班后扒技術文檔，周末在家寫demo……
從坑里摔倒爬起后才明白，先前遇到的問題，其實是成長機會。
幾年前震驚互聯(lián)網(wǎng)的“3Q大戰(zhàn)”，360給騰訊挖了個天坑，騰訊艱難填坑對戰(zhàn)。而后馬化騰給員工內部信寫道，如果沒有360的發(fā)難，我們不會有這么多的反思和感悟?；蛟S未來有一天，當我們走上一個新的高度時，要感謝今天的對手給與我們的磨礪。
隨后騰訊改變戰(zhàn)略發(fā)展方向，走向“開放”。
我們似乎一直活在坑里頭：挖坑的挖坑，掉坑的掉坑，填坑的填坑。可不管樂不樂意，人只有努力把身下的坑填好，然后去下一個坑，如此往復，才有真正的成長。
雖然程序員通常主張“我的鍋你來背，我的坑你來填”。但是低級坑請別挖：
1.巨坑：不寫注釋
排期緊張，新人海宇匆匆忙忙地將代碼堆好便申請?zhí)釡y?？伤腡L一句話將給他打回去重寫：一行注釋都不寫誰能看懂！
有一位開發(fā)說，注釋和代碼同等重要，注釋要寫的清楚明了，讓測試甚至是PM能讀懂你的代碼，這才算一個合格的程序員。
2.很坑：不寫接口文檔
有些公司的前后端聯(lián)調基本靠吼，“哥們，某參數(shù)少傳了”、“這個字段得大寫”、“你傳這么多我沒用，算了，放著吧”……
曾見過一個測試reject開發(fā)的郵件：前端沒傳某參數(shù)，導致流程跑不通，reject。
技術人員通常不愛寫文檔或者不愿意在文檔上花時間，導致前后端各開發(fā)各的，沒有規(guī)范標準，如需和外部系統(tǒng)對接時，又得捋一遍代碼找接口參數(shù)。接口文檔能節(jié)約聯(lián)調溝通時間和減少bug引入，提高代碼質量。
3.超坑：不考慮拓展功能
代碼不解解耦，不考慮未來可能會拓展的設計，無疑是在給隊友挖坑。
除了上面幾個坑外，還有底下的挖坑指南：
不實時容錯，程序只按照自己腦子“理所當然”的軌跡運行；
將判斷放在一層層深不見底的邏輯里；
一個方法寫了上千行，沒人敢動；從不自測。
