所有程序員都應該遵守的11條規則
我是一個傾向于生活在規則下的人。
現在，這些規則大部分是我本人為自己設立的，但它們依然是規則。
我發現為自己創建規則可以讓我過得更好，因為這樣做可以提前決定一些事情，而不是要在匆忙中做出所有的決定。
我今天早上應該去健身房嗎？
我的規則告訴我說我要在周三前往健身房，今天是周三，因此我要去健身房，就這么辦了！
這周，當我正在思考那些對我施加有影響的規則時，我想到了去制定一系列軟件開發者都應該遵守的規則，我認為這可能是一個好主意。
現在，我承認，這里面的大多數規則比那些“指導方針”要求的要多，它們是：
1: 技術是用來讓你獲取解決方案的，但它本身并不是解決方案
Technology is how you get to the solution, it is not THE solution.
我們帶來了最新的JavaScript框架，IoC容器，編程語言或者甚至是操作系統，但是所有這些并沒有實際解決我們作為一個嘗試解決問題的程序員的問題，取而代之的是更簡單的工具幫助我們解決問題。
我們對于特定的技術必須非常謹慎不要太瘋狂，不是我們碰巧喜歡或者碰巧現在很流行，而是要考慮運行他們所帶來的風險，要思考這個問題是不是就是那個釘子，而我們是不是碰巧拿著錘子，那么我們就要學習它。
2: 對代碼而言，“聰明”是“清晰”的敵人
Clever is the enemy of clear.
在寫代碼的時候，我們應努力保持書寫的代碼清晰易懂。
可以明確（Clear）表明自身意圖的代碼，永遠要比那些晦澀的代碼更有價值——無論那些晦澀的代碼被構建得多么聰明（Clever）。
雖然情況并不總是這樣，但一般來說，“聰明”是“清晰”的敵人。
一種經常出現的情況是，當我們寫出一段“聰明”的代碼時，這段代碼并不是特別的“清晰”。
這條規則非常重要，尤其是當我們思考我們要做一些特別“聰明”的事情時。
有時候我們寫出了“聰明”的代碼，它們同時也是清晰的，但是其他情況也會時有發生。
如果你對寫出簡潔的代碼感興趣，我高度推薦你用下面這本書上描寫的規則來檢驗：Robert C. Martin的《干凈的編碼者：專業程序員的行為守則》（The Clean Coder: A Code of Conduct for Professional Programmers）
3: 只在逼不得已的情況下才寫代碼
Only write code if you absolutely have to.
這條可能會有些爭議，畢竟，作為程序員，我們的工作不就是寫代碼嗎？
嗯。。。這個看你怎么說了。
寫代碼的確是我們工作的一部分，但是，我們要盡可能努力的去用最少的代碼來解決問題。
所謂“最少的代碼”并不是說我們只能用一個字母的變量名或者其它方式來壓縮我們的代碼。“最少的代碼”指的是我們應該只寫為了實現功能而必不可少的代碼。
我們常常添加一些“酷”的功能，來讓代碼“健壯”和“靈活”，讓代碼能夠處理“所有”可能的使用情況。我們企圖猜測那些可能會被用到的功能。總之，我們常常花費時間去解決一些頭腦中臆想出來的可能的情況。
我們這么做，是錯的。
不能否認，這些多余的代碼能會帶來些好處。然而，這些代碼同樣的會有很多危害。我們寫的代碼越多，就越有可能引入錯誤；我們寫的代碼越多，將來的維護工作就越繁雜。
好的軟件工程師只寫絕對需要的代碼。
偉大的軟件工程師會把沒用的代碼統統都刪掉。
4: 注釋是魔鬼
Comments are mostly evil.
我并不是很熱衷于寫注釋。當我跟Bob Martin在一起時，他說：
“你寫的每個注釋，都代表著你表達能力的欠缺“ －《整潔代碼：敏捷軟件藝術手冊》
這并不是說一點注釋也不寫，但通常我們可以通過一種更好的方式——命名來避免。
注釋僅在命名不能有效表示變量或方法的意圖時才真正需要。此時的注釋表達了不能用代碼表達的真實意圖。
例如，注釋能夠告訴你在代碼中某些奇怪的操作順序并不是錯誤的，它是由于底層系統的某一bug而有意為之的。
但通常，注釋不僅沒有必要，有時它們還會"撒謊"。
注釋沒有隨著代碼更新的傾向，而這是很危險的，因為它們會將你帶入歧途。
你會檢查每條注釋和與之對應的代碼，確保代碼是在做注釋說的事么？如果是的話，寫注釋還有什么用？如果不是，你怎么相信注釋說的是對的？
真他媽麻煩，所以最好還是盡量別寫注釋了。
5: 永遠要在你開始寫代碼前考慮好它是做什么的
Always know what your code is supposed to do before you start writing it.
這一條看上去顯而易見，然而事實并非如此。
想想你有多少次并沒有完全想好就坐下來寫代碼，而這段代碼確實實現了你要做的功能？
比之我樂于承認這個思路的正確性，我行動了更多次，這是一條我需要經常去品讀的規則。
練習測試驅動開發（Test Driven Development，TDD）在這里會有所幫助，因為你在寫出代碼前，必須逐字的了解它們會做些什么，但是這依然無法阻止你去做錯的事情。因此，在構建一個特性或功能前，保證自己百分之百地理解需求，也是很重要的。
6: 在交付之前，測試你的代碼
Test your sh—code before you ship it.
別把你的代碼直接扔給QA，然后指望著所有人來浪費時間為你服務。
事實上，你自己認真的運行一下測試案例，是完成代碼之前必不可少的一步。
這并不是說一定讓你自己找到代碼中所有的問題，但是你至少得把那些愚蠢得令人尷尬的錯誤找出來吧？
很多軟件工程師都覺得測試代碼是QA的工作。這個想法絕對是大錯特錯。保證代碼的質量，是每個人的工作！
7: 每天學點新東西
Learn something new every day.
如果你每天都不學新知識，你就在退步，因為我可以保證你會忘記一些東西。
每天學一些新東西，并不會花去你太多的時間。
試著花15分鐘去讀一本書——我去年讀了一大堆書，平均每天要花45分鐘在閱讀上。
每天的小進步，隨著時間的推移會積少成多，并在很大程度上重塑你的未來。如果你想在未來獲取回報，你現在就需要開始投資了。
此外，今天的技術變化非常之快，如果你不能做到不斷提高已有技能并學會新的技能，你會很快掉隊。
8: 寫代碼是件快樂的事
Writing code is fun.
誠然，你最開始進入這個行業可能只是因為它待遇優厚。
我是說，為了良好的待遇找工作沒有任何錯誤，但是醫生或律師可能會是更好的選擇。
你之所以成為了一名軟件開發人員，是因為你愛寫代碼。因此，不要忘記你在做你所熱愛的事情。
寫代碼有很多樂趣，我希望我能寫更多的代碼。
我這幾天經常忙于寫代碼并試圖讓它占據我更多的時間，這也是我為什么如此清晰地記得它有多么的有趣。
也許你已經忘記了寫代碼的樂趣，也許是時候你應該再次記起寫代碼是多么的有趣了——通過開始一個邊角的項目，或是僅僅改變你的心態，意識到你開始寫代碼了，并為之付出。（但愿如此）
9: 你無法完全了解它
You can’t know it all.
無論你學了多少知識，都會有大量你所不知道的東西。
認識這一點非常重要，因為你可以駕馭你的那些想要去學會所有東西的發狂的想法。
沒能獲取所有問題的答案，這挺好的。
在自己不理解某事時尋求幫助或說出來，這也挺好的。
在很多情況下，你可以相當接近地了解到你想知道的事情——相信我，我一直在這樣做。
我的觀點是，不要總想著學會一切——如果這是個不可能完成的任務。相反，你應該重點學習那些你需要去知道的東西，并且提升那些可以讓自己學習速度加快的能力。
10: 最佳實踐要因地制宜
Best practices are context dependent.
測試驅動開發是你最拿手的編程方式么?
我們應該一直采用結對編程?
不使用IOC容器你就不好編了?
這些問題的答案是“看情況吧”。
具體情況具體分析。
人們會將所謂的“最佳實踐”強推給你，并且他們經常說這些很實用——你應該經常這樣做或那樣做——但這是不對的。
當我寫代碼時我會遵循很多”最佳實踐“，但有時我也會背離它們。
11: 力求精簡
Always strive to simplify.
所有問題都可以進行分解。
最佳的解決方案往往是最簡單的。
但簡單并不容易，簡化事情需要付出努力。
本文目的在于簡化復雜的軟件開發和人生。
相信我，這并不容易。
傻瓜為問題提出復雜的解決方案。簡化解決方案需要更多的精力和耐心，但這沒有錯。
花點時間。多點努力。力求精簡。
你遵守什么規則？
上面是我遵守的規則，那你呢？
你個人遵守什么規則？
你認為什么是應該天天都記住的？
作者: John Sonmez 來源: 開源中國