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、學會休息，任何⼈人的⼤大腦都需要休息，身體也需要

休息。