做好一个系统分析师、项目经理75条准则（4）

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的工作。