《程序員修鍊之道》筆記

*續 第八章 注重實效的項目

1. 無處不在的自動化

文明通過增加我們不假思索就能完成的重要操作的數目而取得進步。

無論是構建和發布流程、是書面的代碼複查工作、還是其他任何在項目中反覆出現的任務，都必須是自動的。人工流程不能保證一致性，也無法保證可重複性，特別是在不同的人對流程的各個方面有不同解釋時。使用shell腳本、批處理文件來處理流程，它們能以相同的次序反覆執行同樣的指令，還能被置於源碼控制之下，定時調度工具也很有幫助。

2. 全都是寫

a) 要把文檔當做整個開發過程的完整組成部分加以接受。文檔和代碼可以緊密結合起來，作為同一模型的兩個視圖對待。

b) 內部文檔包括源碼註釋、設計與測試文檔等；外部文檔是發布到外界的任何東西，比如用戶手冊。但不管受眾是誰、撰寫者是誰，文檔都應該是代碼的反映。

c) 代碼中的註釋

註釋應該討論為何要做某事、它的目標等。代碼已經說明了它是怎樣完成的，所以再為此加註釋是多餘的，而且也違反了DRY原則。

註釋中也適合記錄工程上的權衡、為何要做某些決策、放棄了哪些替代方案等等。

變數名應該精心選擇，並且有意義。匈牙利命名法（包括了變數類型信息）在面向對象的系統中並不合適。

比無意義的名稱更糟糕的是誤導人的名稱。

代碼應該有代碼作者、版權信息等內容，這些可以讓編輯器自動生成。

d) 任何形式的文檔都只是快照，可能剛剛發布出來就會過時，最好能採用自動化的方法及時更新。

文檔和代碼是同一底層模型的不同視圖，視圖是唯一應該不同的東西。不要讓文檔變成二等公民，被排除在項目主要工作流之外，對待文檔要像對待代碼一樣用心。

3. 極大的期望

在現實中，項目的成功是由它在多大程度上滿足了用戶的期望來衡量的。不符合用戶期望的項目註定是失敗的，不管交付的產品在絕對意義上有多好。要溫和地超出用戶的期望。要做到這一點建議做如下工作：

a) 交流期望。

用戶在一開始會有一些關於自己所需要的東西的想象，它們可能不完整、不一致或在技術上不可能做到，但那時他們的，他們也在其中投入了一些感情，不能簡單地忽視。

交流的目的是達成對開發過程和最終產品、以及他們尚未描述出來的期望的共同理解。如果團隊能與外界暢通地交流，這個過程幾乎是自動的。曳光彈、原型可以促進這一過程。

b) 額外一英里。

在與用戶緊密協作的過程中，用戶會及時了解項目的進展，那麼當項目交付時就不會有多少讓人吃驚的事情了。這是一件糟糕的事情，要設法讓你的用戶驚訝（高興），給他們的東西要比他們期望的多一點，比如友好的幫助系統、快捷鍵、自動化安裝等等，通過這些讓用戶看到：開發團隊想要開發出了不起的系統。但不要因為增加的新特性而破壞系統。

4. 傲慢與偏見

a) 在你的作品上簽名。

b) 過去的手藝人為能在他們自己的作品上簽名而自豪，你也應該如此，我們在負責一項設計，或是一段代碼，我們是在做可以引以為傲的工作。

c) 但不要因為所有權而產生「地盤」意識：懷有偏見，只欣賞自己的代碼，排斥自己的同事。我們不應該懷著猜忌心理阻止別人查看自己的代碼，同樣應該帶著尊重對待別人的代碼。

e) 我們想要看到對所有權的自豪：「這是我編寫的，我對自己的工作負責」，你的簽名應該被視為質量的保證，當人們在一段代碼上看到你的名字時，應該期望它是可靠的，用心編寫的、測試過的和有文檔的，一個真正的專業作品，由真正專業人員編寫——一個注重實效的程序員。