文章轉載自「開發者圓桌」一個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個人修改後的最終結果，改動之前確保你看懂了它。