所有程式設計師都應該遵守的 11 條規則

　　我是一個傾向於生活在規則下的人。

　　現在，這些規則大部分是我本人為自己設立的-但它們依然是規則。

　　我發現為自己建立規則可以讓我過得更好，因為這樣做可以提前決定一些事情，而不是要在匆忙中做出所有的決定。

　　我今天早上應該去健身房嗎？

　　我的規則告訴我說我要在週三前往健身房，今天是週三，因此我要去健身房，就這麼辦了！

　　這周，當我正在思考那些對我施加有影響的規則時，我想到了去制定一系列軟體開發者都應該遵守的規則，我認為這可能是一個好主意。

　　現在，我承認，這裡面的大多數規則比那些“指導方針”要求的要多，它們是：

 

　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: 力求精簡

　　所有問題都可以進行分解.

　　最佳的解決方案往往是最簡單的.

　　但簡單並不容易.簡化事情需要付出努力。

　　本文目的在於簡化複雜的軟體開發和人生.

　　相信我，這並不容易.

　　傻瓜為問題提出複雜的解決方案.簡化解決方案需要更多的精力和耐心，但這沒有錯。

　　花點時間。多點努力。力求精簡.

　你遵守什麼規則？

　　上面是我遵守的規則，那你呢？

　　你個人遵守什麼規則？

　　你認為什麼是應該天天都記住的？

　　你可以發個評論，同時，花一秒鐘的時間來加入已擁有 10,000 位軟體開發者的 Simple Programmer 社群。

　　點選這裡就能免費加入——每週你都能從我這裡獲得最好的資訊和其他免費的乾貨。

　　原文地址：http://dotnet.dzone.com/articles/11-rules-all-programmers