寫好軟體75條體會自我檢查

你們的項目組使用源代碼管理工具了麼？

采用ClearCase進行源代碼管理，同時啟用開發，測試，內建三個分支，對于Bug分支根據版本實際情況确認是否啟用。

你們的項目組使用缺陷管理系統了麼？

使用ClearQuest管理缺陷和變更

你們的測試組還在用Word寫測試用例麼？

采用TestManager寫測試用例和管理測試用例，必要配合Excel進行。

你們的項目組有沒有建立一個門戶網站？

項目有專門的讨論工作室。

你們的項目組用了你能買到最好的工具麼？

能夠買到。主要是VS.Net和PL/SQl Developer.其它輔助工具全部用開源工具。如打包采用Nant，反翻譯采用Reflector，單元測試采用Nunit.

你們的程式員工作在安靜的環境裡麼？

是的，有獨立安靜空間。

你們的員工每個人都有一部電話麼？

一般兩人一部電話，還可以通過RTX進行溝通。

你們每個人都知道出了問題應該找誰麼？

知道

你遇到過有人說“我以為…”麼？

有時候會遇到，但情況不多。

你們的項目組中所有的人都坐在一起麼？

沒有。全部座來分開，通過RTX即時通訊，郵件，電話進行溝通。

你們的進度表是否反映最新開發進展情況？

有及時準确的進度表，但不是每個項目成員都很容易看到。進度表有專門的基線和裡程碑的定義。

你們的工作量是先由每個人自己估算的麼？

不是開發人員自己估算，是有項目的估算小組進行估算。估算時候會适當考慮個體差異。

你們的開發人員從項目一開始就加班麼？

基本不會。

你們的項目計劃中Buffer Time是加在每個小任務後面的麼？

不是，總體進度有5-10%的餘量。

值得再多花一些時間，從95%做到100%好值得，非常值得。

尤其當項目後期人困馬乏的時候，要堅持。這會給産品帶來質的差別。

登記新缺陷時，是否寫清了重制步驟？

是的，有明确重制步驟描述，并配合螢幕截圖。

寫新代碼前會把已知缺陷解決麼？

要。每個人的缺陷不能超過10個或15個，否則必須先解決老的bug才能繼續寫新代碼。

你們對缺陷的輕重緩急有事先的約定麼？

缺陷有驗證性和解決時限的明确定義。

你們對意見不一的缺陷有三國會議麼？

有，意見不一緻的時候由項目的CCB進行統一讨論和決策。

所有的缺陷都是由登記的人最後關閉的麼？

是的，由BUG送出的測試人員來驗證關閉。

你們的程式員厭惡修改老的代碼麼？

厭惡是正常的。解決方法是組織Code Review，單獨留出時間來。XP也是一個方法。

你們項目組有Team Morale Activity麼？

有，一般一兩個月一次，一般在項目版本釋出後。

你們項目組有自己的Logo麼？

有系統的Logo,項目組沒有Logo.

你們的員工有印有公司Logo的T-Shirt麼？

沒有。

總經理至少每月參加次項目組會議要的。

有。一般在需要參加的時候參加。

你們是給每個Dev開一個分支麼？

沒有，隻有一個共有的開發分支，容易管理些。

有人長期不Check-In代碼麼？

不會，最長不會超過1周，一般要求是當天修改隻要能夠編譯通過都要Check In.

在Check-In代碼時都填寫注釋了麼？

有，Check-In的時候系統會自動對應到相關的活動或變更。

有沒有設定每天Check-In的最後期限？

不是特别明确，需要改進。

你們能把所有源碼一下子編譯成安裝檔案嗎？

是的，通過Nant自動編譯和打包，是以項目很容易進行Daily Build.

你們的項目組做每日編譯麼？

跟測試政策有關系，當項目計劃選擇的政策是每日建構時候就必須進行。

你們公司有沒有積累一個項目風險清單？

有，并在每周例會上對分析進行分析。

設計越簡單越好越簡單越好。

設計時候多一句話，将來可能就帶來無窮無盡的煩惱。應該從一開始就勇敢的砍。這叫scope management。

盡量利用現有的産品、技術、代碼千萬别什麼東西都自己Coding。BizTalk和Sharepoint就是最好的例子，有這兩個作為基礎，可以把起點提高很多。或者可以盡量多用現成的Control之類的。或者盡量用XML，而不是自己去Parse一個文本檔案；盡量用RegExp，而不是自己從頭操作字元串，等等等等。這就是“軟體複用”的展現。

你們會隔一段時間就停下來夯實代碼麼？

沒有，沒有專門的這種時間。

你們的項目組每個人都寫Daily Report麼？

沒有，當要求項目成員都有工作日志記錄。成員每天工作會回報到Project的工作日志上面。

你們的項目經理會發出Weekly Report麼？

有項目周報。内容包括目前進度，可能的風險，品質狀況，各種工作的進展等。

你們項目組是否至少每周全體開會一次？

每周項目都召開項目周例會。

你們項目組的會議、讨論都有記錄麼？

有，有專門的會議記錄人員。

其他部門知道你們項目組在幹什麼麼？

要發一些Newsflash給整個大組織。Show your team’s value。否則，當你坐在電梯裡面，其他部門的人問：“你們在幹嘛”，你回答“ABC項目”的時候，别人全然不知，那種感覺不太好。

通過Email進行所有正式溝通

是的。Email的好處是免得抵賴。但也要避免矯枉過正，最好的方法是先用電話和當面說，然後Email來确認。

為項目組建立多個Mailing Group

郵件隻有一個Group,但RTX及時通訊有多個Group.

每個人都知道哪裡可以找到全部的文檔麼？

知道。應該每個人都知道。這叫做知識管理（Knowledge Management）。最友善的就是把文檔放在一個集中的File Share，更好的方法是用Sharepoint。

你做決定、做變化時，告訴大家原因了麼？

要告訴大家原因。Empower team member的手段之一是提供足夠的information，這是MSF一開篇的幾個原則之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中國人做事喜歡搞限制，限制資訊，似乎能夠看到某一份檔案的人就是有身份的人。大錯特錯。權威、權力，不在于是不是能access information/data，而在于是不是掌握資源。

Stay agile and expect change 要這樣。

需求一定會變的，已經寫好的代碼一定會被要求修改的。做好心理準備，對change不要抗拒，而是expect change。

你們有沒有專職的軟體測試人員？

項目有專門得測試人員，一般配置比例在1比6個左右開發人員。

你們的測試有一份總的計劃來規定做什麼和怎麼做麼？這就是Test Plan。要不要做性能測試？要不要做Usability測試？什麼時候開始測試性能？測試通過的标準是什麼？用什麼手段，自動的還是手動的？這些問題需要用Test Plan來回答。

有專門得測試計劃。

你是先寫Test Case然後再測試的麼？

有專門得測試用例，要求測試必須根據測試用例進行。

你是否會為各種輸入組合建立測試用例？

這點項目組強調了測試資料得準備和路徑分支得分析，這塊做得不是很好待改進。

你們的程式員能看到測試用例麼？

可以，但開發人員不會特别去關注這些測試用例，一般根據軟體需求自測。

你們是否随便抓一些人來做易用性測試？

沒有，需求開發階段已經有标準得DEMO

你對自動測試的期望正确麼？

不期望自動測試，LoadRunner隻用來錄制簡單得冒煙測試腳本。

你們的性能測試是等所有功能都開發完才做的麼？

是的。需要改進。

你注意到測試中的殺蟲劑效應了麼？

蟲子有抗藥性，Bug也有。發現的新Bug越來越少是正常的。這時候，最好大家交換一下測試的area，或者用用看其他工具和手法，就又會發現一些新bug了。

你們項目組中有人能說出産品的目前整體品質情況麼？

要有。當老闆問起這個産品目前品質如何，Test Lead/Manager應該負責回答。

你們有單元測試麼？

有單元測試，但和自測，黑盒測試界限不明确。項目成員自測關注重點放到黑盒測試上了而忽略了百盒的分支，條件和代碼的覆寫。

你們的程式員是寫完代碼就扔過牆的麼？

不會必須自測通過。寫好一塊程式以後，即便不做單元測試，也應該自己先跑一跑。雖然有了專門的測試人員，做開發的人也不可以一點測試都不做。微軟還有Test Release Document的說法，程式太爛的話，測試有權踢回去。

你們的程式中所有的函數都有輸入檢查麼？

不要。雖然說做輸入檢查是write secure code的要點，但不要做太多的輸入檢查，有些内部函數之間的參數傳遞就不必檢查輸入了，省點功夫。同樣的道理，未必要給所有的函數都寫注釋。寫一部分主要的就夠了。

産品有統一的錯誤處理機制和報錯界面麼？

有，在項目中已經複用。最好能有統一的error message，然後每個error message都帶一個error number。這樣，使用者可以自己根據error number到user manual裡面去看看錯誤的具體描述和可能原因，就像SQL Server的錯誤那樣。同樣，ASP.NET也要有統一的Exception處理。可以參考有關的Application Block。

你們有統一的代碼書寫規範麼？

有專門的編碼規範文檔

你們的每個人都了解項目的商業意義麼？

要。這是Vision的意思。别把項目隻當成工作。有時候要想着自己是在為中國某某行業的資訊化作先驅者，或者時不時的告訴team member，這個項目能夠為某某某國家部門每年節省多少多少百萬的納稅人的錢，這樣就有動力了。平凡的事情也是可以有個崇高的目标的。

産品各部分的界面和操作習慣一緻麼？

基本一直，還在不斷改進中。

有可以作為宣傳亮點的Cool Feature麼？

有。工作流，權限模型，多層分布式架構，隊列使用，自我開發的資料通路元件都是可以宣傳的亮點。

盡可能縮短産品的啟動時間要這樣。

軟體啟動時間（Start-Up time）是客戶對性能好壞的第一印象。

不要過于注重内在品質而忽視了第一眼的外在印象程式員容易犯這個錯誤：太看重性能、穩定性、存儲效率，但忽視了外在感受。而高層經理、客戶正相反。這兩方面要兼顧，協調這些是PM的工作。

你們根據詳細産品功能說明書做開發麼？

要這樣。要有設計才能開發，這是必須的。設計文檔，應該說清楚這個産品會怎麼運作，應該采取一些講故事的方法。設計的時候千萬别鑽細節，别鑽到資料庫、代碼等具體實作裡面去，那些是後面的事情，一步步來不能着急。

開始開發和測試之前每個人都仔細審閱功能設計麼？

有專門的同行評審和多人複審。

Dev工作的劃分是單純縱向或橫向的麼？

不能單純的根據功能子產品分，或者單純根據表現層、中間層、資料庫層分。我推薦這麼做：首先根據功能子產品分，然後每個“層”都有一個Owner來Review所有人的設計和代碼，保證consistency。

項目是根據功能來分的，按層來分還需要進一步實踐。

你們的程式員寫程式設計說明文檔麼？

有設計文檔輸出，但用處不大，更多設計内容直接展現在代碼注釋中。

你在招人面試時讓他寫一段程式麼？

沒有，一般以問為主。

你們有沒有技術交流講座？

有，每個項目版本都有1到2次技術交流，教育訓練和讨論。

你們的程式員都能專注于一件事情麼？

要讓程式員專注一件事。例如說，一個部門有兩個項目和10個人，一種方法是讓10個人同時參加兩個項目，每個項目上每個人都花50%時間；另一種方法是5個人去項目A，5個人去項目B，每個人都100%在某一個項目上。我一定選後面一種。這個道理很多人都懂，但很多上司實踐起來就把屬下當成可以任意拆分的資源了。

你們的程式員會誇大完成某項工作所需要的時間麼？

會的，這是常見的，尤其會在項目後期誇大做某個change所需要的時間，以次來抵制change。解決的方法是坐下來慢慢磨，磨掉程式員的逆反心理，一起分析，并把估算時間的顆粒度變小。

比較少跨大的情況，因為跨大必須要說明明确的理由。

75. 盡量不要用Virtual Heads 最好不要用Virtual Heads。

Virtual heads意味着resource is not secure，shared resource會降低resource的工作效率，容易增加出錯的機會，會讓一心二用的人沒有太多時間去review spec、review design。一個dedicated的人，要強過兩個隻能投入50%時間和精力的人。我是吃過虧的：7個part time的tester，發現的Bug和幹的活，加起來還不如兩個full-time的。參見第73條。73條是針對程式員的，75條是針對Resource Manager的。