原则30:跟风要小心

即使有五千万人说傻话,那仍然是傻话。 By Anatole France

* 大家都做的不一定是适合所有环境情况的,例如:
    面向对象、软件度量(原则142、143、149、150、151),
    软件复用(84),过程成熟度(163),
    计算机辅助软件工程(CASE,22-25),原型设计(11-13,42);

* 新技术要避免陷入炒作的影响,理性评估收益与风险。

Davis, A, "Software Lemmingineering", IEEE Software, 10, 6(Sept. 1993), pp. 79-81, 84.

原则29:和组织荣辱与共

日本软件工程师对待Bug的态度可以看出他们对于组织的荣辱感深入人心。

* 任何人发现你在产品中犯的错误时,你应该心存感激;

* 人非圣贤孰能无过,过而能改善莫大焉;

* 发现错误要及时广而告之(Git工作流中的提Issue);

* 错误广而告之的好处:
    * 帮助其他工程师,避免同样的错误;
    * 对后续的错误修正,也可以不那么抵触。

Mizuno, Y,. "Software Quality Improvement", IEEE Computer, 16, 3 (March 1983), pp. 66-72.

原则28:了解形式化方法

离散数学不容易,但即使简单地应用离散数学,也会极大地帮助我们发现软件开发中的许多方面的问题。

* 先用自然语言描述;

* 尝试用形式化方法去写其中的某些部分;

* 尝试用更形式化方式书写,会帮助你发现在自然语言中存在的问题;

* 修正自然语言中表达的问题;

* 完成文档后,把形式化的描述去掉。

Hail, A, "Seven Myths of Formal Methods", IEEE Software, 7, 5 (Sept. 1990), pp, 11-19.

原则27:实现目标就停止

软件工程师要遵循许多技术或流程,每种技术都有各自的用途,通常对应软件开发的一个子目标。

> 方法
* 结构化 / 面向对象 分析的目标是理解要解决的问题;
    * DARTS的目标是处理架构;/*DARTS: Design Approach for Real-Time Systems*/
    * 结构化设计的目标是理清调用层次结构

* 不要太过于陷入具体的方法,而忘记了目标本身。

* 如果只执行了上述方法的一部分步骤,就理解了问题,那么就停下来。

* 对整个软件过程有很好的认识,基于本原则抛弃的某个方法的后续步骤可能会对未来软件的使用产生重要影响。

原则26:“知道何时”和“知道如何”同样重要

没有“放之四海而皆准”的技术。

* 优秀的工程师了解很多不同类型的技术,并且知道每种技术何时适合项目或项目的一部分。

* 进行需求工程时,要了解哪种技术对问题的哪些方面最有用。(原则47)

* 进行设计时,要理解那些技术对系统的哪些方面最有用。(原则63)

* 进行编码时,要选择最合适的编程语言。(原则102)

原则25:CASE 工具是昂贵的

CASE 工具对软件开发来说是必需的,每份授权的价格不可忽视,应该被视为业务成本的一部分。

> 投资回报分析
* 考虑购买工具的费用;
* 同时考虑没有购买工具带来的代价:
    * 更低的开发效率;
    * 更高的客户失望率;
    * 延迟的产品发布;
    * 增加的重复工作;
    * 更差的产品质量;
    * 增加员工的流动。

目前大量的软件工具已经可以免费获得。即使是收费软件,一般来说,其使用成本相比开发人员的成本相对较低。对于一般的额开发场景,这个原则可能已经不合时宜。但关于软件工具的成本和收益分析思路,仍然是可以借鉴的。


Huff, C., "Elements of a Realistic CASE Tool Adoption Budget" Commuications of the ACM, 35, 4(April 1992), pp,. 45-54.

原则23:使用工具,但要务实

就像文字处理软件对作家而言是必需的助手,CASE工具对软件工程师来说也是重要的助手。

* 好的工具可以提升开发效率。

* 思考不是由工具完成的。

Kemerer, C., "How the Learning Curve Affects Tool Adoption", IEEE Software, 9, 3 (May, 1992), pp 23-28.

原则22:技术优先于工具

在使用工具前,应该自己要先有规矩(理解并遵循适当的软件开发方法)。

* 在投资于工具以对某项技术“自动化”之前,先手工验证这项技术,并说服leader这项技术是可行的。

* 大多数情况下,如果一项技术在手工操作时不灵,在自动操作时也不灵。

Kemerer, C., "How the Learning Curve Affects Tool Adoption", IEEE Software, 9, 3 (May 1992), pp. 23-28.