本文是碼農網
我最近看了一本叫做《the 97 things a programmer should know》的書。書是一本好書。不過，下面我將我認為最值得我們了解的20件事情列舉給大家：
引用透明性是乙個非常可取的特性。這意味著，不論何時呼叫它，對於同一組引數它永遠給出同樣的結果，這使它跟那些與其他系統相互交織的東西比起來更易於使用。
你不是使用者。不要把你的想法強加到使用者頭上，每個人的想法都不盡相同。花乙個小時去觀察使用者的行為比你花上一天的時間去猜測他們想要什麼要有用得多。
在你決定客戶需求之前，最好先和他們多討論幾次，重新確認問題。有時候，客戶前後談論的話題以及不同客戶群體之間的想法是會有出入的。如果你想要成功，那麼必須得在軟體開發之前先好好解決差異問題。
在交流時不妨使用一些直觀的輔助工具，例如白板、視覺化模型等，有助於客戶的理解和資訊儲存。
不要客戶說什麼就是什麼，多問幾個why。只有弄清楚需求背後的原因，才能發現新的可能。很多時候，我們可以通過對現有產品的改動來完成需求，大大減少工作量。
有時候，客戶的想法與你對產品的看法可能達不成一致。那麼反過來問自己「why？」。這能讓你更加明確自己的第一感覺是否對頭。如果還是裁決不了，那麼就需要其他主要決策者的參與。
不要工作得太辛苦。減少工作量，增加工作效率，才能完成更多的工作。我可不是在忽悠你。做專案時，如果想減少工作量，那麼勢必得找到實現目標的高效途徑。在提高了工作效率的同時還有助於積累經驗。以後碰到這樣的問題不就是三下五除二的事了。
我們還可以訓練自己從而提高執行任務的能力。這是一種技巧和技術，也意味著重複——意味著帶著某種目的去執行任務。不斷地重複and重複，一遍又一遍，直到你達到所需的能力級別。
譯者注：我曾經學asp的時候重複寫了幾十遍資料庫操作的**，都會背了：）
使用現有的**與一步步設計自己的軟體——測試、修復、改進——是完全不同的。這些旁人看來所謂的「重複工作」有助於你更深刻地熟悉並理解現有的各個元件是如何運作的。
大多數開發人員可能從來沒有建立過核心的軟體庫，因此對它們的工作原理也不甚了解。其結果就是，一旦碰到這些種類的軟體出現問題就會束手無策。了解表面永遠是不夠的，只有將裡面隱含的工作原理挖出來，才能讓你真正地在這一行業，獨步武林。
由grep和sed提供的搜尋和替換能力往往比ide的功能更強大。
如，查詢相同名稱的類：
find . -name 『*.rb』 | see 』s/.*\///『 | sort | uniq -c | grep -v 「^ *1」 | sort -runix工具是很簡單的擴充套件工具。只需要謹記以下一些簡單的規則即可：
程式只需要執行單一任務
讀取標準輸入文字行資料
顯示結果為標準輸出
影響工具的操作引數使用的也是命令列。
掌握shell語言，如bash和powershell，構建自動化系統是不可能一蹴而就的。如果需要**互動，可以使用如imacros或selenium等工具。
一開始你沒必要去學習所有的bash命令。當你需要的時候再去學也來得及。如果碰到你認為可以自動化的任務，那麼盡可能地學習並使用工具來達到自動化的目的。自動化任務越早開始越好。
給軟體版本標記乙個象徵性的名稱，以便於將來可以輕鬆找到所需的確切版本。也可以建立並行開發的分支：對於正在積極支援的發布版本，大多數專案有乙個活躍的開發分支和乙個或多個維護分支就行了。
碰到實在解決不了的問題時，不妨放下滑鼠，離開鍵盤——可以聽聽**也可以出去散散步，休息會兒——讓你的大腦也休息會兒。也許過一會兒你再看這個問題的時候，答案呼之欲出了呢。
多型允許我們建立小型的本地化執行上下文，而不需要if-else模組。它可以讓我們寫出的**更少更易於理解。
領域型別能使得**既易於理解，又容易測試。
測試的乙個常見缺點就是與實現細節焊死在一起，而這些細節都是偶然的，跟所要求的功能關係不大。
只為你開發的api編寫測試是不夠的，你還需要為使用api的**編寫單元測試。
乙個優秀的測試程式可以當作開發文件來使用，因為它們已經描述了**是如何工作的。對於每乙個場景，測試程式必須做到：
當然不同的情況下這3個規則也會略有不同。其他程式設計師只要看了測試程式就可以判斷軟體會有哪些不同的行為，因此，每乙個測試程式應該將程式的因果關係描述清楚。
建立單個二進位制檔案可以確保發布流程中的每乙個環節順利地進行。把握每乙個執行環境的詳細資訊，這意味著將這些資訊記錄到乙個檔案中，同時記錄環境資訊的檔案也需要版本控制。如果環境配置有變化，但是你又沒有控制好版本的話，那麼我們就很難知道系統環境**發生了變化。同時，這些環境配置資訊必須和**分離，因為**和配置的變化頻率是不同的，當然變化的原因也是不一樣的。
英文原文：top 20 things a programmer should know
]
程式設計師最應該知道的20件事
本文是碼農網 我最近看了一本叫做 the 97 things a programmer should know 的書。書是一本好書。不過，下面我將我認為最值得我們了解的20件事情列舉給大家 引用透明性是乙個非常可取的特性。這意味著，不論何時呼叫它，對於同一組引數它永遠給出同樣的結果，這使它跟那些與其...
程式設計師應該知道的97件事
上星期拿了三本書來看，其中一本就是 程式設計師應該知道的97件事 大概通讀了一遍裡面有73位著名的人物，分別寫了97件事。每個人都有自己總結的一句話，對於程式設計師們確實很實用。這裡面的人物在程式設計師這一職業中有工作20年以上的經歷，有自己開公司的也有是博士 教授的。若能認真遵守這97件建議，我想...
讀《程式設計師應該知道的97件事》筆記
技術債務 當你發現必須在 幹得好 和 幹得快 之間做出抉擇的時候，一般都會選擇 幹得快 並提醒自己將來再來返工。下一輪迭代自有其新的問題，工作重點轉移到新問題上，老問題還存在。martin fowler把它分成 蓄意和無意 把技術 債務立即記錄到任務卡上，在惡化前償還。無論你承諾了什麼，都得小心處置...