引用 如何用正確的方法來寫出質量好的軟件的75條體會

引用

沈某  的   如何用正確的方法來寫出質量好的軟件的75條體會

1. 大家的項目組使用源代碼管理工具了麼？

應該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly均可以。個人選擇是VSS。

 2. 大家的項目組使用缺陷管理系統了麼？

應該用。ClearQuest太複雜，個人推薦是BugZilla。

3. 大家的測試組還在用Word寫測試用例麼？

不要用Word寫測試用例（Test Case）。應該用一個專門的系統，能夠是Test Manager，也能夠是本身開發一個ASP.NET的小網站。主要目的是Track和Browse。

4. 大家的項目組有沒有創建一個門戶網站？

要有一個門戶網站，用來放Contact Info、Baselined Schedule、News等等。推薦Sharepoint Portal Server 2003來實現，15分鐘就搞定。買不起SPS 2003能夠用WSS (Windows Sharepoint Service)。

5. 大家的項目組用了你能買到最好的工具麼？

應該用盡可能好的工具來工做。好比，應該用VS.NET而不是Notepad來寫C#。用Notepad寫程序多半隻是一種炫耀。但也要考慮到經費，因此說是「你能買到最好的」。

6. 大家的程序員工做在安靜的環境裏麼？

須要安靜環境。這點極端重要，並且要保證每一個人的空間大於必定面積。

7. 大家的員工每一個人都有一部電話麼？須要每人一部電話。並且電話最好是帶留言功能的。固然，上這麼一套帶留言電話系統開銷不小。不過至少每人一部電話要有，千萬別搞得常常有人站起來喊：「某某某電話」。《人件》裏面就強烈譴責這種作法。

8. 大家每一個人都知道出了問題應該找誰麼？

應該知道。任何一個Feature至少都應該有一個Owner，固然，Owner能夠繼續Dispatch給其餘人。

 9. 你遇到過有人說「我覺得…」麼？

要消滅「我覺得」。Never assume anything。

10. 大家的項目組中全部的人都坐在一塊兒麼？

須要。我反對Virtual Team，也反對Dev在美國、Test在中國這種開發方式。能坐在一塊兒就最好坐在一塊兒，好處多得不得了。

11. 大家的進度表是否反映最新開發進展狀況？

應該反映。可是，應該用Baseline的方法來管理進度表：維護一份穩定的Schedule，再維護一份最新更改。Baseline的方法也應該用於其它的Spec。Baseline是變動管理裏面的一個重要手段。

 12. 大家的工做量是先由每一個人本身估算的麼？

應該讓每一個人本身估算。要從下而上估算工做量，而不是從上往下分派。除非有其餘緣由，好比政治任務工期固定等。

13. 大家的開發人員從項目一開始就加班麼？

不要這樣。不要一開始就搞疲勞戰。從項目一開始就加班，只能說明項目進度不合理。固然，一些對日軟件外包必須每天加班，那屬於剝削的範疇。

14. 大家的項目計劃中Buffer Time是加在每一個小任務後面的麼？

不要。Buffer Time加在每一個小任務後面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個Milestone或者checkpoint前面。

15. 值得再多花一些時間，從95%作到100%好值得，很是值得。

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

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

要。這屬於Dev和Test之間的溝通手段。面對面溝通須要，詳細填寫Repro Steps也須要。

17. 寫新代碼前會把已知缺陷解決麼？要。每一個人的缺陷不能超過10個或15個，不然必須先解決老的bug才能繼續寫新代碼。

18. 大家對缺陷的輕重緩急有事先的約定麼？

必須有定義。Severity要分一、二、3，約定好：藍屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但這種約定能夠根據產品質量現狀適當進行調整。

 19. 大家對意見不一的缺陷有三國會議麼？必需要有。要有一個明確的決策過程。這相似於CCB (Change Control Board)的概念。

20. 全部的缺陷都是由登記的人最後關閉的麼？

Bug應該由Opener關閉。Dev不能私自關閉Bug。

21. 大家的程序員厭惡修改老的代碼麼？

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

22. 大家項目組有Team Morale Activity麼？

每月都要搞一次，吃飯、唱歌、Outing、打球、開卡丁車等等，必定要有。不要剩這些錢。

23. 大家項目組有本身的Logo麼？

要有本身的Logo。至少應該有本身的Codename。

24. 大家的員工有印有公司Logo的T-Shirt麼？

要有。能加強歸屬感。固然，T-Shirt要作的好看一些，最好用80支的棉來作。別沒穿幾回就破破爛爛的。

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

要讓team member以爲高層關注這個項目。

26. 大家是給每一個Dev開一個分支麼？

反對。Branch的管理以及Merge的工做量太大，並且容易出錯。

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

不能夠。對大部分項目來講，最多兩三天就應該Check-In。

28. 在Check-In代碼時都填寫註釋了麼？

要寫的，至少一兩句話，好比「解決了Bug No.225」。若是往高處拔，這也算作「配置審計」的一部分。

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

要的，要明確Check-In Deadline。不然會Build Break。

30. 大家能把全部源碼一會兒編譯成安裝文件嗎？

要的。這是每日編譯（Daily Build）的基礎。並且必需要可以作成自動的。

31. 大家的項目組作每日編譯麼？

固然要作。有三樣東西是軟件項目/產品開發必備的：1. bug management; 2. source control; 3. daily build。

32. 大家公司有沒有積累一個項目風險列表？

要。Risk Inventory。不然，下個項目開始的時候，又只能拍腦殼分析Risk了。

 33. 設計越簡單越好越簡單越好。

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

34. 儘可能利用現有的產品、技術、代碼千萬別什麼東西都本身Coding。BizTalk和Sharepoint就是最好的例子，有這兩個做爲基礎，能夠把起點提升不少。或者能夠儘可能多用現成的Control之類的。或者儘可能用XML，而不是本身去Parse一個文本文件；儘可能用RegExp，而不是本身從頭操做字符串，等等等等。這就是「軟件複用」的體現。

35. 大家會隔一段時間就停下來夯實代碼麼？

要。最好一個月左右一次。傳言去年年初Windows組在Stevb的命令下停過一個月加強安全。Btw，「夯」這個字念「hang」，第一聲。

36. 大家的項目組每一個人都寫Daily Report麼？

要寫。五分鐘就夠了，寫10句話左右，告訴本身小組的人今天我幹了什麼。一則爲了溝通，二則鞭策本身（要是不務正業一天，本身都會很差意思寫的）。

 37. 大家的項目經理會發出Weekly Report麼？

要。也是爲了溝通。內容包括目前進度，可能的風險，質量情況，各類工做的進展等。

 38. 大家項目組是否至少每週全體開會一次？

要。必定要開會。程序員討厭開會，但每一個禮拜開會時間加起來至少應該有4小時。包括team meeting, spec review meeting, bug triage meeting。千萬別你們悶頭寫code。

39. 大家項目組的會議、討論都有記錄麼？

會前發meeting request和agenda，會中有人負責主持和記錄，會後有人負責發meeting minutes，這都是effective meeting的要點。並且，每一個會議都要造成agreements和action items。

 40. 其餘部門知道大家項目組在幹什麼麼？

要發一些Newsflash給整個大組織。Show your team’s value。不然，當你坐在電梯裏面，其餘部門的人問：「大家在幹嗎」，你回答「ABC項目」的時候，別人全然不知，那種感受不太好。

41. 經過Email進行全部正式溝通

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

42. 爲項目組創建多個Mailing Group

若是在AD+Exchange裏面，就建Distribution List。好比，我會建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。這樣發起Email來方便，並且能讓該收到email的人都收到、不應收到不被騷擾。

43. 每一個人都知道哪裏能夠找到所有的文檔麼？

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

44. 你作決定、作變化時，告訴你們緣由了麼？

要告訴你們緣由。Empower team member的手段之一是提供足夠的information，這是MSF一開篇的幾個原則之一。的確如此，tell me why是人之常情，tell me why了纔能有understanding。中國人作事喜歡搞限制，限制信息，彷佛可以看到某一份文件的人就是有身份的人。大錯特錯。權威、權力，不在因而不是能access information/data，而在因而不是掌握資源。

45. Stay agile and expect change 要這樣。

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

46. 大家有沒有專職的軟件測試人員？

要有專職測試。若是人手不夠，能夠peer test，交換了測試。千萬別本身測試本身的。

47. 大家的測試有一份總的計劃來規定作什麼和怎麼作麼？這就是Test Plan。要不要作性能測試？要不要作Usability測試？何時開始測試性能？測試經過的標準是什麼？用什麼手段，自動的仍是手動的？這些問題須要用Test Plan來回答。

 48. 你是先寫Test Case而後再測試的麼？

應該如此。應該先設計再編程、先test case再測試。固然，事情是靈活的。我有時候在作第一遍測試的同時補上test case。至於先test case再開發，我不喜歡，由於不習慣，太麻煩，至於別人推薦，那試試看也無妨。

49. 你是否會爲各類輸入組合建立測試用例？

不要，不要搞邊界條件組合。小心組合爆炸。有不少test case工具可以自動生成各類邊界條件的組合——但要想清楚，你是否有時間去運行那麼多test case。

50. 大家的程序員能看到測試用例麼？

要。讓Dev看到Test Case吧。咱們都是爲了同一個目的走到一塊兒來的：提升質量。

 51. 大家是否隨便抓一些人來作易用性測試？

要這麼作。本身看本身寫的程序界面，怎麼看都是順眼的。這叫作審美疲勞——臭的看久了也就不臭了，不方便的永久了也就習慣了。

52. 你對自動測試的指望正確麼？

別指望過高。依我看，除了性能測試之外，仍是暫時先忘掉「自動測試」吧，忘掉WinRunner和LoadRunner吧。對於國內的軟件測試的現狀來講，只能「矯枉必須過正」了。

53. 大家的性能測試是等全部功能都開發完才作的麼？

不能這樣。性能測試不能被歸到所謂的「系統測試」階段。早測早改正，早死早昇天。

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

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

 55. 大家項目組中有人能說出產品的當前總體質量狀況麼？

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

56. 大家有單元測試麼？

單元測試要有的。不過沒有單元測試也不是不能夠，我作過沒有單元測試的項目，也作成功了——多是僥倖，多是你們都是熟手的關係。仍是那句話，軟件工程是很是實踐、很是工程、很是靈活的一套方法，某些方法在某些狀況下會比另外一些方法好，反之亦然。

57. 大家的程序員是寫完代碼就扔過牆的麼？

大忌。寫好一塊程序之後，即使不作單元測試，也應該本身先跑一跑。雖然有了專門的測試人員，作開發的人也不能夠一點測試都不作。微軟還有Test Release Document的說法，程序太爛的話，測試有權踢回去。

 58. 大家的程序中全部的函數都有輸入檢查麼？

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

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

要有。最好能有統一的error message，而後每一個error message都帶一個error number。這樣，用戶能夠本身根據error number到user manual裏面去看看錯誤的具體描述和可能緣由，就像SQL Server的錯誤那樣。一樣，ASP.NET也要有統一的Exception處理。能夠參考有關的Application Block。

60. 大家有統一的代碼書寫規範麼？

要有。Code Convention不少，搞一份來發給你們就能夠了。固然，要是有FxCop這種工具來檢查代碼就更好了。

61. 大家的每一個人都瞭解項目的商業意義麼？

要。這是Vision的意思。別把項目只當成工做。有時候要想着本身是在爲中國某某行業的信息化做先驅者，或者時不時的告訴team member，這個項目可以爲某某某國家部門每一年節省多少多少百萬的納稅人的錢，這樣就有動力了。平凡的事情也是能夠有個崇高的目標的。

 62. 產品各部分的界面和操做習慣一致麼？

要這樣。要讓用戶以爲整個程序好像是一我的寫出來的那樣。

 63. 有能夠做爲宣傳亮點的Cool Feature麼？

要。這是加強團隊凝聚力、信心的。並且，「一俊遮百醜」，有亮點就能夠掩蓋一些問題。這樣，對於客戶來講，會感受產品從質量角度來講仍是acceptable的。或者說，cool feature或者說亮點能夠做爲質量問題的一個過後彌補措施。

64. 儘量縮短產品的啓動時間要這樣。

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

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

 66. 大家根據詳細產品功能說明書作開發麼？

要這樣。要有設計才能開發，這是必須的。設計文檔，應該說清楚這個產品會怎麼運行，應該採起一些講故事的方法。設計的時候千萬別鑽細節，別鑽到數據庫、代碼等具體實現裏面去，那些是後面的事情，一步步來不能着急。

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

要作。Function Spec review是用來統一思想的。並且，review過之後造成了一致意見，未來再也沒有人能夠說「你看，當初我就是反對這麼設計的，如今吃苦頭了吧」

68. 全部人都始終想着The Whole Image麼？要這樣。項目裏面每一個人雖然都只是在製造一片葉子，但每一個人都應該知道本身在製造的那片葉子所在的樹是怎麼樣子的。我反對軟件藍領，反對過度的把軟件製造當作流水線、車間。參見第61條。

 69. Dev工做的劃分是單純縱向或橫向的麼？

不能單純的根據功能模塊分，或者單純根據表現層、中間層、數據庫層分。我推薦這麼作：首先根據功能模塊分，而後每一個「層」都有一個Owner來Review全部人的設計和代碼，保證consistency。

70. 大家的程序員寫程序設計說明文檔麼？

要。不過我據說微軟的程序員1999年之前也不寫。因此說，寫不寫也不是絕對的，偷懶有時候也是能夠的。參見第56條。

 71. 你在招人面試時讓他寫一段程序麼？

要的。我最喜歡讓人作字符串和鏈表一類的題目。這種題目有不少循環、判斷、指針、遞歸等，既不偏向過於考算法，也不偏向過於考特定的API。

72. 大家有沒有技術交流講座？

要的。每一兩個禮拜搞一次內部的Tech Talk或者Chalk Talk吧。讓組員之間分享技術心得，這筆花錢送到外面去培訓划算。

73. 大家的程序員都能專一於一件事情麼？

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

74. 大家的程序員會誇大完成某項工做所須要的時間麼？

會的，這是常見的，尤爲會在項目後期誇大作某個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的。