《软件开发的201个原则》阅读&翻译笔记（一）

本人英文水平有限，如有错误还请海涵~

201 principles of software development

软件开发的201个原则

by Alan M.Davis

chapter 1

This book contains a collection of principles of software engineering.These principles represent the state-of-the-art of what we believe is”right”when engineering software. Other engineering disciplines have principles based on the laws of physics, or biology, or chemistry, or mathematics. Because the product of software engineering is nonphysical, the laws of the physical do not easily form a solid foundation

The software industry has been flooded by hundreds of books that discuss techniques, languages, and tools. None has attempted to compile the list of underlying principles. As shown in Fig 1-1, principles are the rules to live by; they represent the collected wisdom of many dozens of people who have learned through experience. They tend to be stated as absolute truths(this is always true)or as inferences(when X occurs, Y will occur).

Techniques are step-by-step procedures that aid a software developer in performing a part of the software engineering process Techniques tend to enforce a subset of the underlying principles. Most techniques create either documents and /or programs. Many techniques also analyze existing documents and /or programs, or they transform existing documents and /or programs into the products.

Languages consist of a set of primitive elements(such as words or graphical symbols) and a set of rules by which one can construct more complex entities(such as sentences, diagrams, models) from those primitive elements as well as semantics that endow each combination of entitieswith meaning. Languages are used to express all products of software engineering, whether intermediate or final The documents and programs created or analyzed by techniques are typically represented in some language.

Tools are software programs that assist a soft ware engineer in performing some step of software engineering. They may:

• Serve in an advisory capacity to the engineer(like the knowledge-based Requirements Assistant)
• Analyze something for conformity to a technique(a data-flow diagram checker, for example)or a subset of principles
• Automate some aspect of software engineering(such as any compiler)
• Aid the engineer in doing some aspect of the job(as an editor)

The set of principles for a discipline evolve as the discipline grows.Existing principles are modified. New ones are added. Old ones are discarded. It is the practice and experience gained through that practice that cause us to evolve those principles. If we were to examine the set of software engineering principles from 1964 they would look downright silly today(for example, always use short variable names, or do whatever it takes to make your program smaller). Todays principles will look equally silly in thirty years.

And now,today’s principles of software engineering.

介绍本书。略~

chapter 2

principle 1 : quality is #1

A customer will not tolerate a product with poor quality, regardless of the definition of quality. Quality must be quantified and mechanisms put into place to motivate and reward its achievement. It may seem politically correct to deliver a product on time, even though its quality is poor, but it is politically correct in the short term only; it is political suicide in the middle and long term. There is no trade-off to be made. The first requirement must be quality. Edward Yourdon suggests that you Just say no”when you’re asked to speed up testing, ignore a few bugs, or code before agreeing on a design or a set of requirements

1、质量是no.1

无论质量如何定义，客户都不会容忍质量较差的产品。 质量必须要量化，并且激励和成就奖励机制要落实。 即使按时交付质量差的产品在政治上看起来是正确的，但仅在短期内是正确的；在中长期来看，相当于政治自杀。 没有权衡取舍（没得商量）。 第一个要求就是必须做得有质量。

Edward Yourdon建议你在以下情况直接说no：1.被要求加快测试速度；2.忽略一些bug；3.在设计和需求确认之前开发。

---

principle 2 : quality is the eyes of the beholder

There is no one definition of software quality. To developers ,it might be an elegant design or elegant code. To users ,who work in stress environments,it might be response time or high capacity. For cost-sensitive projects, it might be low development cost. For some customers, it might be satisfying all their perceived and not-yet-perceived needs. The dilemma is that these may not be all compatible. Optimizing one persons quality might be detrimental to anothers.(This is Weinberg’s”Political Dilemma”principle. )A project must decide on its priorities and articulate them to all parties.

2、质量是旁观者的眼睛

没有人定义软件质量。对于开发者来说，它们可能是优雅的设计或优雅的代码。对于工作在压力环境的用户们，也许意味着响应时间或者高吞吐。对于成本敏感的项目，也许是低开发成本。对于一些消费者，也许是满足他们自己发现或者没发现的需求。困难的是，他们可能没办法全部实现。提升一类人的体验，可能会牺牲其他人的。一个项目必须决定它的优先事项，并且告知所有人。

---

principle 3 : productivity and quality are inseparable

There is a clear relationship between productivity(measured by numbers of widgits–whether they be lines of code or function points–per person month)and quality. The higher the demand for quality, the lower your productivity becomes. The lower the demand for quality, the higher your productivity becomes. The more you emphasize increased productivity, the lower your resulting quality. Bell Labs has found that, to achieve one to two bugs per thousand lines of code, productivities of 150 to 300 lines of code per person-month are common [see Fleckenstein, W,”Challenges in Software Development, ” IEEE Computer, 16, 3(March 1983), Pp 60-64].As attempts are made to drive productivity up ,the density of bugs increases.

3、生产效率和质量是形影不离的

生产效率（呵呵不太好翻呢）和质量之间有一个清晰的关系。质量要求更高，生产效率则越低。越注重增加生产效率，结果的质量就越低。Bell Labs发现，在每人月150~300行的效率下，每1000行代码出现1~2个bug是普遍的。当试图提高生产效率时，bug出现的密度将增加。

---

principle 4 : high-quality software is possible

Although our industry is saturated with examples of software systems that perform poorly, that are full of bugs, or that otherwise fail to satisfy users’ needs, there are counter examples.large-scale software systems can be built with very high quality, but for a steep price tag: on the order of $1000 per line of code. One such example is IBMS on-board flight software for NASAS space shuttle. Totaling approximately three million lines of code,the rigorous software development process resulted in less than one error found per ten thousand lines of code after product release.

As a developer, be aware of the techniques that have been demon-strated to increase quality considerably. These include involving the customer(Principle 8), prototyping(to verify requirements prior to full-scale development; Principles 11 through 13), keeping the design simple (Principle 67), inspections(Principle 98), and hiring the best people ( Principles 130 and 131). As a customer, demand excellence but be aware of the high costs involved

4、高质量的软件是可能的

虽然我们的行业充满了软件系统的例子，这些软件系统性能不好，充满缺陷，或者不能满足用户的需求，但有一些反例。大规模的软件系统可以高质量的建造，但是代码也被标以高价：$1000/行。其中的一个例子是IBM为NASA的航天飞机做的机载飞行软件。大约3百万行代码，严格的软件开发流程的结果是，在发布后万行代码的错误数小于1。
作为一个开发者，要知道已经被证明可以大幅提高质量的技术。这些包括涉及客户（原则8），原型（在全面验证需求前进行全面开发；原则11到13），保持设计简单（原则67），检查（原则98），聘用最优秀的人（原则130和131）。作为一个消费者，要求卓越，但要意识到所涉及的高成本。

---

principle 5 : don’t try to retrofit quality

Quality cannot be retrofit into software .This applies to any definition of quality: maintainability, reliability, adaptability, testability, safety, and so on. We have a very difficult time building quality into software during development when we try to. How can we possibly expect to achieve quality when we don’ t try? This is primarily why you must not try to convert a throwaway prototype into a product(Principle 11).

5、 不要试图改进质量

软件质量不能被改进。这适用任何质量的定义：可维护性，可靠性，适应性，可测试性，安全性等。当我们尝试开发时，在开发过程中很难提高软件质量。如果我们不尝试，怎么可以达到我们期望的质量。这就是为什么你不能试图将一次性原型（个人理解：临时、口头的、未经过推敲验证的原型）转换成产品的主要原因（原则11）。

---

principle 6 : poor reliability is worse than poor efficiency

When software is not efficient, it is generally possible to isolate the sections of the program that consume most of the execution time and redesign or recode them for increased efficiency(Principle 194).Poor reliability is not only more difficult to detect, it is also more difficult to fix.A system’s poor reliability may not become apparent until years after the system is deployed–and it kills somebody.Once the poor reliability manifests itself, it is often difficult to isolate its cause.

6、低可靠性比低效率更糟糕

当软件效率不高时，通常可以将其中消耗大部分执行时间的部分隔离起来，重新设计或重新编码来提升效率(原则194)。低可靠性不仅很难检测，并且更难修复。一个系统的低可靠性可能在部署后的几年内都不会有明显的改变–它杀死了某些人。一旦低可靠性显现出来，往往很难分离其原因。

---

principle 7 : give products to customers early

No matter how hard you try to learn users’needs during the requirements phase, the most effective means to ascertain their real needs is to give them a product and let them play with it.If you follow a conventional interpretation of the waterfall model, the first delivery of a product to the customer occurs after 99 percent of the development resources are already expended.Thus, the majority of customer feedback on their needs occurs after the resources are expended.Contrast that with an approach, for example, of constructing a quick and dirty prototype early in the development process.Deliver this to the customer, gather feedback, and then write a requirements specification and proceed with a full-scale development.In this scenario, only 5 to 20 percent of the development resources are expended by the time customers experience their first product.f the appropriate features were built into the prototype, the highest-risk user needs will become better known and the final product is more likely to be user-satisfactory.This helps ensure that the remainder of the resources are spent building the right system.

7、尽早呈现产品给用户

无论你在需求阶段多努力的去了解用户的需求，最有效查明他们真实需求的手段是给他们一个产品，然后让他们体验。如果你遵从瀑布模型的常规解释，第一次交付产品给用户发生在99%的开发资源已经耗尽之后。于是，最重要的关于他们需求的用户反馈发生在资源已经被耗尽之后。先比较一个方法，例如，在开发过程的早期构建一个快速且脏乱的原型。将此交付用户，收集反馈，然后写需求文档并进行全面开发。在这个方案中，只有5-20%的开发资源被消费，当消费者体验他们第一个产品时。如果适当的特征加入到了原型中，这些高风险的用户需求将变得更好了解并且最终产品也将更接近用户满意的样子。这些有助于确保资源的其余部分用于构建正确的系统。

---

principle 8 : communicate with customers/users

Never lose sight of why software is being developed:to satisfy real needs,to solve real problems.The only way to solve real needs is to communicate with those who have the needs.The customer or user is the most important person involved with your project.If you are a commercial developer, talk often with the clients.Keep them involved.Sure, it is easier to develop software in a vacuum, but will the customer like the result?If you’re a producer of shrinkwrap software,”customers”are harder to locate during development.So role-play.Designate three or four individuals in your organization as prospective customers and tap them for ideas that will keep them as customers or make them happy.If you’re a government contractor, talk often with the contracting officers, their technical representatives, and, if possible, the users.People and situations change often in the government.the only way to keep up with the change is communication.Ignoring the changes may make life seem easier in the short term, but the final system will not be useful.

8、和客户/用户交流

永远不要忽视为什么要进行软件开发。满足实际的需要，解决实际的问题。这唯一的途径去解决实际需要的方法就是去沟通那些有需要的人。客户或者用户是与你的项目相关的最重要的人。如果你是一个盈利性质的开发者，要经常和客户交谈。让他们参与进来。当然，空白开发是很容易的，但是客户会喜欢这样的结果？如果你是软件外包的生产商，那么在开发阶段顾客就更难定位了。所以，换位思考以下。在你的组织中指定三个或四个人作为客户，并利用他们的想法，将他们作为客户或使他们高兴。如果你是一个政府项目的承包商，经常和政府军官，他们的技术该表，如果可能，还有他们的用户进行交谈。政府的认识变化是很频繁的。唯一能跟上这种变化的方式就是沟通。忽略这种变化可能短期的能让生活看起来更简单一些，但是最终系统可能将不那么好用。

---

principle 9 : align incentives for developer and customer

Projects often fail because customers and developers have different(and perhaps incompatible) goals.For example, take the simple case in which the customer wants features 1, 2, and 3 by a specific date and the developer wants to maximize revenue or profit.To maximize revenue the develper may attempt to build all three features in their entirety even if late.To maximize revenue the develper may attempt to build all three features in their entirety even if late.To help align the two organizations’ goals:
(1)Prioritize requirements (Principle 50)so that developers understand their relative importance,
(2) reward the developer based on the relative priorities(for example, all highpriority requirements must be satisfied, each medium priority requirement earns the developer a small additional bonus of some kind and each low priority requirement satisfied earns a very small bonus),
(3)use strict penalties for late delivery

9、调整开发者和用户的奖励机制

项目会经常因为顾客和开发者之前不同的（也许根本不相容的）目标而失败。举个栗子，一个简单的情况，客户想要在要给特殊的时间获得特征1，2和3，而开发者想要最大化的收入和利润。为了最大化收入，开发者可能会在他们的整体项目中接受生成全部的三个特征，即便会延期。与此同时，顾客可能会首选少做一个特征来保证其他的能准时上线。为了帮助平衡这两个组织的目标：
（1）给需求排优先级（原则50）为了让开发者明白它们之间的重要性。
（2）基于优先级，相对地给开发者奖励（举个栗子，所有高优先级必须被满足，每个中等优先级需求将为开发者赢得一个小的额外的某种类型的奖励，每个更低优先级的需求被满足则给一个更小的奖励）。
（3）对未完成的情况使用严格的处罚手段。

---

principle 10 : plan to throw one away

One of the most important critical success factors for a project is whether it is entirely new.Programs that tread on brand new territory(whether it be with respect to application, architecture, interface, or algorithm) rarely work the first time.Fred Brooks, in his Mythical Man Month, makes this perfectly clear with his advice, “Plan to throw one away; you will anyway.”This advice was originally presented by Winston Royce in 1970, when he said one should plan for the first fully deployed system to be the second one created.The first should at least check out the critical design issues and the operational concept.Furthermore Royce recommended that such a prerelease version should be developed with approximately 25 percent of the total system development resources.As a developer of a new custom product, plan to build a series of throwaway prototypes(Principles 11, 12, and 13)before embarking on the full-scale product development.As a commercial high-volume developer expect that your first product version will be able to be modified for a certain period of years, after which it will need to be fully replaced(related Principles 185, 186, 188, and 201).As a maintainer of a product, be aware that you can fiddle with the program just so much before it becomes unstable and must be replaced (see related Principles 186, 191, 195, and 197).

10、计划扔掉第一个

项目最重要的关键成功因素之一是它是否是全新的。进入崭新领域的程序（无论是关于应用程序，体系结构，接口或者算法）很少会在第一次就正常工作。Fred Brooks,在他的《Mythical Man Month》(人月神话)用他的忠告明确地说，“ 打算丢弃一个，无论如何你还会拥有的”。[ps:有点怪]。这个建议最初是在1970年被Winston Royce提出的，当时他说应该为第一个完全部署的系统升级为第二个系统做计划。第一个系统至少应该检查决定性设计问题和操作理念。此外，Royce推荐这样一个预版本本应该用25%的系统资源来开发。作为一个新的定制产品的开发人员，计划在开始大规模产品开发之前建立一系列一次性原型（原则11，12和13）。作为一个商业大容量的开发人员一定要确认你的第一个产品版本在数年内能够被修改，未来它需要完全被替换（原则185, 186, 188和201）。作为一个程序的维护者，请注意，在程序变得不稳定并必须被替换之前，你可以对程序进行尽可能多的修改（见相关原则 186, 191, 195 和 197）。