每一個程式設計師都應當瞭解的11句話

每一個程式設計師都應當瞭解的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. 努力做到化繁為簡

所有的的問題都可以進行分解。而最優雅的解決方案通常都非常簡單。但是，要變得簡單並不容易，這需要許多的工作。

比如，這篇文章的目的是從複雜的軟體開發工作和日常生活中提取經驗，通過歸納，以較簡潔的方式呈現給大家，而這並不是一件容易的事情。

在解決問題時，可以先找到一個較為複雜的笨方法。在此基礎上進行努力改進和提煉，使它在正確的基礎上變得簡單。這需要花費很多時間和努力，而人類不正是因為這個過程才慢慢變得聰明麼？