不要。虽然说做输入检查是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. 你们的程序员写程序设计说明文档么？
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
