《
如何有效编写软件的75条建议》文章地址：http://www.tfxk.com/wangyesheji/jianzhanjingyan/03023405H013.htm
应该用。ClearQuest太庞杂，我的推荐是BugZilla。
1. 你们的项目组应用源代码管理工具了么?
要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看过错的详细描写和可能起因，就像SQL Server的毛病那样。同样，ASP.NET也要有统一的Exception处置。可以参考有关的Application Block。
需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得常常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。
53. 你们的机能测试是等所有功效都开发完才做的么?
要这样。项目里面每个人虽然都只是在制作一片叶子，但每个人都应该晓得自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过火的把软件制造看成流水线、车间。参见第61条。
39. 你们项目组的会议、探讨都有记载么?
9. 你碰到过有人说“我以为…”么?
单元测试要有的。不过不单元测试也不是不可以，我做过没有单元测试的项目，也做胜利了??可能是幸运，可能是大家都是熟手的关联。仍是那句话，软件工程是无比实践、异常工程、十分机动的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。
31. 你们的项目组做每日编译么?
70. 你们的程序员写程序设计阐明文档么?
48. 你是先写Test Case而后再测试的么,如何有效创建个性化404错误页面?
55. 你们项目组中有人能说生产品确当前整体质量情况么?
Bug应该由Opener关闭。Dev不能擅自封闭Bug。
要有专职测试。假如人手不够，能够peer test，交流了测试。千万别自己测试本人的。
59. 产品有统一的错误处理机制和报错界面么?
要。一定要开会。程序员厌恶开会，但每个礼拜开会时间加起来至少应该有4小时。包含team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。
不要。Buffer Time加在每个小义务后面，很容易容易的就被耗费掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。
要让team member认为高层关注这个项目。
49. 你是否会为各种输入组合创立测试用例?
41. 通过Email进行所有正式沟通
反对。Branch的治理以及Merge的工作量太大，而且轻易犯错。
要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强保险。Btw，“夯”这个字念“hang”，第一声。
23. 你们项目组有自己的Logo么?
72. 你们有没有技术交换讲座?
8. 你们每个人都知道出了问题应该找谁么?
会前发meeting request和agenda，会中有人负责主持和记载，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要造成agreements和action items。
不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早矫正，早逝世早升天。
6. 你们的程序员工作在宁静的环境里么?
73. 你们的程序员都能专一于一件事件么?
要的。每一两个星期搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技巧心得，这笔花钱送到外面去培训划算。
29. 有没有设定天天Check-In的最后期限?
30. 你们能把所有源码一下子编译成装置文件吗?
要这样。要让用户感到整个程序似乎是一个人写出来的那样。
要的,如何更有效的写出CSS代码。这是逐日编译(Daily Build)的基础。而且必需要可能做成自动的。
需要一定会变的，已经写好的代码一定会被请求修改的。做善意理筹备，对change不要抗拒，而是expect change。
要。也是为了沟通。内容包括目前进度，可能的危险，质量状态，各种工作的进展等。
34. 尽量应用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基本，可以把出发点 进步良多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件;尽量用RegExp，而不是自己从头操 作字符串，等等等等。这就是“软件复用”的体现。
不要用Word写测试用例(Test Case)。应该用一个专门的体系，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目标是Track和Browse。
别盼望太高。依我看，除了性能测试以外，还是临时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对海内的软件测试的现状来说，只能“矫枉必须过正”了。
尤其当项目后期人困马乏的时候,如何更好的建好一个论坛，要保持。这会给产品带来质的差别。
要这样。要有设计才能开发，这是必须的。设计文档，应该说清晰这个产品会怎么运行，应该采用一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等详细实现里面去，那些是后面的事情，一步步来不能焦急。
47. 你们的测试有一份总的打算来划定做什么和怎么做么?
19. 你们对看法不一的缺陷有三国会议么?
要有。当老板问起这个产品目前品质如何，Test Lead/Manager应该负责答复。
当然要做。有三样货色是软件名目/产品开发必备的：1. bug management; 2. source control; 3. daily build。
37. 你们的项目经理睬发出Weekly Report么?
75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。
要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作前驱者，或者时不断的告诉team member，这个项目能够为某某某国度部门每年节俭多少多少百万的征税人的钱，这样就有能源了。平常的事情也是可以有个高尚的目的的。
60. 你们有同一的代码书写标准么?
24. 你们的员工有印有公司Logo的T-Shirt么?
67. 开始开发和测试之前每个人都细心审视功能设计么?
必需要有。要有一个明白的决议进程。这相似于CCB (Change Control Board)的概念。
要毁灭“我认为”。Never assume anything。
5. 你们的项目组用了你能买到最好的工具么?
50,如何插入CSS样式表. 你们的程序员能看到测试用例么?
4. 你们的项目组有没有建破一个门户网站?
28. 在Check-In代码时都填写正文了么?
17. 写新代码前会把已知缺陷解决么?
45. Stay agile and expect change 要这样。
需要安静环境。这点极其主要，而且要保障每个人的空间大于必定面积。
厌恶是畸形的。解决办法是组织Code Review，独自留出时光来。XP也是一个方式。
42. 为项目组树立多个Mailing Group
要。这属于Dev跟Test之间的沟通手腕。背靠背沟通需要，具体填写Repro Steps也须要。
应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种夸耀。但也要斟酌到经费，所以说是“你能买到最好的”。
33. 设计越简略越好越简单越好。
应该每个人都知道。这叫做常识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。
如果在AD+Exchange里面,如何提高用户对网站的信任度，就建Distribution List。比方，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发动Email来便利，而且能让该收到email的人都收到、不该收到不被骚扰。
要有。能加强归属感。当然，T-Shirt要做的难看一些，最好用80支的棉来做。别没穿几回就破褴褛烂的。
要发一些Newsflash给全部大组织。Show your team’s value。否则，当你坐在电梯里面，其余部分的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感到不太好。
12. 你们的工作量是先由每个人自己估算的么?
62. 产品各部分的界面和操作习惯一致么?
要。这是增强团队凝集力、信念的。而且，“一俊遮百丑”，有亮点就可以掩饰一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后补充办法。
69. Dev工作的划分是单纯纵向或横向的么?
要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间;另一种方 法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理许多人都懂，但很多引导实际起来就把属下当成可以任意 拆分的资源了。
21. 你们的程序员讨厌修正老的代码么?
35. 你们会隔一段时间就停下来夯实代码么?
--> [
网站建设之]如何有效编写软件的75条倡议
应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。
3. 你们的测试组还在用Word写测试用例么?
71. 你在招人口试时让他写一段程序么?
不能单纯的根据功能模块分，或者单纯根据表示层、旁边层、数据库层分。我推举这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。
每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。
66. 你们依据详细产品功能仿单做开发么?
要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。
不可以。对大部分项目来说，最多两三天就应该Check-In。
不要，不要搞边界条件组合。小心组合爆炸。有很多test case工具能够自动天生各种边界前提的组合??但要想明白，你是否有时间去运行那么多test case。
应该如此。应该先设计再编程、先test case再测试。当然，事情是灵巧的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，由于不习惯，太麻烦，至于别人推荐，那尝尝看也不妨。
不要。固然说做输入检查是write secure code的要点，但不要做太多的输入检讨，有些内部函数之间的参数传递就不用检查输入了，省点工夫。同样的情理，未必要给所有的函数都写解释。写一部门重要的就够了。
要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug能力继承写新代码。
38. 你们项目组是否至少每周全部开会一次?
2. 你们的项目组使用缺陷管理系统了么?
36. 你们的项目组每个人都写Daily Report么?
要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。
68. 所有人都始终想着The Whole Image么?
74. 你们的程序员会夸大实现某项工作所需要的时间么?
56. 你们有单元测试么?
44. 你做决议、做变更时，告诉大家原因了么?
要。让Dev看到Test Case吧。咱们都是为了统一个目的走到一起来的：提高质量。
应该反映。然而，应该用Baseline的方法来管理进度表：保护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变革管理里面的一个重要手段。
54. 你留神到测试中的杀虫剂效应了么?
40. 其他部门知道你们项目组在干什么么?
必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状恰当进行调剂。
7. 你们的员工每个人都有一部电话么?
16. 登记新缺陷时，是否写清了重现步骤?
要的。我最喜欢让人做字符串和链表一类的题目。这种标题有很多轮回、断定、指针、递归等，既不偏向过于考算法，也不倾向过于考特定的API。
10. 你们的项目组中所有的人都坐在一起么?
11. 你们的进度表是否反应最新开发进展情形?
要的，要明确Check-In Deadline。否则会Build Break。
会的，这是常见的，尤其会在项目后期夸张做某个change所需要的时间，以次来抵制change。解决的方法是坐下来缓缓磨，磨掉程序员的逆反心理，一起剖析，并把估算时间的颗粒度变小。
虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和伎俩，就又会发明一些新bug了。
需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方法。能坐在一起就最好坐在一起，好处多得不得了。
要告诉大家原因。Empower team member的手段之一是供给足够的information，这是MSF一开篇的多少个准则之一。确实如斯，tell me why是人情世故，tell me why了才干有understanding。中国人做事爱好搞制约，限度信息，仿佛可以看到某一份文件的人就是有身份的人。大错特错。威望、权利，不在于 是不是能access information/data，而在于是不是控制资源。
应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以持续Dispatch给其别人。
15. 值得再多花一些时间，从95%做到100%好值得，非常值得。
51. 你们是否随意抓一些人来做易用性测试?
14. 你们的项目规划中Buffer Time是加在每个小任务后面的么?
大忌。写好一块程序当前，即使不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。
要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。
57. 你们的程序员是写完代码就扔过墙的么?
46. 你们有没有专职的软件测试人员?
要做。Function Spec review是用来统一思维的。而且，review过以后构成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，当初刻苦头了吧”
要写的，至少一两句话，好比“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一局部。
43. 每个人都知道哪里可以找到全体的文档么?
26. 你们是给每个Dev开一个分支么?
64. 尽可能缩短产品的启动时间要这样。
20. 所有的缺陷都是由登记的人最后关闭的么?
要写。五分钟就够了，写10句话左右，告知自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己(要是不务正业一天，自己都会不好心思写的)。
27. 有人长期不Check-In代码么?
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的。
软件启动时间(Start-Up time)是客户对性能好坏的第一印象。
不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能解释项目进度分歧理。当然，一些对日软件外包必须每天加班，那属于盘剥的范围。
13. 你们的开发职员从项目一开端就加班么?
22. 你们项目组有Team Morale Activity么?
要有自己的Logo。至少应该有自己的Codename。
要。不外我据说微软的程序员1999年以前也不写。所以说，写不写也不是相对的，偷勤有时候也是可以的。参见第56条。
设计时候多一句话，未来可能就带来无限无尽的懊恼。应当从一开始就英勇的砍。这叫scope management。
Tag：提议 软件 编写 有效 如何 建议 软件 编写 有效 如何
52. 你对主动测试的冀望准确么?
18. 你们对缺点的轻重缓急有当时的商定么?
应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的抉择是VSS。
这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的尺度是什么?用什么手段，自动的还是手动的?这些问题需要用Test Plan往返答。
58. 你们的程序中所有的函数都有输入检查么?
32. 你们公司有没有积聚一个项目风险列表?
Email的利益是省得抵赖。但也要防止矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。
63. 有可以作为宣扬亮点的Cool Feature么?
要这么做。自己看自己写的程序界面，怎么看都是悦目的。这叫做审美疲劳??臭的看久了也就不臭了，不方便的永恒了也就习惯了。
25. 总经理至少每月加入次项目组会议要的。
65. 不要过于重视内在品德而忽视了第一眼的外在印象程序员容易犯这个错误：太重视性能、稳固性、存储效力，但疏忽了外在感触。而高层经理、客户正相反。这两方面要统筹，和谐这些是PM的工作。
61. 你们的每个人都懂得项目的贸易意思么?
(责任编辑：网站建设)
如何有效编写软件的75条建议相关文章