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

不要寫代碼前過度計劃，在一頭鉆進代碼前做點計劃是好事，但是即便是好事，也可能物極必反。

請勿低估代碼質量的重要性，如果你只能夠關注你所寫的代碼的一個方面，那么肯定是可讀性。

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

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

擅用Google，除非你正在使用一種極其前沿的技術，否則當你遇到一個問題時，很可能別人早就遇到過同樣的問題了，并且也找到了解決方案了。給自己省點時間，先 Google 一下；

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

做好規劃，寫好需求再寫代碼，盡可能編寫目前正在實現的方案所需的最少量代碼；

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

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

做好代碼注釋，但是不要給傻子都知道的代碼寫注釋；

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

不要覺得代碼運行起來就是正確的，有些時候代碼的 bug 可能并不是顯而易見的；

要能夠質疑既有代碼，作為一個初學者，總是應該假定那些你讀不懂的、且沒有文檔注釋的代碼很可能就是糟糕的代碼。質疑之，詢問之，使用 git blame 揪出罪魁禍首！

不要過度迷戀最佳實踐，我覺得 "最佳實踐" 其實是害人的，它暗示著你不需要深入研究它，這就是有史以來最佳實踐，不用質疑！

不要過度迷戀性能優化，如果你在運行代碼之前就在優化它了，那很可能你就是在過早優化代碼了，也很可能你正在費時費力做的優化是完全沒必要的。

以用戶體驗為目標，要站在最終用戶的角度看問題。專業的開發者要考慮這個特定功能的用戶需要什么、怎樣使用，要想方設法使得這個功能容易讓用戶發現和使用，而不是想方設法在應用中用最便捷添加這個功能，毫不考慮這個功能的可發現性和可用性。

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

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

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

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

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

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

正視 Error，Error 是好東西。Error 意味著你在進步，意味著你可以通過簡單的后續修改就獲得更多的進步。專業程序員喜愛 Error。新手則痛恨 Error；

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