《软件开发的201个原则（必读经典简装本）》 - [美]Alan M. Davis[艾伦·M．戴维斯] - 电子工业出版社 - 香港大書城

	登入帳戶　 \|　訂單查詢　 \|　購物車/收銀台(0)　\|　在線留言板　 \|　付款方式　 \|　運費計算　 \|　聯絡我們　 \|　幫助中心　\|　加入書簽
		會員登入新用戶登記

HOME

新書上架

暢銷書架

好書推介

2023年度TOP

臺灣用戶

品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心

服務：香港／台灣／澳門／海外

送貨：速遞／郵局／服務站

新書上架：簡體書繁體書
暢銷書架：簡體書繁體書
好書推介：簡體書繁體書

『簡體書』软件开发的201个原则（必读经典简装本）

書城自編碼： 3815041
分類：簡體書→大陸圖書→計算機/網絡→软件工程/开发项目管理
作者： [美]Alan M. Davis[艾伦·M．戴维斯]
國際書號(ISBN)： 9787121444661
出版社：电子工业出版社
出版日期： 2022-11-01

頁數/字數： /
書度/開本： 32开釘裝：平装

售價：HK$ 87.4

我要買件

** 我創建的書架 **
未登入.

新書推薦：

《津轻：日本无赖派文学代表太宰治自传性随笔集》
售價：HK$ 66.7

《河流之齿》
售價：HK$ 59.8

《新经济史革命：计量学派与新制度学派》
售價：HK$ 89.7

《盗墓笔记之秦岭神树4 》
售價：HK$ 57.3

《战胜人格障碍》
售價：HK$ 66.7

《逃不开的科技创新战争》
售價：HK$ 103.3

《漫画三国一百年》
售價：HK$ 55.2

《希腊文明3000年（古希腊的科学精神，成就了现代科学之源）》
售價：HK$ 82.8

建議一齊購買：

HK$ 91.8
《术以载道——软件过程改进实践指南》

HK$ 87.4
《代码的艺术：用工程思维驱动软件开发（必读经典简装本）》

HK$ 89.7
《开放式协作：开源软件的生产与维护》

HK$ 112.7
《Unity手机游戏开发：从搭建到发布上线全流程实战》

HK$ 113.9
《AI产品经理：方法、技术与实战》

編輯推薦：

1.本版本为【简装便携版】小册，携带更方便！地铁、公交、图书馆、教室、办公室，一本适合多场景阅读。
2.一部英文原著亚马逊4.5高分，畅销全球26年的领域经典——首次落地中国。
3.用【简单原则】讲透软件研发重要思想——从需求分析到产品演进，覆盖产品研发全流程。
3.首本实现【轻阅读】的研发字典书——201个原则独立成文，简练深刻，轻松阅读。
4.百度技术学院【指定用书】——掌握科学的方法，效率提高不止100%。
5.原则1：质量第一。原则7：尽早把产品交给客户。原则39：先确定问题，再写需求。原则64：没有文档的设计不是设计。原则66：不要重复造轮子。

內容簡介：

★本书汇总了软件工程原则。原则是关于软件工程的基本原理、规则或假设，不管所选的技术、工具或语言是什么，这些原则都有效。

★全书共9章，第1章为引言，后面8章将201个软件工程的原则划分为8个大的类别：一般原则、需求工程原则、设计原则、编码原则、测试原则、管理原则、产品保证原则和演变原则。

★本书面向的读者包括软件工程师和管理者、软件工程专业的学生、软件工程领域的研究人员等。

★本书由百度公司支持出版。百度以技术创新为信仰，在创新投入、研发布局、人才引进方面均走在国际前列。百度一直秉承着“科技为更好”的社会责任理念，坚持运用创新技术，聚焦于解决社会问题，履行企业公民的社会责任，为帮助全球用户创造更加美好的生活而不断努力。

關於作者：

★作者介绍★

Alan M. Davis是一名计算机科学家，他的职业生涯大约有一半在工业界，一半在学术界。

他在工业界的经历包括：
Offtoa公司的联合创始人兼首席执行官，这是一家帮助企业家制定商业战略的互联网公司（2012年至今）。
Omni-Vista公司的联合创始人、董事长兼首席执行官，这是一家位于科罗拉多斯普林斯的软件公司（1998—2002）。

他在学术界的经历包括：
位于丹佛的科罗拉多大学行政MBA创业教授，前任学术主席（2006—2018）。
科罗拉多大学斯普林斯分校的商业策略与企业家精神专业的教授，前El Pomar软件工程教授（1991—2015）。

Davis博士在1994年至1998年担任《IEEE 软件》的主编；在全球28个国家或地区演讲2000余次，并撰写了9本图书；他自1994年起成为IEEE会士；曾多次访问中国，其中包括领导EMBA学生小组三度赴上海、北京出访。

★译者介绍★

本书译者均为百度内部培训项目“代码的艺术训练营”的学员。出于对本书的热爱和推广优秀软件工程理念的使命，大家自发组织起来，利用业务时间完成了本书的翻译。翻译小组的成员包括：叶王，马学翔，吴斌，王冰清，杨光，曾浩浩，李殿斌，甘璐，李子昂，肖远昊，贾儒，王莹，张苗，李双婕，荣文升。
大家很高兴能够在百度完成这件非常有意义的工作。

★第1章　引言★
★第2章　一般原则★
原则1　质量第一
原则2　质量在每个人眼中都不同
原则3　开发效率和质量密不可分
原则4　高质量软件是可以实现的
原则5　不要试图通过改进软件实现高质量
原则6　低可靠性比低效率更糟糕
原则7　尽早把产品交给客户
原则8　与客户/用户沟通
原则9　促使开发者与客户的目标一致
原则10　做好抛弃的准备
原则11　开发正确的原型
原则12　构建合适功能的原型
原则13　要快速地开发一次性原型
原则14　渐进地扩展系统
原则15　看到越多，需要越多
原则16　开发过程中的变化是不可避免的
原则17　只要可能，购买而非开发
原则18　让软件只需简短的用户手册
原则19　每个复杂问题都有一个解决方案
原则20　记录你的假设
原则21　不同的阶段，使用不同的语言
原则22　技术优先于工具
原则23　使用工具，但要务实
原则24　把工具交给优秀的工程师
原则25　CASE工具是昂贵的
原则26　“知道何时”和“知道如何”同样重要
原则27　实现目标就停止
原则28　了解形式化方法
原则29　和组织荣辱与共
原则30　跟风要小心
原则31　不要忽视技术
原则32　使用文档标准
原则33　文档要有术语表
原则34　软件文档都要有索引
原则35　对相同的概念用相同的名字
原则36　研究再转化，不可行
原则37　要承担责任
★第3章　需求工程原则★
原则38　低质量的需求分析，导致低质量的成本估算
原则39　先确定问题，再写需求
原则40　立即确定需求
原则41　立即修复需求规格说明中的错误
原则42　原型可降低选择用户界面的风险
原则43　记录需求为什么被引入
原则44　确定子集
原则45　评审需求
原则46　避免在需求分析时进行系统设计
原则47　使用正确的方法
原则48　使用多角度的需求视图
原则49　合理地组织需求
原则50　给需求排列优先级
原则51　书写要简洁
原则52　给每个需求单独编号
原则53　减少需求中的歧义
原则54　对自然语言辅助增强，而非替换
原则55　在更形式化的模型前，先写自然语言
原则56　保持需求规格说明的可读性
原则57　明确规定可靠性
原则58　应明确环境超出预期时的系统行为
原则59　自毁的待定项
原则60　将需求保存到数据库
★第4章　设计原则★
原则61　从需求到设计的转换并不容易
原则62　将设计追溯至需求
原则63　评估备选方案
原则64　没有文档的设计不是设计
原则65　封装
原则66　不要重复造轮子
原则67　保持简单
原则68　避免大量的特殊案例
原则69　缩小智力距离
原则70　将设计置于知识控制之下
原则71　保持概念一致
原则72　概念性错误比语法错误更严重
原则73　使用耦合和内聚
原则74　为变化而设计
原则75　为维护而设计
原则76　为防备出现错误而设计
原则77　在软件中植入通用性
原则78　在软件中植入灵活性
原则79　使用高效的算法
原则80　模块规格说明只提供用户需要的所有信息
原则81　设计是多维的
原则82　优秀的设计出自优秀的设计师
原则83　理解你的应用场景
原则84　无须太多投资，即可实现复用
原则85　“错进错出”是不正确的
原则86　软件可靠性可以通过冗余来实现
★第5章　编码原则★
原则87　避免使用特殊技巧
原则88　避免使用全局变量
原则89　编写可自上而下阅读的程序
原则90　避免副作用
原则91　使用有意义的命名
原则92　程序首先是写给人看的
原则93　使用最优的数据结构
原则94　先确保正确，再提升性能
原则95　在写完代码之前写注释
原则96　先写文档后写代码
原则97　手动运行每个组件
原则98　代码审查
原则99　你可以使用非结构化的语言
原则100　结构化的代码未必是好的代码
原则101　不要嵌套太深
原则102　使用合适的语言
原则103　编程语言不是借口
原则104　编程语言的知识没那么重要
原则105　格式化你的代码
原则106　不要太早编码
★第6章　测试原则★
原则107　依据需求跟踪测试
原则108　在测试之前早做测试计划
原则109　不要测试自己开发的软件
原则110　不要为自己的软件做测试计划
原则111　测试只能揭示缺陷的存在
原则112　虽然大量的错误可证明软件毫无价值，但是零错误并不能说明软件的价值
原则113　成功的测试应发现错误
原则114　半数的错误出现在15%的模块中
原则115　使用黑盒测试和白盒测试
原则116　测试用例应包含期望的结果
原则117　测试不正确的输入
原则118　压力测试必不可少
原则119　大爆炸理论不适用
原则120　使用 McCabe 复杂度指标
原则121　使用有效的测试完成度标准
原则122　达成有效的测试覆盖
原则123　不要在单元测试之前集成
原则124　测量你的软件
原则125　分析错误的原因
原则126　对“错”不对人
★第7章　管理原则★
原则127　好的管理比好的技术更重要
原则128　使用恰当的方法
原则129　不要相信你读到的一切
原则130　理解客户的优先级
原则131　人是成功的关键
原则132　几个好手要强过很多生手
原则133　倾听你的员工
原则134　信任你的员工
原则135　期望优秀
原则136　沟通技巧是必要的
原则137　端茶送水
原则138　人们的动机是不同的
原则139　让办公室保持安静
原则140　人和时间是不可互换的
原则141　软件工程师之间存在巨大的差异
原则142　你可以优化任何你想要优化的
原则143　隐蔽地收集数据
原则144　每行代码的成本是没用的
原则145　衡量开发效率没有完美的方法
原则146　剪裁成本估算方法
原则147　不要设定不切实际的截止时间
原则148　避免不可能
原则149　评估之前先要了解
原则150　收集生产力数据
原则151　不要忘记团队效率
原则152　LOC/PM与语言无关
原则153　相信排期
原则154　精确的成本估算并不是万无一失的
原则155　定期重新评估排期
原则156　轻微的低估不总是坏事
原则157　分配合适的资源
原则158　制订详细的项目计划
原则159　及时更新你的计划
原则160　避免驻波
原则161　知晓十大风险
原则162　预先了解风险
原则163　使用适当的流程模型
原则164　方法无法挽救你
原则165　没有奇迹般提升效率的秘密
原则166　了解进度的含义
原则167　按差异管理
原则168　不要过度使用你的硬件
原则169　对硬件的演化要乐观
原则170　对软件的进化要悲观
原则171　认为灾难是不可能的想法往往导致灾难
原则172　做项目总结
★第8章　产品保证原则★
原则173　产品保证并不是奢侈品
原则174　尽早建立软件配置管理过程
原则175　使软件配置管理适应软件过程
原则176　组织SCM独立于项目管理
原则177　轮换人员到产品保证组织
原则178　给所有中间产品一个名称和版本
原则179　控制基准
原则180　保存所有内容
原则181　跟踪每一个变更
原则182　不要绕过变更控制
原则183　对变更请求进行分级和排期
原则184　在大型开发项目中使用确认和验证
★第9章　演变原则★
原则185　软件会持续变化
原则186　软件的熵增加
原则187　如果没有坏，就不要修理它
原则188　解决问题，而不是症状
原则189　先变更需求
原则190　发布之前的错误也会在发布之后出现
原则191　一个程序越老，维护起来越困难
原则192　语言影响可维护性
原则193　有时重新开始会更好
原则194　首先翻新最差的
原则195　维护阶段比开发阶段产生的错误更多
原则196　每次变更后都要进行回归测试
原则197　“变更很容易”的想法，会使变更更容易出错
原则198　对非结构化代码进行结构化改造，并不一定会使它更好
原则199　在优化前先进行性能分析
原则200　保持熟悉
原则201　系统的存在促进了演变

內容試閱：

★作者序★

在1995年版的序言中，我写道，

如果软件工程真的是一门工程学科，那么它是对经过验证的原则、技术、语言和工具的智慧的运用，用于有成本效益地创造和维护能够满足用户需求的软件。本书是有史以来第一本成册的软件工程原则集。原则是关于软件工程的基本原理、规则或假设，不管所选的技术、工具或语言是什么，其都有效。

26年后的今天，当我审视这201条原则时，我很高兴地宣告，几乎所有的原则都经受住了时间的考验，就像物理学中的基本原理一样。
然而，在这26年里，因为软件造成的问题相当之多。举几个例子：

★波音 737 MAX 机动特性增强系统（MCAS）的单点故障导致了两起空难，共造成 346 人死亡，调查结果是软件测试不彻底。
★全球范围的软件系统反复被勒索软件攻击，表明软件存在漏洞。
★一个无法预测且未被发现的溢出错误导致人类飞行控制员必须在发射后立即销毁阿丽亚娜 5 型运载火箭。
★火星气候轨道飞行器坠毁在火星上，原因是两个程序员关于变量的单位出现错误沟通：一个认为是磅，另一个认为是牛顿。

当桥梁或建筑物倒塌时，调查人员会尝试确定是什么地方出了问题。通常，是因为建筑商未能遵守建筑规范（即施工期间要遵循的一套规则或原则），或者检查员未能找到物理损坏的位置。当软件失败时，通常是因为软件工程组织没有遵守某个原则。

理解和实践一门学科的所有原则是否可以预防所有灾难？绝对不是。它只会大大降低因你而导致灾难的可能性。正如亚历山大·波普所说，“犯错是人之常情。”只有通过犯错，我们才能学习，并制定新的原则。

在这本书中发表的大部分原则并非原创，很多是从软件工程从业者和研究者的著作中摘录而来的。这些人无私地和我们分享他们的经验、想法和智慧。我并不认为这201个原则是相互独立的。不像Boehm提出的7个“基本”软件工程原则，本书中的一些原则的组合可能蕴涵另一个原则。但我也不认为这201个原则中的某两个或某几个原则是100% 兼容的。俗话所说的，“距离产生美”和“眼不见，心不烦”都是真理，每个原则都可以应用在我们的生活中，但是它们却不能同时用来证明同一个决定是正确的。本书中包含的原则都是有效的，它们都能够用来提升软件工程的水平，但也许并不能将某些组合应用到同一个项目中。

本版中的原则与1995版中的原则相同。但是，你可能会对我的想法感兴趣，哪些仍然是绝对正确的，哪些是我怀疑的。以下是我的想法：

对于第 2 章中介绍的一般原则，全部依然有效。一些额外说明如下。
★在原则 23～25 中，“CASE”这个词已经不流行了。今天，主要的软件开发工具支持问题跟踪、版本控制、虚拟机模拟、项目管理和调试。
★ 对于原则 28，我必须承认，在过去 26 年里，据我所知，没有一个为我工作过的软件工程师使用过形式化方法本身，尽管其中很多人还拥有高等数学学位，也就是说，他们在本质上，是知道如何以形式化的方式思考的。

对于第 3 章中介绍的需求工程原则，全部依然有效。一些额外说明如下。
★对于原则 40、41、43、45、47、48、49 和 54，在过去 26 年的大部分时间里，我一直致力于创业，在这种环境下，向客户提供一系列不断增大的最小可行产品（MVP）以获取他们的反馈至关重要。我们只是在问题跟踪工具中以自然语言维护我们的需求，我们可以轻松地用优先级、目标版本、状态和注解对它们进行注释。当然，这正是原则 60 所体现的精神。

对于第 4 章中介绍的设计原则，全部依然有效。一些额外说明如下。
★对于原则 73，如今耦合和内聚变得不那么重要，已经被重用所取代。今天，我们通过从大量经过验证的组件库中选取许多组件来构建系统，并在必要时进行定制开发。库所依赖的框架倾向于鼓励弱耦合和强内聚，但我们不再需要考虑它了。
★ 原则 76 和 84 可能是所有原则中最重要的原则。当然，我们在过去26年见证了框架的出现，它使软件重用变得更加容易。事实上，不再称之为重用，我们就简称其为软件开发。
★随着硬件变得更快、更便宜，原则 79 变得越来越不重要。
★原则 80，如果实施更正，可能已经避免了阿丽亚娜 5 型火箭的灾难。

对于第 5 章中介绍的编码原则，全部依然有效。一些额外说明如下。
★对于原则 94，我认为现代软件工程师不需要再担心这个了。
★对于原则 96，这仍然是我的最爱之一。我一直在实践它，我的软件工程师同事认为我疯了。

对于第 6 章中介绍的测试原则，全部依然有效。一些额外说明如下。
★ 对于原则 120，谨以此向我的朋友汤姆·麦克凯布致以崇高的敬意，我认为他的指标已经不再有用。我知道没有人再使用它了。对不起，汤姆。
★ 对于原则 124，所有现代测试工具都会自动执行此操作。

对于第 7 章中介绍的管理原则，全部依然有效。一些额外说明如下。
★对于原则 129、131、132、133、134、135、137、138、140、142 和 147，如果你不相信这些，请不要成为经理。
★ 对于原则 168，对当今的大多数应用程序来说不是一个真正的问题。

对于第 8 章中介绍的产品保证原则，全部依然有效。一些额外说明：
★我最近托运了一辆自行车，几乎横跨了整个国家，当收到时，货物箱子损坏而且很多零件不见了。我联系制造商购买缺少的零件，他们告诉我，每辆自行车都不同，虽然我有型号，但每辆自行车的每个实例都是不同的。不仅如此，他们也没有记录每辆运输的自行车组装了哪些零件，因此他们不可能将丢失的零件寄给我。我很震惊。软件配置管理（如今，通常称为版本控制）应该跟踪每个组件的每个版本，以及组件版本的哪些组合构成了可行的系统，以及哪些客户拥有哪些可行的版本。我认为这应该是一个新的原则。
★对于原则 176 和 177，可能不再那么重要了。

对于第 9 章中介绍的演变原则，全部依然有效。

Alan M. Davis
2021.9

★译者序★

我不是译者，仅是一名校对者。大家让我来写这篇译者序，盛情难却，无法推脱。本书英文版是我于2017年至2020年在百度举办“代码的艺术训练营”时使用的教材。这本书的内容深受训练营学员的好评。由于之前没有中文版，对于部分英文基础不太好的同学来说，阅读有些困难。在2019年年底，十多名“代码的艺术训练营”的毕业生自发组织起来，开始了对此书的翻译工作。我从2020年5月初开始校对工作，完成全书的校对，我花费了80～100小时。由此推断，负责翻译的同学花费了数倍于此的时间。非常感谢这些同学的无私付出！

初识本书英文版是在二十多年前。当时我还在清华大学读书，在老师的指导下做一个有一定规模的软件研发项目，在项目的研发过程中，遇到了不少软件工程方面的问题。于是在那一年，我阅读了大约十本软件工程方面的图书，包括Code Complete（《代码大全》）、Rapid Development、Programming Pearls（《编程珠玑》），等等。本书是我当时在清华大学图书馆里发现的“宝贝”。我必须说，此书对我的影响非常大，很多我现在经常提起的软件工程原则，都源于对这本书的阅读。

2006年我离开清华大学，到目前为止已经在工业界工作了十多年，先后就职于多家公司。我发现，虽然我们的软件研发规模和二十多年前相比有了很大的发展，但是在软件研发理念方面的进步还是太慢了。有太多的软件从业者，虽然已经工作多年，但对软件研发的基本理念和原则了解得还是不够多。根据我的多次调查，阅读超过两本“真正的”软件工程图书的人都非常少。很多软件工程师，仍然使用非常低效甚至是错误的方法在工作！

于是在2015年，我在百度开办了“代码的艺术”面授课程，其中就重点推荐了本书的英文版。而在2017年做“代码的艺术训练营”的时候，这本书就成了指定教材。为什么要选择这本书？因为它对软件工程的内容覆盖全面，且篇幅短小。对于一个短期培训班来说，如果选择类似《代码大全》这样的图书，阅读所需要的时间就有些太多了。在这种情况下，本书的英文版是一个性价比更高的选择。另外，我常常感觉，对于一个软件工程师，具备正确的意识比掌握具体的知识更重要。如果有正确的意识，即使不记得具体的知识点，也可以在需要的时候查阅相关资料，而反过来则不是这样的。

必须要说的是，本书的英文版写于1995年，距今已经有26年。这也是很多人担心的地方—计算机技术发展得如此之快，这本书是不是已经过时了？但是，正如我在“代码的艺术”课程中对“知识”“方法”“精神”三者所做的对比，方法的变化速度远远慢于知识。尤其是在本次校对过程中，我惊奇地发现，书中真的可以说是“过时”的原则不足5个！是软件研发的方法变化太慢，还是书的内容太深刻？我想两者兼而有之。在此，我必须要对本书的作者Alan M. Davis致敬，并对书中所有原则的贡献者和历史上所有软件工程领域的大师们致敬！

在此，我要隆重介绍翻译本书的百度的同学们，他们是：叶王、马学翔、吴斌、王冰清、杨光、曾浩浩、李殿斌、甘璐、李子昂、肖远昊、贾儒、王莹、张苗、李双婕、荣文升。另外，经大家商定，将本书因翻译出版获得的稿酬全都捐赠给公益事业。

最后，所有阅读本书的软件工程师和所有准备从事软件研发的同学们，我祝愿本书能助你们取得更大的成功！

章淼博士百度BFE团队技术负责人、百度代码规范委员会主席
2021年6月14日写于百度

★原则1　质量第一★
无论如何定义质量，客户都不会容忍低质量的产品。质量必须被量化，并建立可落地实施的机制，以促进和激励质量目标的达成。即使质量没达到要求，也要按时交付产品，这似乎是政治正确的行为，但这是短视的。从中长期来看，这样做是自杀。质量必须被放在首位，没有可商量的余地。Edward Yourdon建议，当你被要求加快测试、忽视剩余的少量bug、在设计或需求达成一致前就开始编码时，要直接说“不”。

★原则7　尽早把产品交给客户★
在需求阶段，无论你多么努力地试图去了解客户的需求，都不如给他们一个产品，让他们使用它，这是确定他们真实需求的最有效方法。如果遵循传统的瀑布式开发模型，那么在99% 的开发资源已经耗尽之后，才会第一次向客户交付产品。如此一来，大部分的客户需求反馈将发生在资源耗尽之后。
和以上方法相反，可在开发过程的早期构建一个快速而粗糙的原型。将这个原型交付给客户，收集反馈，然后编写需求规格说明并进行正规的开发。使用这种方法，当客户体验到产品的第一个版本时，只消耗了 5%～20% 的开发资源。如果原型包含合适的功能，就可以更好地理解和把握最有风险的客户需求，最终产品也就更有可能让客户满意。这有助于确保将剩余的资源用于开发正确的系统。

★原则39　先确定问题，再写需求★
当面对他们认定的问题时，大多数工程师都会匆忙提供解决方案。如果工程师对这个问题的看法是正确的，那么解决方案可能奏效。然而，问题往往是难以捉摸的。例如，唐纳德·高斯（Donald Gause）和杰拉尔德·温伯格（Gerald Weinberg）描述了高层办公楼中的一个“问题”，里面的住户抱怨电梯等待时间太长。这真的是一个问题吗？这是谁的问题？从居住者的角度来看，问题可能是浪费了他们太多时间。从房主的角度来看，问题可能是入住率（及租金）可能会下降。
显而易见的解决办法是提高电梯的速度。但其他解决方法可能包括（1）增加新电梯，（2）错峰安排上班时间，（3）给快递保留一些电梯，（4）提高租金（这样业主可以接受降低后的入住率），（5）改进电梯使用的“归位算法”（homing algorithm），以便在闲置时移动到高需求楼层。这些解决方案的成本、风险和时间延迟差别巨大。而任何一个方案生效，都取决于特定的场景。在试图解决问题前，针对面临问题的人及问题的本质，要确保深入分析了所有的可能选择。在解决问题时，不要被最初方案带来的潜在兴奋所蒙蔽。方案的变化总是比构建系统的成本低。

★原则64　没有文档的设计不是设计★
我经常听到软件工程师说，“我已经完成了设计，剩下的工作就是写文档了”。这种做法毫无道理。你能想象一个建筑设计师说， “我已经完成了你新家的设计，剩下的工作就是把它画出来”，或者一个小说家说，“我已经完成了这部小说，剩下的工作就是把它写下来”？设计，是在纸或其他媒介上，对恰当的体系结构和算法的选择、抽象和记录。

★原则66　不要重复造轮子★
当电子工程师设计新的印刷电路板时，他们会查阅可用集成电路的目录，以选择最合适的组件。当电子工程师设计新的集成电路时，他们会查阅标准单元的目录。当建筑师设计新房屋时，他们会查阅预制门窗、饰条和其他组件的目录。所有这些都被称为“工程”。软件工程师经常一次又一次地重新发明组件。他们很少修补已有的软件组件。有趣的是，软件业称这种罕见的实践为“复用”，而不是“工程”。

★原则92　程序首先是写给人看的★
在计算机时代早期，计算机处理速度相对较慢，任何能够减少一些指令操作的事情都值得去做。在非常昂贵的计算机系统上，最有效地利用资源是主要目标。如今形势发生了变化。现在最有价值的资源是人力：开发软件的人力、维护软件的人力和提高软件能力的人力。除了非常少数的例外场景，程序员应该首先考虑的是，后续需要尝试理解和适配软件的人员。任何能够帮助他们的事情都应该去做（原则 87 到 91 会提供一些帮助）。执行效率也很重要（见原则63、79、94），但它们并不是互斥的。如果你需要执行效率，这没问题，但要提升程序的可读性，以免在这个过程中对相关人员造成负面影响。

★原则104　编程语言的知识没那么重要★
不管使用哪种语言，优秀的程序员都是优秀的。不管使用哪种语言，糟糕的程序员仍然是糟糕的。不可能有一个人是“优秀的C程序员”，同时是“糟糕的Ada程序员”。如果他确实在Ada语言上表现得很糟糕，那大概率在C语言上也不会表现得很好！除此之外，一个真正优秀的程序员应该可以很容易地学会一种新语言。这是因为一个真正优秀的程序员很好地理解和赞赏高质量编程的概念，而不只是了解某些编程语言的语法和语义特性。
所以，为一个项目选择语言的首要驱动力应该是什么语言更合适（见原则102），而不是程序员都在抱怨“我们只知道C语言”。如果由于项目选择了其他语言而导致一些人退出，那么这个项目很可能会更好！

書城介紹　 \|　合作申請　\|　索要書目　 \|　新手入門　\|　聯絡方式　 \|　幫助中心　\|　找書說明　 \|　送貨方式　\|　付款方式	香港用户　 \|　台灣用户　\|　大陸用户　\|　海外用户

	megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.