?? 如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).htm
字號(hào):
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0052)http://pop.pcpop.com/showtopic.aspx?topic_id=1148571 -->
<HTML><HEAD><TITLE>PCPOP-電腦時(shí)尚-泡泡社區(qū)-貼子內(nèi)容</TITLE>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content=no http-equiv=imagetoolbar><LINK
href="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/css.css" rel=stylesheet type=text/css>
<META content="MSHTML 5.00.2920.0" name=GENERATOR>
<META content="Visual Basic 7.0" name=CODE_LANGUAGE>
<META content=JavaScript name=vs_defaultClientScript>
<META content=http://schemas.microsoft.com/intellisense/ie5
name=vs_targetSchema>
<SCRIPT src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/openWindow.js"></SCRIPT>
<!--<body bgColor="">--></HEAD>
<BODY bgColor=#deefff>
<FORM action=showtopic.aspx?topic_id=1148571 encType=multipart/form-data id=frm
method=post name=frm onkeydown=ctlent()><INPUT name=__VIEWSTATE type=hidden
value=dDwxODE4NTg1OTA2Ozs+> <SPAN id=isrefresh></SPAN><SPAN id=errMessage
style="COLOR: #ff0000"></SPAN>
<DIV id=panShowtopic>
<P>標(biāo)題：<SPAN id=lblSubject>如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì)！by石魚 [點(diǎn)2674/回52] [<A
href="http://pop.pcpop.com/showtopic.aspx?topic_id=1148571"
target=_blank>新開窗口閱讀</A>]</SPAN> <SPAN id=lblTopicTools><BR>功能：[<A
href="http://pop.pcpop.com/showtopic.aspx?topic_id=1148571#replyform">回復(fù)此帖</A>]
[<A href="http://pop.pcpop.com/FavoriteAdd.aspx?topic_id=1148571"
onclick="javascript:return callpage2(this.href);">收藏此帖</A>] [<A
href="http://pop.pcpop.com/card.aspx?topic_id=1148571&type=list"
onclick="javascript:return callpage(this.href);">使用卡片</A>] [<A
onclick="javascript:window.open('lawsuit.aspx?topic_id=1148571','info','scrollbars=1,resizable=1,height=200,width=380,left=100,top=0')"
style="CURSOR: hand"><FONT color=red>違規(guī)舉報(bào)</FONT></A>] <BR></SPAN></P>
<CENTER>
<SCRIPT src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/hp468.js"></SCRIPT>
<OBJECT classid=clsid:D27CDB6E-AE6D-11cf-96B8-444553540000
codeBase=http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,29,0
height=60 width=468><PARAM NAME="movie" VALUE="http://www.pcpop.com/banner/dell468.swf"><PARAM NAME="quality" VALUE="high">
<embed src="http://www.pcpop.com/banner/dell468.swf"
quality="high" pluginspage="http://www.macromedia.com/go/getflashplayer"
type="application/x-shockwave-flash" width="468"
height="60"></embed></OBJECT></CENTER>
<HR>
<BR>[<A href="http://www.pcpop.com/" target=_blank>每日必看</A>] <SPAN
id=lblMessage>我把內(nèi)容帖出來了，強(qiáng)烈推薦(不僅僅是程序員的事啊)：</SPAN><!--加入投票選項(xiàng)--> <!--投票選項(xiàng)結(jié)束--><SPAN
id=lblTopicLabel><BR><IMG
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/1067019359200451297547349.gif"></SPAN> <BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<SPAN id=lblName><A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A></SPAN>
<SPAN id=spanEdit></SPAN>發(fā)帖時(shí)間： <SPAN id=lblDate>2004-8-3 16:8:38</SPAN><FONT
color=#c0c0c0><SPAN id=spanPostIp>
</SPAN></FONT><BR><BR>回復(fù)[1]：1. 你們的項(xiàng)目組使用源代碼管理工具了么？ <BR>應(yīng)該用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的選擇是VSS。 <BR><BR>2. 你們的項(xiàng)目組使用缺陷管理系統(tǒng)了么？ <BR>應(yīng)該用。ClearQuest太復(fù)雜，我的推薦是BugZilla。 <BR><BR>3. 你們的測(cè)試組還在用Word寫測(cè)試用例么？ <BR>不要用Word寫測(cè)試用例（Test Case）。應(yīng)該用一個(gè)專門的系統(tǒng)，可以是Test Manager，也可以是自己開發(fā)一個(gè)ASP.NET的小網(wǎng)站。主要目的是Track和Browse。 <BR><BR>4. 你們的項(xiàng)目組有沒有建立一個(gè)門戶網(wǎng)站？ <BR>要有一個(gè)門戶網(wǎng)站，用來放Contact Info、Baselined Schedule、News等等。推薦Sharepoint Portal Server 2003來實(shí)現(xiàn)，15分鐘就搞定。買不起SPS 2003可以用WSS (Windows Sharepoint Service)。 <BR><BR>5. 你們的項(xiàng)目組用了你能買到最好的工具么？ <BR>應(yīng)該用盡量好的工具來工作。比如，應(yīng)該用VS.NET而不是Notepad來寫C#。用Notepad寫程序多半只是一種炫耀。但也要考慮到經(jīng)費(fèi)，所以說是“你能買到最好的”。 <BR><BR>6. 你們的程序員工作在安靜的環(huán)境里么？ <BR>需要安靜環(huán)境。這點(diǎn)極端重要，而且要保證每個(gè)人的空間大于一定面積。 <BR><BR>7. 你們的員工每個(gè)人都有一部電話么？ <BR>需要每人一部電話。而且電話最好是帶留言功能的。當(dāng)然，上這么一套帶留言電話系統(tǒng)開銷不小。不過至少每人一部電話要有，千萬別搞得經(jīng)常有人站起來喊：“某某某電話”。《人件》里面就強(qiáng)烈譴責(zé)這種做法。 <BR><BR>8. 你們每個(gè)人都知道出了問題應(yīng)該找誰么？ <BR>應(yīng)該知道。任何一個(gè)Feature至少都應(yīng)該有一個(gè)Owner，當(dāng)然，Owner可以繼續(xù)Dispatch給其他人。 <BR><BR>9. 你遇到過有人說“我以為…”么？ <BR>要消滅“我以為”。Never assume anything。 <BR><BR>10. 你們的項(xiàng)目組中所有的人都坐在一起么？ <BR>需要。我反對(duì)Virtual Team，也反對(duì)Dev在美國(guó)、Test在中國(guó)這種開發(fā)方式。能坐在一起就最好坐在一起，好處多得不得了。 <BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[2]：11. 你們的進(jìn)度表是否反映最新開發(fā)進(jìn)展情況？ <BR>應(yīng)該反映。但是，應(yīng)該用Baseline的方法來管理進(jìn)度表：維護(hù)一份穩(wěn)定的Schedule，再維護(hù)一份最新更改。Baseline的方法也應(yīng)該用于其它的Spec。Baseline是變更管理里面的一個(gè)重要手段。 <BR><BR>12. 你們的工作量是先由每個(gè)人自己估算的么？ <BR>應(yīng)該讓每個(gè)人自己估算。要從下而上估算工作量，而不是從上往下分派。除非有其他原因，比如政治任務(wù)工期固定等。 <BR><BR>13. 你們的開發(fā)人員從項(xiàng)目一開始就加班么？ <BR>不要這樣。不要一開始就搞疲勞戰(zhàn)。從項(xiàng)目一開始就加班，只能說明項(xiàng)目進(jìn)度不合理。當(dāng)然，一些對(duì)日軟件外包必須天天加班，那屬于剝削的范疇。 <BR><BR>14. 你們的項(xiàng)目計(jì)劃中Buffer Time是加在每個(gè)小任務(wù)后面的么？ <BR>不要。Buffer Time加在每個(gè)小任務(wù)后面，很容易輕易的就被消耗掉。Buffer Time要整段的加在一個(gè)Milestone或者checkpoint前面。 <BR><BR>15. 值得再多花一些時(shí)間，從95%做到100%好 <BR>值得，非常值得。尤其當(dāng)項(xiàng)目后期人困馬乏的時(shí)候，要堅(jiān)持。這會(huì)給產(chǎn)品帶來質(zhì)的區(qū)別。 <BR><BR>16. 登記新缺陷時(shí)，是否寫清了重現(xiàn)步驟？ <BR>要。這屬于Dev和Test之間的溝通手段。面對(duì)面溝通需要，詳細(xì)填寫Repro Steps也需要。 <BR><BR>17. 寫新代碼前會(huì)把已知缺陷解決么？ <BR>要。每個(gè)人的缺陷不能超過10個(gè)或15個(gè)，否則必須先解決老的bug才能繼續(xù)寫新代碼。 <BR><BR>18. 你們對(duì)缺陷的輕重緩急有事先的約定么？ <BR>必須有定義。Severity要分1、2、3，約定好：藍(lán)屏和Data Lost算Sev 1，F(xiàn)unction Error算Sev 2，界面上的算Sev 3。但這種約定可以根據(jù)產(chǎn)品質(zhì)量現(xiàn)狀適當(dāng)進(jìn)行調(diào)整。 <BR><BR>19. 你們對(duì)意見不一的缺陷有三國(guó)會(huì)議么？ <BR>必須要有。要有一個(gè)明確的決策過程。這類似于CCB (Change Control Board)的概念。 <BR><BR>20. 所有的缺陷都是由登記的人最后關(guān)閉的么？ <BR>Bug應(yīng)該由Opener關(guān)閉。Dev不能私自關(guān)閉Bug。 <BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[3]：繼續(xù)~~<BR><A href="http://www.pcpop.com/" target=_blank><IMG
border=0 src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067120156')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>發(fā)霉的保鮮劑</FONT></A>
<BR><BR>回復(fù)[4]：21. 你們的程序員厭惡修改老的代碼么？ <BR>厭惡是正常的。解決方法是組織Code Review，單獨(dú)留出時(shí)間來。XP也是一個(gè)方法。 <BR><BR>22. 你們項(xiàng)目組有Team Morale Activity么？ <BR>每個(gè)月都要搞一次，吃飯、唱歌、Outing、打球、開卡丁車等等，一定要有。不要剩這些錢。 <BR><BR>23. 你們項(xiàng)目組有自己的Logo么？ <BR>要有自己的Logo。至少應(yīng)該有自己的Codename。 <BR><BR>24. 你們的員工有印有公司Logo的T-Shirt么？ <BR>要有。能增強(qiáng)歸屬感。當(dāng)然，T-Shirt要做的好看一些，最好用80支的棉來做。別沒穿幾次就破破爛爛的。 <BR><BR>25. 總經(jīng)理至少每月參加次項(xiàng)目組會(huì)議 <BR>要的。要讓team member覺得高層關(guān)注這個(gè)項(xiàng)目。 <BR><BR>26. 你們是給每個(gè)Dev開一個(gè)分支么？ <BR>反對(duì)。Branch的管理以及Merge的工作量太大，而且容易出錯(cuò)。 <BR><BR>27. 有人長(zhǎng)期不Check-In代碼么？ <BR>不可以。對(duì)大部分項(xiàng)目來說，最多兩三天就應(yīng)該Check-In。 <BR><BR>28. 在Check-In代碼時(shí)都填寫注釋了么？ <BR>要寫的，至少一兩句話，比如“解決了Bug No.225”。如果往高處拔，這也算做“配置審計(jì)”的一部分。 <BR><BR>29. 有沒有設(shè)定每天Check-In的最后期限？ <BR>要的，要明確Check-In Deadline。否則會(huì)Build Break。 <BR><BR>30. 你們能把所有源碼一下子編譯成安裝文件嗎？ <BR>要的。這是每日編譯（Daily Build）的基礎(chǔ)。而且必須要能夠做成自動(dòng)的。 <BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[5]：31. 你們的項(xiàng)目組做每日編譯么？ <BR>當(dāng)然要做。有三樣?xùn)|西是軟件項(xiàng)目/產(chǎn)品開發(fā)必備的：1. bug management; 2. source control; 3. daily build。 <BR><BR>32. 你們公司有沒有積累一個(gè)項(xiàng)目風(fēng)險(xiǎn)列表？ <BR>要。Risk Inventory。否則，下個(gè)項(xiàng)目開始的時(shí)候，又只能拍腦袋分析Risk了。 <BR><BR>33. 設(shè)計(jì)越簡(jiǎn)單越好 <BR>越簡(jiǎn)單越好。設(shè)計(jì)時(shí)候多一句話，將來可能就帶來無窮無盡的煩惱。應(yīng)該從一開始就勇敢的砍。這叫scope management。 <BR><BR>34. 盡量利用現(xiàn)有的產(chǎn)品、技術(shù)、代碼 <BR>千萬別什么東西都自己Coding。BizTalk和Sharepoint就是最好的例子，有這兩個(gè)作為基礎(chǔ)，可以把起點(diǎn)提高很多。或者可以盡量多用現(xiàn)成的Control之類的。或者盡量用XML，而不是自己去Parse一個(gè)文本文件；盡量用RegExp，而不是自己從頭操作字符串，等等等等。這就是“軟件復(fù)用”的體現(xiàn)。 <BR><BR>35. 你們會(huì)隔一段時(shí)間就停下來夯實(shí)代碼么？ <BR>要。最好一個(gè)月左右一次。傳言去年年初Windows組在Stevb的命令下停過一個(gè)月增強(qiáng)安全。Btw，“夯”這個(gè)字念“hang”，第一聲。 <BR><BR>36. 你們的項(xiàng)目組每個(gè)人都寫Daily Report么？ <BR>要寫。五分鐘就夠了，寫10句話左右，告訴自己小組的人今天我干了什么。一則為了溝通，二則鞭策自己（要是游手好閑一天，自己都會(huì)不好意思寫的）。 <BR><BR>37. 你們的項(xiàng)目經(jīng)理會(huì)發(fā)出Weekly Report么？ <BR>要。也是為了溝通。內(nèi)容包括目前進(jìn)度，可能的風(fēng)險(xiǎn)，質(zhì)量狀況，各種工作的進(jìn)展等。 <BR><BR>38. 你們項(xiàng)目組是否至少每周全體開會(huì)一次？ <BR>要。一定要開會(huì)。程序員討厭開會(huì)，但每個(gè)禮拜開會(huì)時(shí)間加起來至少應(yīng)該有4小時(shí)。包括team meeting, spec review meeting, bug triage meeting。千萬別大家悶頭寫code。 <BR><BR>39. 你們項(xiàng)目組的會(huì)議、討論都有記錄么？ <BR>會(huì)前發(fā)meeting request和agenda，會(huì)中有人負(fù)責(zé)主持和記錄，會(huì)后有人負(fù)責(zé)發(fā)meeting minutes，這都是effective meeting的要點(diǎn)。而且，每個(gè)會(huì)議都要形成agreements和action items。 <BR><BR>40. 其他部門知道你們項(xiàng)目組在干什么么？ <BR>要發(fā)一些Newsflash給整個(gè)大組織。Show your team’s value。否則，當(dāng)你坐在電梯里面，其他部門的人問：“你們?cè)诟陕铩保慊卮稹癆BC項(xiàng)目”的時(shí)候，別人全然不知，那種感覺不太好。 <BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[6]：41. 通過Email進(jìn)行所有正式溝通 <BR>Email的好處是免得抵賴。但也要避免矯枉過正，最好的方法是先用電話和當(dāng)面說，然后Email來確認(rèn)。 <BR><BR>42. 為項(xiàng)目組建立多個(gè)Mailing Group <BR>如果在AD+Exchange里面，就建Distribution List。比如，我會(huì)建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。這樣發(fā)起Email來方便，而且能讓該收到email的人都收到、不該收到不被騷擾。 <BR><BR>43. 每個(gè)人都知道哪里可以找到全部的文檔么？ <BR>應(yīng)該每個(gè)人都知道。這叫做知識(shí)管理（Knowledge Management）。最方便的就是把文檔放在一個(gè)集中的File Share，更好的方法是用Sharepoint。 <BR><BR>44. 你做決定、做變化時(shí)，告訴大家原因了么？ <BR>要告訴大家原因。Empower team member的手段之一是提供足夠的information，這是MSF一開篇的幾個(gè)原則之一。的確如此，tell me why是人之常情，tell me why了才能有understanding。中國(guó)人做事喜歡搞限制，限制信息，似乎能夠看到某一份文件的人就是有身份的人。大錯(cuò)特錯(cuò)。權(quán)威、權(quán)力，不在于是不是能access information/data，而在于是不是掌握資源。 <BR><BR>45. Stay agile and expect change <BR>要這樣。需求一定會(huì)變的，已經(jīng)寫好的代碼一定會(huì)被要求修改的。做好心理準(zhǔn)備，對(duì)change不要抗拒，而是expect change。 <BR><BR>46. 你們有沒有專職的軟件測(cè)試人員？ <BR>要有專職測(cè)試。如果人手不夠，可以peer test，交換了測(cè)試。千萬別自己測(cè)試自己的。 <BR><BR>47. 你們的測(cè)試有一份總的計(jì)劃來規(guī)定做什么和怎么做么？ <BR>這就是Test Plan。要不要做性能測(cè)試？要不要做Usability測(cè)試？什么時(shí)候開始測(cè)試性能？測(cè)試通過的標(biāo)準(zhǔn)是什么？用什么手段，自動(dòng)的還是手動(dòng)的？這些問題需要用Test Plan來回答。 <BR><BR>48. 你是先寫Test Case然后再測(cè)試的么？ <BR>應(yīng)該如此。應(yīng)該先設(shè)計(jì)再編程、先test case再測(cè)試。當(dāng)然，事情是靈活的。我有時(shí)候在做第一遍測(cè)試的同時(shí)補(bǔ)上test case。至于先test case再開發(fā)，我不喜歡，因?yàn)椴涣?xí)慣，太麻煩，至于別人推薦，那試試看也無妨。 <BR><BR>49. 你是否會(huì)為各種輸入組合創(chuàng)建測(cè)試用例？ <BR>不要，不要搞邊界條件組合。當(dāng)心組合爆炸。有很多test case工具能夠自動(dòng)生成各種邊界條件的組合——但要想清楚，你是否有時(shí)間去運(yùn)行那么多test case。 <BR><BR>50. 你們的程序員能看到測(cè)試用例么？ <BR>要。讓Dev看到Test Case吧。我們都是為了同一個(gè)目的走到一起來的：提高質(zhì)量。 <BR><BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[7]：51. 你們是否隨便抓一些人來做易用性測(cè)試？ <BR>要這么做。自己看自己寫的程序界面，怎么看都是順眼的。這叫做審美疲勞——臭的看久了也就不臭了，不方便的永久了也就習(xí)慣了。 <BR><BR>52. 你對(duì)自動(dòng)測(cè)試的期望正確么？ <BR>別期望太高。依我看，除了性能測(cè)試以外，還是暫時(shí)先忘掉“自動(dòng)測(cè)試”吧，忘掉WinRunner和LoadRunner吧。對(duì)于國(guó)內(nèi)的軟件測(cè)試的現(xiàn)狀來說，只能“矯枉必須過正”了。 <BR><BR>53. 你們的性能測(cè)試是等所有功能都開發(fā)完才做的么？ <BR>不能這樣。性能測(cè)試不能被歸到所謂的“系統(tǒng)測(cè)試”階段。早測(cè)早改正，早死早升天。 <BR><BR>54. 你注意到測(cè)試中的殺蟲劑效應(yīng)了么？ <BR>蟲子有抗藥性，Bug也有。發(fā)現(xiàn)的新Bug越來越少是正常的。這時(shí)候，最好大家交換一下測(cè)試的area，或者用用看其他工具和手法，就又會(huì)發(fā)現(xiàn)一些新bug了。 <BR><BR>55. 你們項(xiàng)目組中有人能說出產(chǎn)品的當(dāng)前整體質(zhì)量情況么？ <BR>要有。當(dāng)老板問起這個(gè)產(chǎn)品目前質(zhì)量如何，Test Lead/Manager應(yīng)該負(fù)責(zé)回答。 <BR><BR>56. 你們有單元測(cè)試么？ <BR>單元測(cè)試要有的。不過沒有單元測(cè)試也不是不可以，我做過沒有單元測(cè)試的項(xiàng)目，也做成功了——可能是僥幸，可能是大家都是熟手的關(guān)系。還是那句話，軟件工程是非常實(shí)踐、非常工程、非常靈活的一套方法，某些方法在某些情況下會(huì)比另一些方法好，反之亦然。 <BR><BR>57. 你們的程序員是寫完代碼就扔過墻的么？ <BR>大忌。寫好一塊程序以后，即便不做單元測(cè)試，也應(yīng)該自己先跑一跑。雖然有了專門的測(cè)試人員，做開發(fā)的人也不可以一點(diǎn)測(cè)試都不做。微軟還有Test Release Document的說法，程序太爛的話，測(cè)試有權(quán)踢回去。 <BR><BR>58. 你們的程序中所有的函數(shù)都有輸入檢查么？ <BR>不要。雖然說做輸入檢查是write secure code的要點(diǎn)，但不要做太多的輸入檢查，有些內(nèi)部函數(shù)之間的參數(shù)傳遞就不必檢查輸入了，省點(diǎn)功夫。同樣的道理，未必要給所有的函數(shù)都寫注釋。寫一部分主要的就夠了。 <BR><BR>59. 產(chǎn)品有統(tǒng)一的錯(cuò)誤處理機(jī)制和報(bào)錯(cuò)界面么？ <BR>要有。最好能有統(tǒng)一的error message，然后每個(gè)error message都帶一個(gè)error number。這樣，用戶可以自己根據(jù)error number到user manual里面去看看錯(cuò)誤的具體描述和可能原因，就像SQL Server的錯(cuò)誤那樣。同樣，ASP.NET也要有統(tǒng)一的Exception處理。可以參考有關(guān)的Application Block。 <BR><BR>60. 你們有統(tǒng)一的代碼書寫規(guī)范么？ <BR>要有。Code Convention很多，搞一份來發(fā)給大家就可以了。當(dāng)然，要是有FxCop這種工具來檢查代碼就更好了。 <BR><BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[8]：61. 你們的每個(gè)人都了解項(xiàng)目的商業(yè)意義么？ <BR>要。這是Vision的意思。別把項(xiàng)目只當(dāng)成工作。有時(shí)候要想著自己是在為中國(guó)某某行業(yè)的信息化作先驅(qū)者，或者時(shí)不時(shí)的告訴team member，這個(gè)項(xiàng)目能夠?yàn)槟衬衬硣?guó)家部門每年節(jié)省多少多少百萬的納稅人的錢，這樣就有動(dòng)力了。平凡的事情也是可以有個(gè)崇高的目標(biāo)的。 <BR><BR>62. 產(chǎn)品各部分的界面和操作習(xí)慣一致么？ <BR>要這樣。要讓用戶覺得整個(gè)程序好像是一個(gè)人寫出來的那樣。 <BR><BR>63. 有可以作為宣傳亮點(diǎn)的Cool Feature么？ <BR>要。這是增強(qiáng)團(tuán)隊(duì)凝聚力、信心的。而且，“一俊遮百丑”，有亮點(diǎn)就可以掩蓋一些問題。這樣，對(duì)于客戶來說，會(huì)感覺產(chǎn)品從質(zhì)量角度來說還是acceptable的。或者說，cool feature或者說亮點(diǎn)可以作為質(zhì)量問題的一個(gè)事后彌補(bǔ)措施。 <BR><BR>64. 盡可能縮短產(chǎn)品的啟動(dòng)時(shí)間 <BR>要這樣。軟件啟動(dòng)時(shí)間（Start-Up time）是客戶對(duì)性能好壞的第一印象。 <BR><BR>65. 不要過于注重內(nèi)在品質(zhì)而忽視了第一眼的外在印象 <BR>程序員容易犯這個(gè)錯(cuò)誤：太看重性能、穩(wěn)定性、存儲(chǔ)效率，但忽視了外在感受。而高層經(jīng)理、客戶正相反。這兩方面要兼顧，協(xié)調(diào)這些是PM的工作。 <BR><BR>66. 你們根據(jù)詳細(xì)產(chǎn)品功能說明書做開發(fā)么？ <BR>要這樣。要有設(shè)計(jì)才能開發(fā)，這是必須的。設(shè)計(jì)文檔，應(yīng)該說清楚這個(gè)產(chǎn)品會(huì)怎么運(yùn)行，應(yīng)該采取一些講故事的方法。設(shè)計(jì)的時(shí)候千萬別鉆細(xì)節(jié)，別鉆到數(shù)據(jù)庫(kù)、代碼等具體實(shí)現(xiàn)里面去，那些是后面的事情，一步步來不能著急。 <BR><BR>67. 開始開發(fā)和測(cè)試之前每個(gè)人都仔細(xì)審閱功能設(shè)計(jì)么？ <BR>要做。Function Spec review是用來統(tǒng)一思想的。而且，review過以后形成了一致意見，將來再也沒有人可以說“你看，當(dāng)初我就是反對(duì)這么設(shè)計(jì)的，現(xiàn)在吃苦頭了吧” <BR><BR>68. 所有人都始終想著The Whole Image么？ <BR>要這樣。項(xiàng)目里面每個(gè)人雖然都只是在制造一片葉子，但每個(gè)人都應(yīng)該知道自己在制造的那片葉子所在的樹是怎么樣子的。我反對(duì)軟件藍(lán)領(lǐng)，反對(duì)過分的把軟件制造看成流水線、車間。參見第61條。 <BR><BR>69. Dev工作的劃分是單純縱向或橫向的么？ <BR>不能單純的根據(jù)功能模塊分，或者單純根據(jù)表現(xiàn)層、中間層、數(shù)據(jù)庫(kù)層分。我推薦這么做：首先根據(jù)功能模塊分，然后每個(gè)“層”都有一個(gè)Owner來Review所有人的設(shè)計(jì)和代碼，保證consistency。 <BR><BR>70. 你們的程序員寫程序設(shè)計(jì)說明文檔么？ <BR>要。不過我聽說微軟的程序員1999年以前也不寫。所以說，寫不寫也不是絕對(duì)的，偷懶有時(shí)候也是可以的。參見第56條。 <BR><BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[9]：71. 你在招人面試時(shí)讓他寫一段程序么？ <BR>要的。我最喜歡讓人做字符串和鏈表一類的題目。這種題目有很多循環(huán)、判斷、指針、遞歸等，既不偏向過于考算法，也不偏向過于考特定的API。 <BR><BR>72. 你們有沒有技術(shù)交流講座？ <BR>要的。每一兩個(gè)禮拜搞一次內(nèi)部的Tech Talk或者Chalk Talk吧。讓組員之間分享技術(shù)心得，這筆花錢送到外面去培訓(xùn)劃算。 <BR><BR>73. 你們的程序員都能專注于一件事情么？ <BR>要讓程序員專注一件事。例如說，一個(gè)部門有兩個(gè)項(xiàng)目和10個(gè)人，一種方法是讓10個(gè)人同時(shí)參加兩個(gè)項(xiàng)目，每個(gè)項(xiàng)目上每個(gè)人都花50%時(shí)間；另一種方法是5個(gè)人去項(xiàng)目A，5個(gè)人去項(xiàng)目B，每個(gè)人都100%在某一個(gè)項(xiàng)目上。我一定選后面一種。這個(gè)道理很多人都懂，但很多領(lǐng)導(dǎo)實(shí)踐起來就把屬下當(dāng)成可以任意拆分的資源了。 <BR><BR>74. 你們的程序員會(huì)夸大完成某項(xiàng)工作所需要的時(shí)間么？ <BR>會(huì)的，這是常見的，尤其會(huì)在項(xiàng)目后期夸大做某個(gè)change所需要的時(shí)間，以次來抵制change。解決的方法是坐下來慢慢磨，磨掉程序員的逆反心理，一起分析，并把估算時(shí)間的顆粒度變小。 <BR><BR>75. 盡量不要用Virtual Heads <BR>最好不要用Virtual Heads。Virtual heads意味著resource is not secure，shared resource會(huì)降低resource的工作效率，容易增加出錯(cuò)的機(jī)會(huì)，會(huì)讓一心二用的人沒有太多時(shí)間去review spec、review design。一個(gè)dedicated的人，要強(qiáng)過兩個(gè)只能投入50%時(shí)間和精力的人。我是吃過虧的：7個(gè)part time的tester，發(fā)現(xiàn)的Bug和干的活，加起來還不如兩個(gè)full-time的。參見第73條。73條是針對(duì)程序員的，75條是針對(duì)Resource Manager的。 <BR><BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[10]：看后感覺有益的留個(gè)貼幫頂起來吧，，謝謝<BR><IMG
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/1067019359200451297547349.gif"><BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1067019359')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>石魚</FONT></A>
<BR><BR>回復(fù)[11]：很不錯(cuò)，蠻有啟發(fā)的，謝謝樓主<BR><A href="http://www.pcpop.com/"
target=_blank><IMG border=0 src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1066950851')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>CoronusVirus</FONT></A>
<BR><BR>回復(fù)[12]：實(shí)在忘了怎么說中國(guó)話，就直接全用英文寫吧，象這樣在中文里亂蹦英文單詞，是對(duì)中文的褻瀆<BR><A
href="http://www.pcpop.com/" target=_blank><IMG border=0
src="如何用正確的方法來寫出質(zhì)量好的軟件的75條體會(huì).files/p.gif"></A>---<A
onclick="javascript:Openmemberinfo('userinfo.aspx?memberid=1066992814')"
style="CURSOR: hand" title=用戶信息><FONT color=#0000a5>國(guó)產(chǎn)貝克漢姆</FONT></A>
?? 快捷鍵說明
復(fù)制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號(hào)
Ctrl + =
減小字號(hào)
Ctrl + -