*續 第八章 注重實效的項目
?
1. 無處不在的自動化
文明通過增加我們不假思索就能完成的重要操作的數目而取得進步。
無論是構建和發布流程、是書面的代碼復查工作、還是其他任何在項目中反復出現的任務，都必須是自動的。人工流程不能保證一致性，也無法保證可重復性，特別是在不同的人對流程的各個方面有不同解釋時。使用shell腳本、批處理文件來處理流程，它們能以相同的次序反復執行同樣的指令，還能被置于源碼控制之下，定時調度工具也很有幫助。
?
?
?
2. 全都是寫
a) 要把文檔當做整個開發過程的完整組成部分加以接受。文檔和代碼可以緊密結合起來，作為同一模型的兩個視圖對待。
?
b) 內部文檔包括源碼注釋、設計與測試文檔等；外部文檔是發布到外界的任何東西，比如用戶手冊。但不管受眾是誰、撰寫者是誰，文檔都應該是代碼的反映。
?
c) 代碼中的注釋
注釋應該討論為何要做某事、它的目標等。代碼已經說明了它是怎樣完成的，所以再為此加注釋是多余的，而且也違反了DRY原則。
注釋中也適合記錄工程上的權衡、為何要做某些決策、放棄了哪些替代方案等等。
變量名應該精心選擇，并且有意義。匈牙利命名法（包括了變量類型信息）在面向對象的系統中并不合適。
比無意義的名稱更糟糕的是誤導人的名稱。
代碼應該有代碼作者、版權信息等內容，這些可以讓編輯器自動生成。
?
d) 任何形式的文檔都只是快照，可能剛剛發布出來就會過時，最好能采用自動化的方法及時更新。
文檔和代碼是同一底層模型的不同視圖，視圖是唯一應該不同的東西。不要讓文檔變成二等公民，被排除在項目主要工作流之外，對待文檔要像對待代碼一樣用心。
?
?
?
3. 極大的期望
在現實中，項目的成功是由它在多大程度上滿足了用戶的期望來衡量的。不符合用戶期望的項目注定是失敗的，不管交付的產品在絕對意義上有多好。要溫和地超出用戶的期望。要做到這一點建議做如下工作：
a) 交流期望。
用戶在一開始會有一些關于自己所需要的東西的想象，它們可能不完整、不一致或在技術上不可能做到，但那時他們的，他們也在其中投入了一些感情，不能簡單地忽視。
交流的目的是達成對開發過程和最終產品、以及他們尚未描述出來的期望的共同理解。如果團隊能與外界暢通地交流，這個過程幾乎是自動的。曳光彈、原型可以促進這一過程。
?
b) 額外一英里。
在與用戶緊密協作的過程中，用戶會及時了解項目的進展，那么當項目交付時就不會有多少讓人吃驚的事情了。這是一件糟糕的事情，要設法讓你的用戶驚訝（高興），給他們的東西要比他們期望的多一點，比如友好的幫助系統、快捷鍵、自動化安裝等等，通過這些讓用戶看到：開發團隊想要開發出了不起的系統。但不要因為增加的新特性而破壞系統。
?
?
?
4. 傲慢與偏見
a) 在你的作品上簽名。
?
b) 過去的手藝人為能在他們自己的作品上簽名而自豪，你也應該如此，我們在負責一項設計，或是一段代碼，我們是在做可以引以為傲的工作。
?
c) 但不要因為所有權而產生“地盤”意識：懷有偏見，只欣賞自己的代碼，排斥自己的同事。我們不應該懷著猜忌心理阻止別人查看自己的代碼，同樣應該帶著尊重對待別人的代碼。
?
d) 匿名可能會為邋遢、錯誤、懶惰和糟糕的代碼提供繁殖地。
?
e) 我們想要看到對所有權的自豪：“這是我編寫的，我對自己的工作負責”，你的簽名應該被視為質量的保證，當人們在一段代碼上看到你的名字時，應該期望它是可靠的，用心編寫的、測試過的和有文檔的，一個真正的專業作品，由真正專業人員編寫——一個注重實效的程序員。
?
![[轉]Xvid參數詳解](http://pic.xiahunao.cn/[轉]Xvid參數詳解)
)