软件开发的201个原则阅读笔记05

第二十六条--“知道何时”和“知道如何”同样重要

在行业中经常发生这样的事情，一个工程师学习一项新技术后，判断这是“放之四海而皆准”的技术；同时，同组另一个人在学习另外一项新技术，一场情绪化的争辩随之而来。

事实上，没有一方是正确的，知道如何很好地使用技术，既不会让技术本身成为好技术，也不会让你成为一名优秀的工程师。知道如何用好木工车床，并不能使你成为你一名好木匠。一名优秀的工程师了解很多不同种类的技术，并且知道每种技术何时适合项目或项目的一部分。一个好木匠知道多种工具的用法，知道很多不同的技巧，而且，最重要的是，知道什么时候该用哪一种。在进行需求工程时，要了解哪种技术对问题的哪些方面最有用。当进行设计时，要理解哪些技术对系统的哪些方面最有用。当进行编码时，要选择最合适的编程语言。

第二十七条--实现目标就停止

软件工程师要遵循许多方法(也称为技术或流程)。每个方法都有各自的用途，通常对应软件开发的一个子目标。例如，结构化(或者面向对象)分析的目标是理解要解决的问题，DARTS的目标是处理架构，结构化设计的目标是理清调用层次结构。这些例子中的方法都包含一系列的步骤。不要太过于陷入具体的方法，而忘记了目标本身。不要为更换目标而感到内疚。例如，如果只执行了方法的一半步骤，你就理解了问题，那就停下来。此外，你需要对整个软件过程有很好的认识，因为基于本原则所抛弃的某个方法的后续步骤可能会对未来软件的使用产生重要影响。

第二十八条--了解形式化方法

没有过硬的离散数学技能，使用形式化方法是不容易的。但是，使用它们(即便是很简单的使用)，可以极大地帮助我们发现软件开发中许多方面的问题。在每个项目中，至少应该有一个人能熟练使用形式化方法，以确保不会错过提升产品质量的机会。

很多人以为，使用形式化方法的唯一途径，就是完全使用它们来定义系统。其实并非如此。实际上，最有效的方法之一，是先用自然语言描述。然后再尝试用形式化方法去写其中某些部分。尝试用更形式化的方式书写，会帮助你发现在自然语言中存在的问题。修正自然语言表达中的问题，你会得到一个更好的文档。在完成之后，如果有需要，可以再把形式化的描述去掉。

第二十九条--和组织荣辱与共

业界普遍认为： 日本软件工程师对待bug的态度，和美国工程师不同。尽管有许多影响因素，但有一个日本的观念与此密切相关：产品中的缺陷是公司的耻辱；软件工程师引起的公司耻辱，是工程师的耻辱。这种观念在日本比在美国更深入人心，因为日本劳动者倾向于一辈子只服务一家公司。不管在一家公司工作的时间是长还是短，这种心态是很重要的。

一般而言，当任何人发现你在产品中犯的错误时，你应该心存感激，而不是试图辩解。人非圣贤，孰能无过。过而能改，善莫大焉！当发现一个错误时，导致错误的人应该使其被周知，而不是藏着掖着。将错误广而告之有两个好处： (1)帮助其他工程师，避免同样的错误，(2)对后续的错误修正，也可以不那么抵触。

第三十条--跟风要小心

即使有五千万人说傻话，那仍然是傻话。

安那托尔·佛朗士(Anatole France)

大家都做的事情，对你来说也不一定是正确的。也许它是正确的，但你也应该评估它对你所处环境的适用性。这样的例子包括：面向对象,软件度量,软件复用，过程成熟度，计算机辅助软件工程,原型设计。在所有案例中，以上这些方法都提供了非常积极的帮助，体现在提高质量、降低成本、提高用户满意度等方面。然而，这些好处只在它们能发挥作用的组织中才会显现出来。尽管回报显著，但是它们的作用常常被过度宣传，其实它们并不是那么必然或通用。

当你学习 “新”技术时，不要轻易接受与之相关的不可避免的炒作。要仔细阅读，理性考虑它的收益和风险。在大规模应用之前要进行试验。但同时也绝对不要忽略“新”技术。