1.優化vs可讀性。去特么的優化
盡量寫易于閱讀的代碼并且能被其他開發者所理解。因為花在閱讀難以理解的代碼的時間和資源遠遠多于優化代碼所帶來的好處。如果你需要優化，你可以將其獨立為一個模塊并且通過依賴注入的方法將其注入，進行百分百的覆蓋測試并且一年之內不會去更改它。
2. 架構優先
寫代碼沒有架構和實現你的理想而沒有計劃是一樣可笑的。在編寫你的第一行代碼前，思考一下它將做什么，怎么做，需要用到什么，各個模塊和服務之間如何交互，他們將會呈現出何種架構，怎樣進行測試和調試和如何更新。
3.測試覆蓋
測試是一件好事，但是對一個項目而言并不總是可以承受和有意義的。
你需要測試的時候：
-當你寫至少一月以內不會發生變化的模塊和微服務的時候。
-當你寫開源代碼的時候
-當你寫的代碼涉及金融行業的時候
不需要測試的時候：
-當你身處一個創業公司的時候。
-當你的團隊很小的時候并且代碼變更頻繁。
4. 保持簡單和傻瓜的
不要寫復雜的代碼。越簡單的代碼，bug可能越少，用于調試的時間也就越少。代碼只需要完成其功能就好而不是附帶許多的抽象和其他oop的東西（這位大佬很鄙視oop啊，暫且不敢茍同）
5.注釋
注釋暗示著壞代碼的存在。代碼應該不需要一行注釋就能理解。
6. 強耦合vs低耦合
盡量使用微服務的架構。一體化的軟件的運行速度快于微服務的軟件，但也僅限于一個服務器的時候。微服務可以讓你在多臺服務器上部署也可以在一臺機器上部署成為可能。
7.代碼審查
代碼審查可好可壞。
8. 重構是不殼能重構的啦
在我的從業生涯中，已經聽到“不要擔心，我們會來重構的”很多次啦。后面就演變成成啦技術債或者刪掉代碼重頭寫起。
所以不要留下技術債務除非你有資金重寫你的軟件。
9.疲憊或者心情不好的時候不宜寫代碼
當一個程序員疲憊的時候會比在精力旺盛的時候多產出2~5倍的bug。所以干的多并不是什么好事。這就是為什么越來越多的國家考慮六小時工作制并且有些國家已經開始實施啦（額，外國的月亮比較圓么？）
10. 不要一下寫完-而是不斷迭代開發
在寫代碼前，分析和預計一下客戶真正需要的東西，然后挑出你在短時間內能夠高質量完成的的最有價值的功能進行開發。
11. 自動化 vs 手動
長期看，自動化是一件百分百成功的事情。所以你如果有條件馬上將一些重復的事情進行自動化。
12. 走出去，培養一些愛好
13.空閑時間學習新東西
當人們停止學習的時候也是其開始走下坡路的時候。
翻譯自：13 Simple Rules for Good Coding (from my 15 years of experience)
