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