[[130021]]

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

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

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

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

當(dāng)編寫代碼時，我們應(yīng)當(dāng)努力做到代碼清晰易理解。

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

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

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

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

3. 寫盡可能少的代碼

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

嗯，是的但也不是。

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

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

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

優(yōu)秀的軟件工程師寫盡可能少的代碼。

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

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

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

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

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

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

雖然在一般情況下，許多注釋還是非常有用的，但是卻存在著誤導(dǎo)的風(fēng)險。

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

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

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

5. 在編寫代碼之前你應(yīng)當(dāng)清楚你的代碼要做什么

這看起來是理所當(dāng)然的，但實際情況卻不是。

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

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

#p#

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

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

很多的軟件開發(fā)人員認(rèn)為測試代碼只是 QA 人員的工作。這是不對的。保持質(zhì)量是我們每個人的責(zé)任。

7. 每天都要學(xué)一些新東西

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

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

8. 寫代碼應(yīng)該成為一種樂趣

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

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

9. 你不需要無所不知

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

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

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

我的觀點是，不要企圖去學(xué)習(xí)所有的知識，因為這是一個不可能完成的任務(wù)。你需要關(guān)注和掌握的是能夠幫助你快速學(xué)習(xí)的技巧。

10. ***的實踐視環(huán)境而定

測試驅(qū)動開發(fā)***的方法是先編寫測試代碼?

我們應(yīng)該保持結(jié)對編程的習(xí)慣?

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

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

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

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

知識是死的，人是活的。***的實踐需要視環(huán)境而定。

11. 努力做到化繁為簡

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

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

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