每一個程序員都應當瞭解的11句話，你最同意哪一句？
1. 技術只是解決問題的選擇，而不是解決問題的根本
我們可以因爲掌握了最新的 JavaScript 框架 ahem、Angular 的 IoC 容器技術或者某些編程語言甚至操作系統而歡欣雀躍，但是這些東西並不是作爲程序員的我們用來解決問題的根本——它們只是用於幫助我們解決問題的簡單工具。
我們必須非常謹慎，不要對某項正好喜歡或者正好很火的特定技術走火入魔。否則，我們將進入這樣的思維怪圈：把掌握的那項技術比做是錘子，在思考問題時，會自然的把所有的問題都想象成是錘子可以解決的釘子。
2. 聰明是代碼清晰的敵人
當編寫代碼時，我們應當努力做到代碼清晰易理解。
雖然這句話並不總是正確的，但在一般情況下，聰明確實是代碼清晰的敵人。
事實證明，當我們寫一段自認爲非常了不起的代碼的時候，這些代碼在別人眼裏可能會是一頭霧水。
所以當你在編寫某段聰明高效的代碼的時候牢牢記住這個原則是很有必要的。
如果你對如何編寫整潔清晰的代碼很感興趣的話，我強烈推薦你看羅伯特·C·馬丁的書《The Clean Coder: A Code of Conduct for Professional Programmers》。
3. 寫儘可能少的代碼
這句話看起來有一些矛盾。程序員的工作不就是編寫代碼麼？
嗯，是的但也不是。
我們的工作需要我們編寫代碼，但是我們在嘗試解決問題的時候應當做到儘量編寫更少的代碼。
這並不意味着我們需要儘量把代碼寫得更緊湊或者把所有的變量都使用單個字母。它的意思是我們應當嘗試用更精簡的算法來實現所需要實現的功能。
通常情況下，我們在代碼中所添加的各種很酷的特性是非常誘人的，這還能讓我們的代碼看起來更“健壯”和“靈活”，能夠處理各種不同類型的情況。但是，在更多的時候，我們嘗試更多可能有用的特性或者預防可能在未來存在的問題的做法是錯誤的。這些額外的代碼可能不具備任何的價值，但是卻可能造成更多的傷害。因爲代碼越多，出現未知錯誤的機會就越多，代碼的維護也更加的麻煩。
優秀的軟件工程師寫儘可能少的代碼。
偉大的軟件工程師刪除儘可能多的代碼。
4. 註釋是代碼表述的最後選擇
鮑勃·馬丁曾經說過：“當你在爲一段代碼寫註釋的時候，你應當對自己糟糕的表達能力而反思。”
這並不意味着我們以後就不要寫註釋了。但在大多數情況下這種情況是可以避免的，你可以選擇用更好的命名方式來取代它。
只有在使用命名都無法表述清楚某個方法或者變量的目的時，註釋纔是最後的選擇。事實上，表達無法輕易在代碼表達的東西纔是註釋的真正作用。
舉個例子，註釋可以告訴你在代碼中的那些奇怪的操作命令並不是一個錯誤，而是故意的，那是因爲在底層操作系統存在着某個 bug。
雖然在一般情況下，許多註釋還是非常有用的，但是卻存在着誤導的風險。
在其它代碼更新後，與某些更新前代碼相關的註釋常常會得不到同樣的更新，這就導致了某些註釋會變得非常的危險，它們很可能會把你引導到一個錯誤的方向。
你檢查過與代碼密切相關的每一段註釋麼？是否確保代碼都是在按照註釋所說的那樣做？如果你都照着這樣做了，那麼註釋的意義又何在呢？如果你沒有這樣做，你又怎麼知道註釋說的都是真的？
所以，註釋的作用並不象所宣揚的那麼好，這種東西切勿濫用。
5. 在編寫代碼之前你應當清楚你的代碼要做什麼
這看起來是理所當然的，但實際情況卻不是。
現實工作中你有多少次是在沒有經過充分瞭解到你的代碼要幹些什麼就開始着手編程的？反正對於我來說，是不計其數了，所以我把這條記錄下來用來隨時提醒我。
測試驅動開發(TDD)的實踐在這裏可以幫助你，因爲你需要在編寫代碼之前瞭解這些代碼將要用於什麼地方，雖然這仍然不能阻止你創建錯誤的東西，但是它仍然非常重要。所以當你完完全全瞭解需要構建的需求和功能時，再動手編程。
6. 提交完成代碼之前先自行測試
不要在完成編程工作後，就把代碼扔給 QA，然後就坐等消息了。這樣會浪費每一個參加處理不必要 Bug 和問題的人的時間。你應當在報告編程工作完成之前，花費幾分鐘時間運行測試場景進行自我檢測。當然，在你把代碼提交給 QA 之前不一定會發現每一個 Bug，但至少你可以杜絕一些我們每個人都可能犯下的愚蠢低級錯誤。
很多的軟件開發人員認爲測試代碼只是 QA 人員的工作。這是不對的。保持質量是我們每個人的責任。
7. 每天都要學一些新東西
有句名言“刀不磨要生鏽，人不學要落後。”這句話是很有道理的，因爲無論是否獲取到新的知識，你每天都會遺忘掉一些以前的東西。
每天學些一些新東西並不會花費掉你很多的時間。試着每天用 15 分鐘時間去讀書，然後你就會發現每天你都會有一點點的進步，在未來的某個時候，你會發現這種進步是巨大的。因此，爲了在今後獲得豐厚回報你必須從現在開始就進行投資。另外，今天的技術發展日新月異，如果你不改善自己的技巧，學習新的東西，你很快就會被甩開。
8. 寫代碼應該成爲一種樂趣
這是非常正確的。或許，你進入這個行業僅僅是因爲它的薪水可觀。選擇一份報酬豐厚的工作這並沒有錯，但是還有更好的選擇，比如醫生或者律師。事實上很多人選擇做軟件開發還有一個原因，那就是他們喜歡寫代碼。在你被工作壓力所累的時候，不要忘了你選擇這份職業的初衷。
編寫代碼可以帶來很大的樂趣。多年的時間裏，很多人可能都已經遺忘了這一點，那麼從現在起，重新喚回以前的那份熱情吧，從身邊的項目開始，把你的觀念和意識轉換到以前你開始學習編程的那個時刻。
9. 你不需要無所不知
在你學到了很多知識的時候，你仍然有很多東西不知道。
意識到這點很重要，因爲它可以驅使你去了解更多更多的東西。
不知道問題的所有答案沒有關係，不瞭解某個東西說出來並尋求幫助也無關緊要。在很多情況下，你可以選擇現學現用——相信我，我就是這麼走過來的。
我的觀點是，不要企圖去學習所有的知識，因爲這是一個不可能完成的任務。你需要關注和掌握的是能夠幫助你快速學習的技巧。
10. 最佳的實踐視環境而定
測試驅動開發最好的方法是先編寫測試代碼？
我們應該保持結對編程的習慣？
如果不使用 IoC 容器是否會低人一等？
所有這些問題的答案是“看情況。”這取決於所處的實際環境。
人們試圖把最佳的實踐通過喉嚨等方式傳輸給你，他們會告訴你，他們平時都是這樣應用的。所以，你也應該這樣做——這其實並不正確。
在寫代碼的時候，我也借鑑過不少別人的成功經驗。但是，這些借鑑都是有條件的。
知識是死的，人是活的。最好的實踐需要視環境而定。
11. 努力做到化繁爲簡
所有的的問題都可以進行分解。而最優雅的解決方案通常都非常簡單。但是，要變得簡單並不容易，這需要許多的工作。
比如，這篇文章的目的是從複雜的軟件開發工作和日常生活中提取經驗，通過歸納，以較簡潔的方式呈現給大家，而這並不是一件容易的事情。
在解決問題時，可以先找到一個較爲複雜的笨方法。在此基礎上進行努力改進和提煉，使它在正確的基礎上變得簡單。這需要花費很多時間和努力，而人類不正是因爲這個過程才慢慢變得聰明麼？