程式設計師最應該知道的20件事

我最近看了一本叫做《the 97 Things a Programmer Should Know》的書。書是一本好書。不過，下面我將我認為最值得我們瞭解的20件事情列舉給大家：

1.應用函數語言程式設計原則
引用透明性是一個非常可取的特性。這意味著，不論何時呼叫它，對於同一組引數它永遠給出同樣的結果，這使它跟那些與其他系統相互交織的東西比起來更易於使用。

2.從使用者的角度看問題
你不是使用者。不要把你的想法強加到使用者頭上，每個人的想法都不盡相同。花一個小時去觀察使用者的行為比你花上一天的時間去猜測他們想要什麼要有用得多。

3.心口不一的客戶。
在你決定客戶需求之前，最好先和他們多討論幾次，重新確認問題。有時候，客戶前後談論的話題以及不同客戶群體之間的想法是會有出入的。如果你想要成功，那麼必須得在軟體開發之前先好好解決差異問題。
在交流時不妨使用一些直觀的輔助工具，例如白板、視覺化模型等，有助於客戶的理解和資訊儲存。

4.以Why開始
不要客戶說什麼就是什麼，多問幾個Why。只有弄清楚需求背後的原因，才能發現新的可能。很多時候，我們可以通過對現有產品的改動來完成需求，大大減少工作量。
有時候，客戶的想法與你對產品的看法可能達不成一致。那麼反過來問自己“Why？”。這能讓你更加明確自己的第一感覺是否對頭。如果還是裁決不了，那麼就需要其他主要決策者的參與。

5.努力並不一定都有回報
不要工作得太辛苦。減少工作量，增加工作效率，才能完成更多的工作。我可不是在忽悠你。做專案時，如果想減少工作量，那麼勢必得找到實現目標的高效途徑。在提高了工作效率的同時還有助於積累經驗。以後碰到這樣的問題不就是三下五除二的事了。

6.大量刻意的訓練
我們還可以訓練自己從而提高執行任務的能力。這是一種技巧和技術，也意味著重複——意味著帶著某種目的去執行任務。不斷地重複and重複，一遍又一遍，直到你達到所需的能力級別。
譯者注：我曾經學asp的時候重複寫了幾十遍資料庫操作的程式碼，都會背了：）

7.做點所謂的“重複工作”
使用現有的程式碼與一步步設計自己的軟體——測試、修復、改進——是完全不同的。這些旁人看來所謂的“重複工作”有助於你更深刻地熟悉並理解現有的各個元件是如何運作的。
大多數開發人員可能從來沒有建立過核心的軟體庫，因此對它們的工作原理也不甚瞭解。其結果就是，一旦碰到這些種類的軟體出現問題就會束手無策。瞭解表面永遠是不夠的，只有將裡面隱含的工作原理挖出來，才能讓你真正地在這一行業，獨步武林。

8.不斷學習

• 閱讀。（譯者注：訂閱《快樂碼農》程式設計師期刊）
• 參與郵件討論。
• 獲取並編寫程式碼。
• 找一個導師。
• 瞭解你正在使用的框架和庫。
• 犯了錯誤，需要修復bug或遇到問題時，弄清楚原因。
• 教人也是學習的一種好方法，可以教學相長。
• 參於使用者組或本地會議。
• 加入或啟動研究小組。
• 聽講座或線上觀看會談。
• 學習一門新的程式語言。
• 梳理出新的，可用於技術堆疊的想法和點子。

9.知道如何使用命令列工具。
由grep和SED提供的搜尋和替換能力往往比IDE的功能更強大。
如，查詢相同名稱的類：

find . -name ‘*.rb’ | see ’s/.*\///‘ | sort | uniq -c | grep -v “^ *1” | sort -r

10. Unix工具會是你的好夥伴。
Unix工具是很簡單的擴充套件工具。只需要謹記以下一些簡單的規則即可：

• 程式只需要執行單一任務
• 讀取標準輸入文字行資料
• 顯示結果為標準輸出
• 影響工具的操作引數使用的也是命令列。

11.自動化，自動化，還是自動化。
掌握shell語言，如bash和PowerShell，構建自動化系統是不可能一蹴而就的。如果需要網站互動，可以使用如iMacros或Selenium等工具。
一開始你沒必要去學習所有的bash命令。當你需要的時候再去學也來得及。如果碰到你認為可以自動化的任務，那麼儘可能地學習並使用工具來達到自動化的目的。自動化任務越早開始越好。

12.版本控制
給軟體版本標記一個象徵性的名稱，以便於將來可以輕鬆找到所需的確切版本。也可以建立並行開發的分支：對於正在積極支援的釋出版本，大多數專案有一個活躍的開發分支和一個或多個維護分支就行了。

13.放下滑鼠，離開鍵盤。
碰到實在解決不了的問題時，不妨放下滑鼠，離開鍵盤——可以聽聽音樂也可以出去散散步，休息會兒——讓你的大腦也休息會兒。也許過一會兒你再看這個問題的時候，答案呼之欲出了呢。

14.錯失採用多型的機會。
多型允許我們建立小型的本地化執行上下文，而不需要if-else模組。它可以讓我們寫出的程式碼更少更易於理解。

15.特定領域型別勝過原始型別
領域型別能使得程式碼既易於理解，又容易測試。

16.為必需行為測試，而不是偶發行為。
測試的一個常見缺點就是與實現細節焊死在一起，而這些細節都是偶然的，跟所要求的功能關係不大。

17.測試要準確、具體。

18.API設計的黃金法則。
只為你開發的API編寫測試是不夠的，你還需要為使用API的程式碼編寫單元測試。

19.編寫測試程式
一個優秀的測試程式可以當作開發文件來使用，因為它們已經描述了程式碼是如何工作的。對於每一個場景，測試程式必須做到：

• 1、將程式的上下文、執行起點或者必須滿足的前提條件描述清楚。
• 2、寫清楚程式是如何被呼叫的。
• 3、將程式執行的期望結果描述清楚。

當然不同的情況下這3個規則也會略有不同。其他程式設計師只要看了測試程式就可以判斷軟體會有哪些不同的行為，因此，每一個測試程式應該將程式的因果關係描述清楚。

20.採用單個二進位制檔案的釋出規則
建立單個二進位制檔案可以確保釋出流程中的每一個環節順利地進行。把握每一個執行環境的詳細資訊，這意味著將這些資訊記錄到一個檔案中，同時記錄環境資訊的檔案也需要版本控制。如果環境配置有變化，但是你又沒有控制好版本的話，那麼我們就很難知道系統環境哪裡發生了變化。同時，這些環境配置資訊必須和程式碼分離，因為程式碼和配置的變化頻率是不同的，當然變化的原因也是不一樣的。