不會填坑的程式設計師不是一個好程式設計師！
你是否經常遇到這樣的情景：負責開發的專案遇到線上bug，心想這不是我的鍋，先不管了，放著吧；程式碼寫完後，隱隱感覺有問題，可程式跑得通，先用著吧；接手一個老系統，這什麼破程式碼，算了，改吧改吧將就用吧……
今天繞過的坑明天將加倍回來：
下次再改這塊程式碼你仍然遇上它，只能硬著頭皮一行行捋程式碼解決；線上某種場景觸發問題程式碼，造成意想不到的崩潰；老系統改起來太費時間和容易踩坑，不如花時間重構。
測試向你吐槽你寫的bug，你否認道，這是前人挖的坑。PM改需求時說這裡只加了個小功能，等到你開發時剛要挖坑，轟地掉進一個天坑裡。你有沒有發現，每天的工作實則是在填一個接一個的坑。
填坑力，是程式設計師要具備的核心技能之一。
填坑力說到底是解決問題的能力
還記得自己上一次快速成長是什麼時候嗎？是往做了一年的系統上CtrlC,CtrlV？還是去給人講你熟悉的業務框架？
人無法在順境中成長，而是在逆境中成長：新跳槽一家公司學習全新業務和技術框架，一邊闖禍一邊改進；公司想引進某項新技術，你被指定在一個月內完成遷移，於是你捉緊時間下班後扒技術文件，週末在家寫demo……
從坑裡摔倒爬起後才明白，先前遇到的問題，其實是成長機會。
幾年前震驚網際網路的“3Q大戰”，360給騰訊挖了個天坑，騰訊艱難填坑對戰。而後馬化騰給員工內部信寫道，如果沒有360的發難，我們不會有這麼多的反思和感悟。或許未來有一天，當我們走上一個新的高度時，要感謝今天的對手給與我們的磨礪。
隨後騰訊改變戰略發展方向，走向“開放”。
我們似乎一直活在坑裡頭：挖坑的挖坑，掉坑的掉坑，填坑的填坑。可不管樂不樂意，人只有努力把身下的坑填好，然後去下一個坑，如此往復，才有真正的成長。
雖然程式設計師通常主張“我的鍋你來背，我的坑你來填”。但是低階坑請別挖：
1.天坑：不寫註釋
排期緊張，新人海宇匆匆忙忙地將程式碼堆好便申請提測。可他的TL一句話將給他打回去重寫：一行註釋都不寫誰能看懂！
有一位開發說，註釋和程式碼同等重要，註釋要寫的清楚明瞭，讓測試甚至是PM能讀懂你的程式碼，這才算一個合格的程式設計師。
2.山坑：不寫介面文件
有些公司的前後端聯調基本靠吼，“哥們，某引數少傳了”、“這個欄位得大寫”、“你傳這麼多我沒用，算了，放著吧”……
曾見過一個測試reject開發的郵件：前端沒傳某引數，導致流程跑不通，reject。
技術人員通常不愛寫文件或者不願意在文件上花時間，導致前後端各開發各的，沒有規範標準，如需和外部系統對接時，又得捋一遍程式碼找介面引數。介面文件能節約聯調溝通時間和減少bug引入，提高程式碼質量。
3.地坑：不考慮拓展功能
程式碼不解解耦，不考慮未來可能會拓展的設計，無疑是在給隊友挖坑。
除了上面幾個坑外，還有底下的挖坑指南：
不實時容錯，程式只按照自己腦子“理所當然”的軌跡執行；
將判斷放在一層層深不見底的邏輯裡；
一個方法寫了上千行，沒人敢動；
從不自測。
從事前端開發的工作5年了，業餘的時候希望能在這裡分享一些網際網路資訊給大家。
如果你想學程式設計，可以來學習前端，前端學習門檻低，無論你有無程式設計基礎都可以學習。
無論是在學習web前端開發，還是已經工作的，這裡推薦一下我們的前端學習交流群：784783012，這裡是把夢想照亮的地方，同為了生活而拼搏奮鬥，大家互相幫助。新手加入即可獲得經過整理的最前沿的前端技術資料，不定時更新技術，與企業需求同步。好友都在裡面交流，歡迎加入
點選： 加入