給工程師的羊年 20 句心訣，開工一起加油吧～咩
我最近看了一本叫做《the 97 Things a Programmer Should Know》的書。書是一本好書。不過，下面我將我認為最值得我們了解的 20 件事情列舉給大家：
- 應用函數式編程原則
引用透明性是一個非常可取的特性。這意味著，不論何時調用它，對於同一組參數它永遠給出同樣的結果，這使它跟那些與其他系統相互交織的東西比起來更易於使用。
- 從用戶的角度看問題
你不是用戶。不要把你的想法強加到用戶頭上，每個人的想法都不盡相同。 花一個小時去觀察用戶的行為比你花上一天的時間去猜測他們想要什麼要有用得多。
- 心口不一的客戶
在你決定客戶需求之前，最好先和他們多討論幾次，重新確認問題。有時候，客戶前後談論的話題以及不同客戶群體之間的想法是會有出入的。如果你想要成功，那麼必須得在軟件開發之前先好好解決差異問題。
在交流時不妨使用一些直觀的輔助工具，例如白板、可視化模型等，有助於客戶的理解和信息保存。
- 以 Why 開始
不要客戶說什麼就是什麼，多問幾個 Why。 只有弄清楚需求背後的原因，才能發現新的可能 。很多時候，我們可以通過對現有產品的改動來完成需求，大大減少工作量。
有時候，客戶的想法與你對產品的看法可能達不成一致。那麼反過來問自己「Why？」。這能讓你更加明確自己的第一感覺是否對頭。如果還是裁決不了，那麼就需要其他主要決策者的參與。
- 努力並不一定都有回報
不要工作得太辛苦。減少工作量，增加工作效率，才能完成更多的工作。我可不是在忽悠你。做項目時，如果想減少工作量，那麼勢必得找到實現目標的高效途徑。在提高了工作效率的同時還有助於積累經驗。以後碰到這樣的問題不就是三下五除二的事了。
- 大量刻意的訓練
我們還可以訓練自己從而提高執行任務的能力。這是一種技巧和技術，也意味著重複——意味著帶著某種目的去執行任務。不斷地重複 and 重複，一遍又一遍，直到你達到所需的能力級別。
譯者註：我曾經學 asp 的時候重複寫了幾十遍數據庫操作的代碼，都會背了：）
- 做點所謂的「重複工作」
使用現有的代碼與一步步設計自己的軟件——測試、修復、改進——是完全不同的。這些旁人看來所謂的「重複工作」有助於你更深刻地熟悉並理解現有的各個組件是如何運作的。
大多數開發人員可能從來沒有創建過核心的軟件庫，因此對它們的工作原理也不甚了解。其結果就是，一旦碰到這些種類的軟件出現問題就會束手無策。了解表面永遠是不夠的，只有將裡面隱含的工作原理挖出來，才能讓你真正地在這一行業，獨步武林。
- 不斷學習
● 閱讀
● 參與郵件討論
● 獲取並編寫代碼
● 找一個導師
● 了解你正在使用的框架和庫
● 犯了錯誤，需要修復 bug 或遇到問題時，弄清楚原因
● 教人也是學習的一種好方法，可以教學相長
● 參於用戶組或本地會議
● 加入或啟動研究小組
● 聽講座或在線觀看會談
● 學習一門新的編程語言
● 梳理出新的，可用於技術堆棧的想法和點子
- 知道如何使用命令行工具
由 grep 和 SED 提供的搜索和替換能力往往比 IDE 的功能更強大。
如，查找相同名稱的類：
find . -name '*.rb' | see 's/.*////' | sort | uniq -c | grep -v “^ *1” | sort -r
- Unix 工具會是你的好夥伴
Unix 工具是很簡單的擴展工具。只需要謹記以下一些簡單的規則即可：
● 程序只需要執行單一任務
● 讀取標準輸入文本行數據
● 顯示結果為標準輸出
● 影響工具的操作參數使用的也是命令行。
- 自動化，自動化，還是自動化
掌握 shell 語言，如 bash 和 PowerShell，構建自動化系統是不可能一蹴而就的。如果需要網站交互，可以使用如 iMacros 或 Selenium 等工具。
一開始你沒必要去學習所有的 bash 命令。當你需要的時候再去學也來得及。如果碰到你認為可以自動化的任務，那麼盡可能地學習並使用工具來達到自動化的目的。自動化任務越早開始越好。
- 版本控制
給軟件版本標記一個像徵性的名稱，以便於將來可以輕鬆找到所需的確切版本。也可以創建並行開發的分支：對於正在積極支持的發布版本，大多數項目有一個活躍的開發分支和一個或多個維護分支就行了。
- 放下滑鼠，離開鍵盤
碰到實在解決不了的問題時，不妨放下鼠標（滑鼠），離開鍵盤——可以聽聽音樂也可以出去散散步，休息會兒——讓你的大腦也休息會兒。也許過一會兒你再看這個問題的時候，答案呼之欲出了呢。
- 錯失採用多態的機會
多態允許我們創建小型的本地化執行上下文，而不需要 if-else 模塊。它可以讓我們寫出的代碼更少更易於理解。
- 特定領域類型勝過原始類型
領域類型能使得代碼既易於理解，又容易測試。
- 為必需行為測試，而不是偶發行為
測試的一個常見缺點就是與實現細節焊死在一起，而這些細節都是偶然的，跟所要求的功能關係不大。
- 測試要準確、具體
- API 設計的黃金法則
只為你開發的 API 編寫測試是不夠的，你還需要為使用 API 的代碼編寫單元測試。
- 編寫測試程序
一個優秀的測試程序可以當作開發文檔來使用，因為它們已經描述了代碼是如何工作的。對於每一個場景，測試程序必須做到：
1、將程序的上下文、運行起點或者必須滿足的前提條件描述清楚。
2、寫清楚程序是如何被調用的。
3、將程序運行的期望結果描述清楚。
當然不同的情況下這 3 個規則也會略有不同。其他程序員只要看了測試程序就可以判斷軟件會有哪些不同的行為，因此，每一個測試程序應該將程序的因果關係描述清楚。
- 採用單個二進製文件的發布規則
建立單個二進製文件可以確保發布流程中的每一個環節順利地進行。把握每一個運行環境的詳細信息，這意味著將這些信息記錄到一個 文件中，同時記錄環境信息的文件也需要版本控制。
如果環境配置有變化，但是你又沒有控制好版本的話，那麼我們就很難知道系統環境哪裡發生了變化。同時，這些環境配置信息必須和代碼分離，因為代碼和配置的變化頻率是不同的，當然變化的原因也是不一樣的。
譯文鏈接： http://www.codeceo.com/article/20-things-programmer-should-know.html
英文原文： Top 20 Things a Programmer Should Know
翻譯作者： 碼農網 –小峰
（本文轉載自《 碼農網 》；圖片來源： markus spiske ，CC Licensed）
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](http://www.liuhaihua.cn/img/qrcode_gzh.jpg)
