學習代碼語法是一件比較簡單的事情。但是如何利用簡單的語法去組建龐大的項目，會衍生出很多問題。這裡總結了一些編程過程中需要注意的陷阱和原則，之後如果有新的總結，我會繼續更新。
1，不要編程
對，不要編程。能用草稿紙解決的問題，不用去寫程序。
在寫程序之前，應該先弄清楚問題。花更多的時間去聽、讀和理解問題。
非常多的程序員在寫代碼的過程中去梳理問題，所以他們會花更多時間去調試和找 bug.
2，不要太依賴工具
不管是編程語言，類庫和成熟軟件，都是解決問題的工具，真正值錢的並不是工具，而是掌握的編程技能，計算機知識和思維。
為具體的項目去尋找合適的編程語言，類庫和軟件。每個工具都有適用場景，python 更適合上層開發，go 更適合底層開發。 如果只會特定的編程語言，類庫，工具的使用，你只能根據這些工具去找工作，選擇性會大大降低。
太依賴工具還有另一個副作用：只懂用法，不懂實現。當工具更新或者過時了，又要重新學過，辛辛苦苦積攢的經驗毫無勇武之地，和一個從來沒用過的新人沒有多大區別。
儘可能的原生語句實現，不要隨意安裝第三方庫。一旦這些庫停止維護，或者因為版本更新出現兼容性問題，你的代碼將無法運行。
對於不是特別複雜的問題，儘量用原生語法和標準庫。要用第三方的類庫，也要選擇那些成熟的，持續維護而且兼容性夠好的類庫，就算實現起來麻煩一點。
3，不要欠技術債務
技術債務指的是：開發人員為了加速軟件開發，在應該採用最佳方案時進行了妥協，改用了短期內能加速軟件開發的方案，從而在未來給自己帶來的額外開發負擔。這種技術上的選擇，就像一筆債務一樣，雖然眼前看起來可以得到好處，但必須在未來償還。
比如使用了新潮但是不成熟的框架。或者在編程中複製粘貼別人的代碼，但是沒有經過自己的思考而直接使用。
在代碼編寫過程中儘量要弄懂框架和代碼的原理，就算當時因為進度不理解，也要抽時間去消化。否則代碼出問題了都不知道怎麼回事。
4，遠離商業炒作的項目，對新興技術保持警惕
許多流行的框架都是一些公司為了 KPI 或者商業需要開發的。這些框架可能面臨後期無人維護，或者社區運營無力的風險。這意味著當底層出現問題的時候你不能高效的解決問題。
在 github 上有很多熱門的項目非常受人歡迎，但很多沒有實質內容。開發者從來不去處理 issue, 也不對代碼進行更新。
對新興技術同樣需要保持警惕。新興技術可能是公司的實驗產品，不管是穩定性，社區運營都沒有得到市場證明，過早投入太多精力風險很大。如果這個技術沒有形成氣候，基本上前期的努力就白費了。 一個成熟的技術框架需要長時間和大量用戶的實踐證明，選用技術方案時最好優先考慮成熟方案。
5， 保持學習
離開你的舒適區。每天學習。並且把你學到的教給別人（教學是最好的學習工具）。除非你是一位大師，你就可以不用學習。讓自己接觸其他語言、技術、文化並保持好奇心。
學習一定要有產出。可以通過文字，視頻，語音等方式記錄。 沒有產出，很難形成自己的思維，馬上就會忘掉。
對於新興的技術，不是完全不能碰。新技術出來的時候可以安排適當的時間接觸，從中吸收新的思想和設計方式。 學習的時候一定要做一個項目出來，以項目驅動學習。
6，寫文檔
好代碼不需要文檔，但是優秀的代碼都有很好的文檔。
有了文檔，別人在使用的時候就可以大幅減少試錯成本。 之後你去優化更新代碼的時候也可以極大的提升效率。
7，提高代碼的可讀性
你不是為機器寫代碼，而是為你的同事和未來的自己寫代碼。如果你不想在更新的時候花大量時間去閱讀之前的代碼，那就應該讓你寫的代碼，小朋友也能看得懂。
儘量使用簡單易懂的語法，不要炫技。很多流行的技術框架使用了一些非常酷炫的語言特性，讓人容易產生技術崇拜，但是很多實現都可以使用更加通俗易懂的語法寫成。
酷炫的語法糖或者語言特性容易讓你迷失自我。
8，編寫獨立的模塊
你不應該把你所有的代碼像麵條一樣攪在一起，彼此依賴。 這樣一旦某個部分出現問題，整個項目都會受到影響。
你應該為每一個功能編寫獨立的模塊，並且對模塊進行獨立測試，然後再導入到其他的代碼，做集成測試。
模塊交互的地方容易出現 bug, 所以要更加仔細檢查。
9， 編寫純函數
純函數是指：
•當傳入相同的輸入值時，產生相同的輸出；•函數的輸出和輸入值以外的狀態無關；（比如在輸入值不變的情況下，時間改變，輸出發生了變化）
對那些不方便通過純函數實現的，使用類和對象進行封裝。 使用類的時候，儘量避免重寫、繼承和隱式智能。
對純函數和非純函數進行分開管理。
10，不要複製粘貼
複製粘貼非常容易產生 Bug。複製越多次，bug 越多。 可以說一個項目裡的 bug 數量和你複製粘貼的數量是成正比的。 如果一定要複製粘貼，請仔細檢查每一行代碼。
11，面向異常編程
人的思維習慣總是傾向於考慮正常情況，而忽略可能潛在的異常。 有時候是沒有考慮到，更多的時候則是考慮到了，但是嫌麻煩。
如果不處理異常，意味著你的代碼隨時會終止運行，意味著這份代碼是不可信賴的。
儘早處理異常，並且回答這些異常為什麼會發生，如何檢測，以及如何解決。驗證所有系統輸入（包括用戶輸入），儘早發現問題，你的代碼就會少更多的隱患。
編程的時候，應該習慣性的問自己，如果程序沒有按照我預設的路徑執行，會怎麼樣？
12， 分清楚代碼的優先級
並不是所以的代碼都同樣重要。有的代碼，沒了它程序完全無法執行，有的代碼，自從你寫了以後，就從來沒被使用過。 你需要理解這 3 者之間的區別：
•核心代碼：就像汽車裡的引擎。沒有它，產品就沒有意義。•必要代碼：就像汽車的備用輪胎。它很少使用，但當需要時，它的功能決定了系統的成功。•附加代碼：就像汽車的杯託。有它很好，但沒有它，汽車照樣開。
13， 分清楚產品規範的優先級
用戶體驗、安全性、性能是相互衝突的。
一個一般的原則是： 安全性 > 可用性（易訪問性和用戶體驗）> 可維護性 > 簡單性（開發人員體驗/DX）> 簡潔性（代碼長度）> 性能
但也不要盲目，每個類型的產品都有側重點。和任何職業一樣，經驗越豐富，就越能在每一種情況下找到正確的平衡點。例如，在設計遊戲引擎時，性能是最重要的；但在創建銀行應用程序時，安全性是最重要的因素；在初創項目，你完全不需要考慮性能，當項目發展起來的用戶太多，性能就會成為你首要要考慮的問題。
14， 讓別人參與你的代碼維護
開源和閉源並不是永遠都是爭鋒相對的。 對於涉及到商業風險的項目，可以選擇閉源。但是對於不觸及商業的底層代碼，開源是個更好的選擇。
因為底層的代碼脫離了商業邏輯，而且往往非常抽象和複雜，需要更多人的參與和實踐。可參考 linux 開源項目。
任何有意義和有回報的軟件都是協作的結果。一個人總是會有思維死角，不要太相信自己的能力。
請跟我默唸 3 遍：我寫的代碼是垃圾，我寫的代碼是垃圾，我寫的代碼是垃圾。 它們需要別人的優化。
閱讀更多 小湧的互聯網天地 的文章
