1.編程最可怕的不是語法難，而是邏輯亂
複雜化的業務，帶來各種各樣的邏輯問題，可能由於一個小數點，就會導致很嚴重的線上事故。當語法已經成爲了一種過去式，那麼邏輯正確則是代碼的必備技能了。在邏輯的基礎上，更有可能需要兼顧併發，性能和容錯等問題，會將代碼的邏輯的複雜程度成幾何倍的上升。這樣的結果會導致問題，會讓你在你原有的基礎代碼上打補丁，最終造成整個代碼臃腫且效率低下的情況。因此，在開始設計代碼思路的時候，就應該有一個人來把控這樣的大局觀，來考慮這些方方面面的問題。
2.請永遠對線上代碼保持敬畏
代碼的好壞並不是通過自己的主觀判斷來決定的，看似很傻逼的一段代碼，可能是因爲當時的環境造成程序員迫不得已這樣去實現這段邏輯，而且這段代碼可能在線上已經運行了很久，隨意的更改可能會導致線上問題的產生，而且由於歷史原因，對這段代碼重構的成本將大大超出預期。如果你讀不懂這段代碼，請對它保持敬畏，說不定在某個地方起着關鍵性的作用。
3.最優解的追求並不是最佳選擇
每一個程序眼裏都有一個最優解，而因此誕生了算法這一產物。但是，最優解的本質，並不一定適合現代的業務開發，最優解的實踐往往是精簡且特立獨行的思維方式，而在“敏捷開發”的實踐中，快速更替迭代，纔是最有效的開發方式。花費大量的時間去理解代碼本身，則是一件非常不友好的方式。雖然最優解確實能夠帶來性能的提升，但是實際中從各方面的成本覈算來看，並不能起到關鍵性的作用，尤其在現在硬件性能以及極爲強悍的今天，快速實現業務功能，纔是最有效的考量。
4.沒有以用戶體驗爲目標
做一個應用，一定要以用戶的角度來看待問題。如果只是以自己實現的邏輯的角度，將不一定有一個用戶友好功能。要做專業的開發者，站在最終用戶的角度看問題。專業的開發者要考慮這個特定功能的用戶需要什麼、怎樣使用，要想方設法使得這個功能容易讓用戶發現和使用，而不是想方設法在應用中用最便捷添加這個功能，毫不考慮這個功能的可發現性和可用性。
5.要學會自己造輪子
關於某種固定的任務，可能會用到特定的邏輯，當多次進行實踐的情況下，特定的邏輯就可以抽象爲一個特定的工具。這樣的實現會大大增加你的開發效率。一些程序員明顯只是針對每一次任務的完成而完成，並不會思考自己爲什麼要這樣完成，爲什麼要用這樣的方法，而在下一次相似的業務邏輯下，則又一次的重複相同的邏輯開發。這樣的開發不僅僅對自己的提升有限，且對業務邏輯的處理不友好。
6.不要重複的造輪子
這是一件很恐怖的事情，這裏承接上面這一點，造輪子是爲了提高自己的編程效率，而重複的造輪子則是浪費資源的一種行爲。在開源軟件的大前提下，很多的輪子是開源免費的。因此，使用別人的輪子，並不是否定自己的過程，而你要做的，是花時間在輪子的改造上下功夫。這裏有個需要注意的點在於，千萬不要因爲一個輪子，而引入大部分的代碼，這樣本身的邏輯將會因此而臃腫不堪。
7.要讓自己的代碼有跡可循
代碼一旦上線，就很難進行調試，往往線上一旦出現bug，能依靠的只有自己的日誌。而這些日誌，則會成爲你尋找bug的唯一線索。因此，在合適的地方打日誌，將會是你職業生涯中必備的能力。爲了讓自己的代碼有跡可循，每一個分支邏輯都需要日誌進行記錄，且每一個函數的入口也要有固定的參數。只有這樣，才能在遇到線上問題的情況下，讓你不會無計可施。
8.版本控制
業務邏輯必然需要版本控制，沒有任何的例外。沒錯，我這裏說的這個控制工具就是GIT。源碼控制並不僅僅是你把你的更改推送給別人，讓他們在此之上接着開發，除此之外還有更重要的。源碼控制是和清晰的歷史相關的。源碼會被質疑，代碼的歷史進程能夠輔助回答這些困難的質疑。這就是爲什麼我們如此關注提交信息的原因。它們還是又一種交流實現的通道，使用提交信息能夠幫助將來的維護者弄清代碼爲什麼會發展到目前的狀態。
更多信息，請關注【計算機俱樂部】