多快好省地建設代碼主義

文章轉載自「開發者圓桌」一個10年老猿原創文章傳播開發經驗，尤爲適合初學者或剛入職場前幾年程序猿的微信公衆號。

我播種，因此我收穫。我深深地懂得「一份耕耘，一分收穫」的道理。因此，我握着知識的鋤頭在學習的田野裏辛勤地勞動着，在夢境中從朦朧的狀態逐漸清晰，直至將它成爲現實。5.1勞動節段子一枚，祝你們勞動節玩好。

農業勞做有農活技巧，工人上班有工做技巧，程序員coding也有coding技巧，下面總結了一些老猿們的生產技巧，有不錯的參考意義，不要照搬，根據實際狀況去應用它們吧。

短期內，你可能沒法感覺到它們的做用，可是通過一段時間的積累和實踐，你會發現它們的意義很是大。廢話很少說了，咱們來看看這些小技巧吧。

重構是程序員的主力技能；你不可能一直開發，也會有維護工做，維護工做甚至比開發更費心力，由於你首先要看懂，而後才能夠修改甚至重構他人的代碼。

工做日誌能提高腦容量；養成寫工做日誌的好習慣，一是能夠跟蹤本身的工做狀況，二是能夠敦促本身合理安排工做時間。

先用profiler調查，纔有臉談優化；經過工具發現存在性能問題或者系統存在瓶頸再去優化，若是沒有任何問題，不要着急去優化，那會得不償失。

註釋貴精不貴多；杜絕大姨媽般的「例注」，漫山遍野的碎碎念註釋，實際就是背景噪音。你能夠多參考一些Apache，Github上的開源代碼是如何添加註釋的。

普通程序員+google=超級程序員；搜索能力是程序員必備的，不一樣的搜索方法和技巧，搜索到的內容也會千差萬別，關於程序員的搜索能力，能夠參考我以前的一篇文章「談談搜索能力」。任何事情都有兩面性，一味的依賴搜索會在必定程度上讓大腦變得懶惰，再也不思考和記憶問題，沒法造成完整的知識體系，這是須要不斷警醒的。

單元測試老是合算的；只要你是寫代碼的，寫的代碼質量再高，也不免有bug，而單元測試能夠有效地發現這些bug，提升你的代碼質量，而若是是採起測試驅動開發的，更能影響到你對整個系統的設計，這樣設計出來的系統的可測試性會大大提升。

不少公司的開發人員寫完代碼就提交了，有的可能會簡單寫個測試代碼(而非單元測試)來檢驗下代碼是否能正常工做，當調用者調用這些方法(函數或接口)時，常常會發現有問題，因爲這代碼可能不是他寫的，找bug就浪費了時間，有的隱藏的bug甚至在線上系統中才發現。形成的損失和影響有時就會很嚴重。

不要先寫框架再寫實現，最好反過來，從原型中提煉框架；先從解決問題出發，實現功能原型，而後再根據須要提煉公共方法或框架。

代碼結構清晰，其它問題都不算事兒；不要寫只有本身懂，而別人看不懂的代碼，如何讓本身的代碼結構更清晰，請參考「代碼大全2」這本旨在提升代碼質量的書。

分清好項目和壞項目；好的項目做風硬派，一鍵測試，一鍵發佈，一鍵部署；爛的項目生性猥瑣，口口相傳，不立文字，神神祕祕。

編碼不要畏懼變化，要擁抱變化；在程序員生涯中惟一不變的就是變化，若是可以採用良好的系統架構、設計模式等作到低耦合高內聚，在必定程度上是能夠把握變化，擁抱變化的。

常充電；程序員只有一種死法：土死的，IT行業發展自己就比較快，只有不斷的學習和嘗試新技術、新方法，才能保持職業生命力。

編程之事，隔離是方向，起名是關鍵，測試是主角，調試是補充，版本控制是後悔藥。

控制代碼行數；一行代碼一個兵，造成建制纔能有戰鬥力。單位規模不宜過大，千人班，萬人排易成萬人坑。

重構/優化/修復Bug，同時只能做一件；一次只調整一個參數或者一個方向，以觀察變化，按部就班開展工做。

簡單模塊注意封裝，複雜模塊注意分層；這個很少說了，你們能夠本身去體會。

人腦性能有限，整潔勝於雜亂；讀不懂的代碼，嘗試整理下格式，很差用的接口，嘗試從新封裝下。

迭代速度決定工做強度；想多快好省，就從簡化開發流程，加快迭代速度開始。

忘掉優化寫代碼；過早優化等同惡意破壞；忘掉代碼做優化。優化要基於性能測試，而不是糾結於字裏行間。

好記性不如爛筆頭；最好的工具是紙筆，其次好的是markdown。

任務拆分要夠細；leader問任務時間，若答不上來，多是任務拆分還不夠細。

適當的悲觀評估；寧肯多算一週，不可少估一天。過於「樂觀」容易讓boss受驚嚇。

會點英文頗有必要；最有用的語言是English，其次的多是Python。

百聞不如一見；多利用建模工具、思惟導圖畫出結果，一目瞭然。

資源、代碼應一道受版本管理；資源匹配錯誤遠比代碼匹配錯誤更難排查。

不要基於想象開發， 要基於原型開發；原型的價值是快速驗證想法，幫你們節省時間。

序列化首選明文 ；諸如二進制、混淆、加密、壓縮等等有須要時再加。

編譯器永遠比你懂微觀優化；你只能向它不擅長的方向努力。

過細無用；不要定過大、過遠、過細的計劃，即便定了也沒有用，採用精益創業的作法，逐步開展。

重視集成；至少半數時間將花在集成上。時間，時間，時間老是不夠。

自省最可靠；與主流意見/方法/風格/習慣相悖時，先反省本身最可靠。

出現bug主動查，不論是不是你的；這能讓你業務能力猛漲、我的形象飆升， 若是你的bug被別人揪出來.....呵呵，那你會很被動～≧﹏≦

不知怎麼選技術書時就挑薄的；起碼不會太貴，且你能看完，哈哈，不過這樣的技術書籍很少。如何選擇和閱讀技術書籍，能夠參考以前的一篇文章「圓桌問答(2017 第三季)」。

Git是最棒的；簡單，可靠，免費。

僅對「可預測的非理性」拋斷言。

Log日誌要精細；Log要寫時間與分類。而且要能重定向輸出。

註釋是稍差的文檔；更好的是清晰的命名。讓代碼講本身的故事。

知識面要廣；造輪子是很好的鍛鍊方法，前提是你見過別的輪子。

code review最好以小組/結對的形式；對業務有必定了解，建議會更有價值（但不絕對），並且不會成爲負擔。管理員我的review則很容易成team的瓶頸。

提問前先作調研；問不到點上既被鄙視，又浪費本身的時間。

永遠別小看任何一段代碼；一段看似簡單的代碼多是N我的修改後的最終結果，改動以前確保你看懂了它。