有哪些新手程序員不知道的小技巧？

內容摘於知乎： https://www.zhihu.com/question/36426051

 

做者：大狐狸
連接：https://www.zhihu.com/question/36426051/answer/76031743
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

1.重構是程序員的主力技能。

2.工做日誌能提高腦容量。

3.先用profiler調查，纔有臉談優化。

4.註釋貴精不貴多。杜絕大姨媽般的「例注」。漫山遍野的碎碎念註釋，實際就是背景噪音。

5.普通程序員+google=超級程序員。

6.單元測試老是合算的。

7.不要先寫框架再寫實現。最好反過來，從原型中提煉框架。

8.代碼結構清晰，其它問題都不算事兒。

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

10.編碼不要畏懼變化，要擁抱變化。

11.常充電。程序員只有一種死法：土死的。

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

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

14. 重構/優化/修復Bug，同時只能做一件。

15. 簡單模塊注意封裝，複雜模塊注意分層。

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

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

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

19. 最好的工具是紙筆;其次好的是markdown。

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

21. 寧肯多算一週，不可少估一天。過於「樂觀」容易讓boss受驚嚇。

22. 最有用的語言是English。其次的多是Python。

23. 百聞不如一見。畫出結果，一目瞭然。調試耗時將大大縮短。

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

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

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

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

28. 不要定過大、過遠、過細的計劃。即便定了也沒有用。

29. 至少半數時間將花在集成上。時間，時間，時間老是不夠。

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

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

32. 不知怎麼選技術書時就挑薄的。起碼不會太貴，且你能看完。

33. git是最棒的。簡單，可靠，免費。

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

35. Log要寫時間與分類。而且要能重定向輸出。

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

37. 造輪子是很好的鍛鍊方法。前提是你見過別的輪子。

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

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

40. 永遠別小看程序媛(╯3╰)

 

做者：程序員客棧
連接：https://www.zhihu.com/question/36426051/answer/559577427
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

1. 不要毫無計劃地寫代碼，思考、調研、計劃、編碼、測試、修改，一個都不能少；

2. 不要寫代碼前過分計劃，在一頭鑽進代碼前作點計劃是好事，可是即使是好事，也可能物極必反。喝太多的水都會使你中毒呢；

3. 請勿低估代碼質量的重要性，若是你只可以關注你所寫的代碼的一個方面，那麼確定是可讀性。表意不明的代碼就是垃圾，甚至是不可回收的垃圾；

4. 使用實現功能的最簡單方案，做爲專業的程序員，你的職責不是找出問題的一個解決方案，而是找出問題的最簡單的解決方案；

5. 適時放棄，當你開始懷疑一個解決方案的時候，你就應該考慮拋棄它，而且從新思考這個問題。無論你已經在這個解決方案中投入了多少精力。像 GIT 這樣的版本控制系統可以幫助你分開管理和嘗試多種不一樣的解決方案，把它利用起來吧；

6. 擅用 Google，除非你正在使用一種極其前沿的技術，不然當你遇到一個問題時，極可能別人早就遇到過一樣的問題了，而且也找到了解決方案了。給本身省點時間，先 Google 一下；

7. 作好封裝，基本的想法就是你想你的代碼高內聚和低耦合，意思是說保持相關的代碼在一塊兒（在一個類中），下降不一樣類之間的相互依賴；

8. 作好規劃，寫好需求再寫代碼，儘量編寫目前正在實現的方案所需的最少許代碼；

9. 要懂算法，使用合適的數據結構；

10. 不要寫重複性代碼，要用好配置文件，不要使用不必的條件語句和臨時變量；

11. 作好代碼註釋，可是不要給傻子都知道的代碼寫註釋；

12. 必定要寫好測試，若是可能的話，甚至在開始寫代碼實現需求以前，你就應該開始預估和設計須要測試校驗的狀況了。測試驅動開發 （Testing-driven development, TDD）不是什麼花俏的炒做，它是會實實在在會對你思考功能特性、尋找更好的設計方案產生積極影響的。

13. 不要以爲代碼運行起來就是正確的，有些時候代碼的 bug 可能並非顯而易見的；

14. 要可以質疑既有代碼，做爲一個初學者，老是應該假定那些你讀不懂的、且沒有文檔註釋的代碼極可能就是糟糕的代碼。質疑之，詢問之，使用 git blame 揪出罪魁禍首！

15. 不要過分迷戀最佳實踐，我以爲「最佳實踐」實際上是害人的，它暗示着你不須要深刻研究它，這就是有史以來最佳實踐，不用質疑！

16. 不要過分迷戀性能優化，若是你在運行代碼以前就在優化它了，那極可能你就是在過早優化代碼了，也極可能你正在費時費力作的優化是徹底不必的。

17. 以用戶體驗爲目標，要站在最終用戶的角度看問題。專業的開發者要考慮這個特定功能的用戶須要什麼、怎樣使用，要千方百計使得這個功能容易讓用戶發現和使用，而不是千方百計在應用中用最便捷添加這個功能，絕不考慮這個功能的可發現性和可用性。

18. 爲你的開發任務挑選合適的工具，你可使用最原始的工具建造房子，而後享受甜蜜時光。你也能夠花費一些時間和金錢去了解先進的工具、更快地建造更好的房子。工具在不斷地改進中，你要樂意去學習它們、使用它們。

19. 要理解好代碼問題和數據問題之間的關係，即便是程序中最小的 bug 也會致使它所管理的數據去到一種不可預測的狀態。尤爲是當全部數據校驗都徹底在這個有 bug 的程序中進行時。

20. 切勿重複造輪子，使用好現有的輪子和各類開源庫，會讓你事半功倍。固然，不要僅僅爲了使用一兩個函數就引入一整個代碼庫，在 JavaScript 中的典型例子就是 lodash 代碼庫；

21. 對代碼審查保持正確的態度，應該把每一次代碼複審看成是學習的機會，歡迎他們、感激他們、從中學習，最重要的，當你從你的代碼複審人員那裏學習到東西的時候，要感謝他們；

22. 用好版本控制工具和系統，新手每每低估了一個好的版本控制系統的威力，我這裏所說的好的版本控制系統其實就是指 Git；

23. 不要過分使用共享狀態，一個新手可能會嘗試使用定時器來解決這個共享變量的競態條件問題，特別是當他們必須處理一個數據鎖的問題時。這是危險的標誌，別這麼作，注意它，在代碼複審中指出它，永遠也不要接受這樣的代碼。

24. 正視 Error，Error 是好東西。Error 意味着你在進步，意味着你能夠經過簡單的後續修改就得到更多的進步。專業程序員喜好 Error。新手則痛恨 Error；

25. 學會休息，任何人的大腦都須要休息，身體也須要休息。

 

 

代碼體現一我的的能力，也體現一我的素質、工做態度以及修養。編碼不易，且編且珍惜。好的代碼是對項目的負責，對我的職業將來尊重，對團隊對同事的尊重