第七章——在專案開始之前
不要蒐集需求，挖掘它們。需求是對需要完成的某件事情的陳述。
與使用者一同工作，以像使用者一樣思考。開採需求地過程也是開始與使用者群建立和諧地關係、了他們對你正在構建地系統的期許和希望的時候。需求不是架構。需求不是設計，也不是使用者介面。需求是需要。
製作需求文件時的一大危險是太過具體。抽象比細節活得更長久。
傾聽反覆出現的疑慮等你準備好再開始。
編寫規範是一項重要職責。對有些事情，「做」勝於「描述」。
不要做形式方法的奴隸。我們使用形式方法，但始終要記住，形式開發方法只是工具箱裡的又一種工具。昂貴的工具不一定能製作出更好的設計。
第八章——注重實效的專案
質量是乙個團隊問題。團隊作為乙個整體，不應該容忍小錯誤。在團隊中，應確保每個人都主動的監視環境的變化。團隊中的開發者必須相互交談。不要重複你自己，這樣的重複會造成工作的浪費。圍繞功能、而不是工作職務進行組織。確保一致和準確的一種很好的方式是使團隊所做的每件事情自動化。自動化是每個專案團隊的必要組成部分。同時知道何時停止。（內容和前面的有一點重複）
不要使用手工流程。提倡生成**，以根據公共**派生知識。讓計算機去做重複、庸常的事情，它會做得比我們更好，我們有更重要、更困難的事情要做。
早測試，常測試，自動測試。bug發現的越早，進行修補的成本就越低。事實上，好的專案擁有的測試**可能比產品**還要多。要到通過全部測試，編碼才算完成。你需要測試的主要型別有：單元測試，整合測試，驗證和校驗，資源耗盡、錯誤及恢復，效能測試，可用性測試。怎樣測試：回歸測試，測試資料，演練gui系統，對測試進行測試，徹底測試。測試狀態覆蓋，而不是**覆蓋。任何產品**一旦存在，就需要進行測試。乙個bug只抓一次。
把英語當作又一種程式語言。為專案製作的文件基本上有兩種：內部文件和外部文件。把文件建在裡面，不要拴在外面。
**應該有注釋，但太多的注釋可能和太少一樣糟。下面是不應出現在原始碼注釋中的一些內容：檔案中的**匯出的函式的列表，修訂歷史，該檔案使用的其他檔案的列表，檔名。文件和**是同一底層模型的不同檢視，對待文件要像對待**一樣用心。
額外的一英里。給使用者的東西要比他們期望的多一點，給系統增加某種面向使用者的特性所需的一點額外努力將一次又一次在商譽上帶來回報。隨著專案的進展，聽取你的使用者的意見，了解什麼特性會使他們真的高興。你可以相對容易地增加、並讓一般使用者覺得很好地特性包括：氣球式幫助或工具提示幫助，快捷鍵，作為使用者手冊的補充材料的快速參考指南，彩色化，日誌檔案分析器，自動化安裝，用於檢查系統完整性的工具，執行系統的多個版本、以進行培訓的能力，為他們的機構定製的splash螢幕（互動式軟體顯示的初始畫面）。只是要記住不要因為增加這些新特性而破壞系統。
在你的作品上簽名。過去時代的手藝人為能在他們的作品上簽名而自豪，你也應該如此。「這是我編寫的，我對自己的工作負責。」你的簽名應該被視為質量的保證。
好的程式設計師總是在學習。有兩個世界級的程式設計師專業協會：association for computing machinery(acm)和ieee computer society。我們建議所有的程式設計師都加入其中乙個，或是兩個都加入。成為專業協會的成員有許多好處。討論會和本地的會議能讓你有大量機會接觸興趣相投的人，而特別的興趣團體和技術委員會能給予你機會、參與制訂全世界使用的標準和指導方針。你還將從他們的出版物中學到許多知識，從高階的行業實踐討論直到低階的計算理論。
乙個注重實效的程式設計師。
閱讀《程式設計師修煉之道 從小工到專家》有感 1
第一章 注重實效的哲學 作為乙個負責人的程式設計師，在遇到問題時，應該是提供各種選擇，不要找蹩腳的藉口。在寫 的過程中，破窗效應同樣適用，所以在出現小問題的時候就應該及時解決，不要容忍破窗戶。我們看到過整潔 執行良好的系統，一旦窗戶開始破裂，就相當迅速的惡化。置之不理會更快的加速腐爛的程序。石頭湯的...
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...