[[130021]]

1. 技術只是解決問題的選擇，而不是解決問題的根本

我們可以因為掌握了***的 JavaScript 框架 ahem、Angular 的 IoC 容器技術或者某些編程語言甚至操作系統而歡欣雀躍，但是這些東西并不是作為程序員的我們用來解決問題的根本——它們只是用于幫助我們解決問題的簡單工具。

我們必須非常謹慎，不要對某項正好喜歡或者正好很火的特定技術走火入魔。否則，我們將進入這樣的思維怪圈：把掌握的那項技術比做是錘子，在思考問題時，會自然的把所有的問題都想象成是錘子可以解決的釘子。

2. 聰明是代碼清晰的敵人

當編寫代碼時，我們應當努力做到代碼清晰易理解。

雖然這句話并不總是正確的，但在一般情況下，聰明確實是代碼清晰的敵人。

事實證明，當我們寫一段自認為非常了不起的代碼的時候，這些代碼在別人眼里可能會是一頭霧水。

所以當你在編寫某段聰明高效的代碼的時候牢牢記住這個原則是很有必要的。

如果你對如何編寫整潔清晰的代碼很感興趣的話，我強烈推薦你看羅伯特·C·馬丁的書《The Clean Coder: A Code of Conduct for Professional Programmers》。

3. 寫盡可能少的代碼

這句話看起來有一些矛盾。程序員的工作不就是編寫代碼么?

嗯，是的但也不是。

我們的工作需要我們編寫代碼，但是我們在嘗試解決問題的時候應當做到盡量編寫更少的代碼。

這并不意味著我們需要盡量把代碼寫得更緊湊或者把所有的變量都使用單個字母。它的意思是我們應當嘗試用更精簡的算法來實現所需要實現的功能。

通常情況下，我們在代碼中所添加的各種很酷的特性是非常誘人的，這還能讓我們的代碼看起來更“健壯”和“靈活”，能夠處理各種不同類型的情況。但是，在更多的時候，我們嘗試更多可能有用的特性或者預防可能在未來存在的問題的做法是錯誤的。這些額外的代碼可能不具備任何的價值，但是卻可能造成更多的傷害。因為代碼越多，出現未知錯誤的機會就越多，代碼的維護也更加的麻煩。

優秀的軟件工程師寫盡可能少的代碼。

偉大的軟件工程師刪除盡可能多的代碼。

4. 注釋是代碼表述的***選擇

鮑勃·馬丁曾經說過：“當你在為一段代碼寫注釋的時候，你應當對自己糟糕的表達能力而反思。”

這并不意味著我們以后就不要寫注釋了。但在大多數情況下這種情況是可以避免的，你可以選擇用更好的命名方式來取代它。

只有在使用命名都無法表述清楚某個方法或者變量的目的時，注釋才是***的選擇。事實上，表達無法輕易在代碼表達的東西才是注釋的真正作用。

舉個例子，注釋可以告訴你在代碼中的那些奇怪的操作命令并不是一個錯誤，而是故意的，那是因為在底層操作系統存在著某個 bug。

雖然在一般情況下，許多注釋還是非常有用的，但是卻存在著誤導的風險。

在其它代碼更新后，與某些更新前代碼相關的注釋常常會得不到同樣的更新，這就導致了某些注釋會變得非常的危險，它們很可能會把你引導到一個錯誤的方向。

你檢查過與代碼密切相關的每一段注釋么?是否確保代碼都是在按照注釋所說的那樣做?如果你都照著這樣做了，那么注釋的意義又何在呢?如果你沒有這樣做，你又怎么知道注釋說的都是真的?

所以，注釋的作用并不象所宣揚的那么好，這種東西切勿濫用。

5. 在編寫代碼之前你應當清楚你的代碼要做什么

這看起來是理所當然的，但實際情況卻不是。

現實工作中你有多少次是在沒有經過充分了解到你的代碼要干些什么就開始著手編程的?反正對于我來說，是不計其數了，所以我把這條記錄下來用來隨時提醒我。

測試驅動開發(TDD)的實踐在這里可以幫助你，因為你需要在編寫代碼之前了解這些代碼將要用于什么地方，雖然這仍然不能阻止你創建錯誤的東西，但是它仍然非常重要。所以當你完完全全了解需要構建的需求和功能時，再動手編程。

#p#

6. 提交完成代碼之前先自行測試

不要在完成編程工作后，就把代碼扔給 QA，然后就坐等消息了。這樣會浪費每一個參加處理不必要 Bug 和問題的人的時間。你應當在報告編程工作完成之前，花費幾分鐘時間運行測試場景進行自我檢測。當然，在你把代碼提交給 QA 之前不一定會發現每一個 Bug，但至少你可以杜絕一些我們每個人都可能犯下的愚蠢低級錯誤。

很多的軟件開發人員認為測試代碼只是 QA 人員的工作。這是不對的。保持質量是我們每個人的責任。

7. 每天都要學一些新東西

有句名言“刀不磨要生銹，人不學要落后。”這句話是很有道理的，因為無論是否獲取到新的知識，你每天都會遺忘掉一些以前的東西。

每天學些一些新東西并不會花費掉你很多的時間。試著每天用 15 分鐘時間去讀書，然后你就會發現每天你都會有一點點的進步，在未來的某個時候，你會發現這種進步是巨大的。因此，為了在今后獲得豐厚回報你必須從現在開始就進行投資。另外，今天的技術發展日新月異，如果你不改善自己的技巧，學習新的東西，你很快就會被甩開。

8. 寫代碼應該成為一種樂趣

這是非常正確的。或許，你進入這個行業僅僅是因為它的薪水可觀。選擇一份報酬豐厚的工作這并沒有錯，但是還有更好的選擇，比如醫生或者律師。事實上很多人選擇做軟件開發還有一個原因，那就是他們喜歡寫代碼。在你被工作壓力所累的時候，不要忘了你選擇這份職業的初衷。

編寫代碼可以帶來很大的樂趣。多年的時間里，很多人可能都已經遺忘了這一點，那么從現在起，重新喚回以前的那份熱情吧，從身邊的項目開始，把你的觀念和意識轉換到以前你開始學習編程的那個時刻。

9. 你不需要無所不知

在你學到了很多知識的時候，你仍然有很多東西不知道。

意識到這點很重要，因為它可以驅使你去了解更多更多的東西。

不知道問題的所有答案沒有關系，不了解某個東西說出來并尋求幫助也無關緊要。在很多情況下，你可以選擇現學現用——相信我，我就是這么走過來的。

我的觀點是，不要企圖去學習所有的知識，因為這是一個不可能完成的任務。你需要關注和掌握的是能夠幫助你快速學習的技巧。

10. ***的實踐視環境而定

測試驅動開發***的方法是先編寫測試代碼?

我們應該保持結對編程的習慣?

如果不使用 IoC 容器是否會低人一等?

所有這些問題的答案是“看情況。”這取決于所處的實際環境。

人們試圖把***的實踐通過喉嚨等方式傳輸給你，他們會告訴你，他們平時都是這樣應用的。所以，你也應該這樣做——這其實并不正確。

在寫代碼的時候，我也借鑒過不少別人的成功經驗。但是，這些借鑒都是有條件的。

知識是死的，人是活的。***的實踐需要視環境而定。

11. 努力做到化繁為簡

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

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

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