鑽石舞台

如果代碼沒有經過測試，那麼它就不起作用。

源代碼是你的朋友，確保你會使用它。

雖然你編寫了一些代碼，但並不代表你擁有這些代碼，如果團隊的成員不得不修改你的代碼，請不要生氣。

不要重複造輪子，現有的輪子或者代碼庫能夠提供幫助，多去搜索。

如果你有一些 idea，但是你沒有實現過，並不意味着這些 idea 是廢話。

源代碼只是向編譯器提示你要做什麼，但編譯器不一定會這樣做（編譯器優化）。

積極進行代碼審查，不要帶着自負的情緒進行代碼審查。

難以理解的代碼很難維護，所以要及時寫注釋。

難以維護的代碼幾乎毫無用處。

學會從業務需求中讀懂字裡行間的意思，並把它轉換為技術需求。

代碼布局越整潔，你的代碼讀起來就越容易。越容易閱讀，就越容易理解和維護。

代碼是不會自己寫注釋的，你的注釋能夠幫助他人理解，更重要的是，能夠幫助你理解，你可能現在明白了，但 5 年後呢？

糟糕的代碼會經常回來困擾你。

很少有 5 分鐘就能做完的工作，至少需要半天。

魔法值非常糟糕。

始終將代碼文檔化，不僅幫助別人，實際也是在幫助你自己。

項目管理人員總是希望你能一天完成兩天的工作。

如果你的產品有 bug ，你的用戶總會發現它。

重要的不是代碼的數量，而是代碼的質量，因為每個人都會寫 if else ，但不是每個人都會使用策略模式。

記住：代碼審查不是在批評你的代碼，無需多慮。

爛代碼最大的成本不在於運行，在於維護。

修復你代碼中的 bug 可以提高你的編碼能力而且能夠提高你的理解力。

你必須時刻提高你的技能，否則你可能就會 out of 整個行業。

如果用戶沒有要求某個功能，請不要亂加。

如果代碼沒有經過測試，它就不起作用（是的，我知道我已經包含了兩次，但這真的很重要）。

如果你寫出來讓你覺得很有成就感的代碼，請不要自滿，因為總會有人在某個地方，比你寫出更好的代碼。

代碼測試的時候，要針對經常性情況和邊界情況測試你的代碼。

永遠不要相信用戶輸入的內容，要始終對用戶的內容進行查殺。

要一直把緩衝區溢出納入日常考慮的範疇。

你要花更多的時間來思考代碼怎麼寫，而不是花更多的時間來寫代碼。

需求變更是最令人痛恨的東西。

請記住，你的成功更多是依賴你的軟技能和你如何闡述問題及其解決方案，而不是你的技術能力。

當你看到你的一些想法納入了產品，而很多卻被廢棄了，不要把它放在心上，因為這就是事情的工作方式。

使用版本控制，這會在關鍵時刻救了你。

愛你的工作，而不是愛你的公司，你永遠不知道你的公司什麼時候會停止愛你。

永遠會有比你更年輕，更有才華的人加入公司，這些年來不斷的薪資倒掛很好的說明了這一點。