注重實效的專案
41，注重實效的團隊
好團隊讓你加速成長。
不要留破窗戶：
團隊必須要為產品的質量負責。
煮青蛙：
確保每個人都主動地監視環境的變化。
交流：團隊中的開發者必須相互交談。
對外界而言，看上去沉悶寡言的專案團隊事最糟糕的團隊。
創立專案的品牌可以幫助團隊作為整體與外界交流。
不要重複你自己：
指定某個成員擔任專項管理員。
正交性：
不要把專案的各項活動－－分析、設計、編碼、測試－－孤立開來。
圍繞功能、而不是工作職務進行組織。
按照功能劃分團隊。不要兩個不同的子團隊做同乙個程式模組或類。
按照功能組織，用像合約、解藕、正交性這樣的技術組織我們的各種資源，有助於使團隊作為整體與變化的各種效應隔離開來。
創立一組自行其是的團隊並放任自流，是一種災難性的處方。專案至少需要兩個頭－－乙個主管技術，另乙個主管行政。
自動化：
確保一致和準確事一種很好的方式使團隊所做的每件事情自動化。
知道何時停止繪畫：
讓每個成員都能以他們自己的方式閃亮。足夠好的軟體。
42，無處不在的自動化
我們想要確保專案的一致性和可重複性。
一切都要自動化：
不要使用手工流程。
讓**幫你，shell，cron命令（週期性的執行），晚上可以跑測試，備份，構建，維護等。
專案編譯：
它應該是可靠的，可重複的。makefile。
我們想要一條命令就完成簽出、構建、測試和發布。
生成**：
在make的時候加入生成**的過程。以根據公公**派生知識。生成標頭檔案、原始檔或者是文件。
回歸測試：
讓makefile為你執行回歸測試，或針對單個模組。
遞迴make
構建自動化：
簽出**、構建（版本號，日期）、建立可分發映象、執行規定的測試。
定期執行測試，有助於保證修改的正確性。
最終構建：
make final，要一次完成所有引數設定。要進行所有的測試。
自動化管理：
執行指令碼，讓它們機遇原始碼和文件的內容來幫助你完成各種流程。email，書面工作，發布文件到web上。
目標是維持自動、無人照管、內容驅動的工作流。
用原始碼、文件、構建結果、回歸測試、效能統計、編碼度量等做成網頁資訊，發布到**。dry，資訊已經存在，將檢視放到瀏覽器。
批准流程：
也可以在網頁上完成，將資訊寫入原始碼，然後在網頁上check後，修改文字中的狀態。**檢查。
鞋匠的孩子：
軟體開發人員常常會使用最糟糕的工具來完成工作，鞋匠的孩子沒鞋穿。
讓計算機去做重複、庸常的事情－－它會做得比我們更好。我們有更重要、更困難的事情要做。
43，無情的測試
早測試，常測試，自動測試。
編一點，測一點。
編寫測試**的時間是值得的。
要通過全部測試，編碼才算完成。
測試什麼：
單元、整合、驗證和校驗、資源耗盡、錯誤及恢復、效能測試、可用性測試。
單元測試：
針對某個模組進行演練的**。
整合測試：
整合測試說明組成專案的主要子系統能工作，並且能夠很好地協同。
先單元測試，再整合。否則就是製造bug。
驗證和校驗：
它滿足系統的功能需求嗎？這是使用者想要的嗎？
使用者的訪問模式。
資源耗盡、錯誤及恢復：
根據環境的限制，進行相應的調整。檢查記憶體分配失敗，檢查硬碟空間。
失敗的時候如何失敗，設法儲存狀態，防止工作丟失。
效能測試：
效能測試、壓力測試和負載測試。
可用性測試：
由真正的使用者、在真實的環境條件下進行的。
軟體對於使用者而言、就像是手的延伸嗎？
沒能滿足可用性標準就像是除零錯誤，是個大bug。
怎樣測試：
回歸測試、測試資料、演練gui系統、對測試進行測試、徹底測試。
回歸測試：
把當前測試的輸出與已知的值進行對比。可以確定今天對bug的修正沒有破壞昨天可以工作的**。
測試資料：
現實世界的資料和合成的資料。
以下情形需要使用合成資料
需要大量的資料。需要強調邊界條件的資料。需要能展現出特定的統計屬性的資料。
演練gui系統：
提高解藕性，達到無需使用gui就可以測試的**。採用指令碼測試，耦合度太高了。
對測試進行測試：
通過蓄意破壞測試你的**。這樣可以確保測試時有效的。有時候會方便你理解**。
徹底測試：
覆蓋分析，可以檢視你的**執行與否。統計工具有用的。
測試狀態覆蓋，而不是**覆蓋。
何時進行測試：
大多數測試應自動完成。有計畫的測試，週期性的。
把網收緊：
乙個bug只抓一次。
發現bug以後，及時增加測試，及時檢視有無同類事情發生，所謂展開。
44，全都是寫
把文件和**結合起來。
把英語當作又一種程式語言。
內部文件：注釋，設計與測試文件。
外部文件，使用者手冊。
把文件建在裡面，不要拴在外面。
**中的注釋：
注釋應該討論為何做某事、它的目的和目標。
簡單的模組級頭注釋、關於重要資料與資料型別的注釋，以及給每個類和每個方法所加的簡要頭注釋、用以描述函式的用法和任何不明了的事情。
變數命名
引數是否也需要一起注釋。
不要把一些冗餘的資訊放到注釋裡，如修訂歷史，檔名。
注釋中有些內容可以讓編輯器自動為你插入。
可執行文件：
保留乙份知識，其他都是可以生成的檢視。
技術文件撰寫者：
也要遵守同樣的原則。
列印還是編排：
把資料放在web上，隨時修改，放上日期戳。可以用markup系統。
標記語言：
使用標記語言來寫文件，及時更新。可以多處安放。
45，極大的期望
專案的成功是由它在多大程度上滿足了使用者的期望來衡量的。
溫和地超出使用者的期望。
交流期望：
與你的使用者一同工作，以使他們正確地理解你將要交付的產品。
曳光彈和原型與便箋可以讓團隊構造使用者能看見的東西。兩者都是與使用者交流你對他們繡球的理解的理想途徑。並且兩者都讓你和使用者習慣於相互交流。
額外的一英里：
要設法讓你的使用者驚訝。不是驚嚇，是讓他們高興。
給他們的東西要比他們期望的多一點。
比如：氣球式幫助或工具提示幫助，快捷鍵，作為使用者手冊的補充材料的快速參考指南，彩色化，日誌檔案分析器，自動化安裝，用於檢查系統完整性的工具，執行系統的多個版本、以進行培訓的能力，為他們的機構定製的splash螢幕（啟動時的初始畫面）
不要因為增加新特性而破壞系統。
46，傲慢與偏見
不要逃避責任。
在你的作品上簽名。
不要懷著猜忌心阻止要檢視你的**的人。出於同樣的原因，你應該帶著尊重對待他人的**。
不要匿名。
這是我編寫的，我對自己的工作負責。
乙個注重實效的程式設計師。
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...