正版 软件开发的201个原则 (美)艾伦·M.戴维斯(Alan M. Davis)著

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

[美]艾伦·M.戴维斯(Alan M.Davis)，Offtoa 公司联合创始人兼首席执行官（2012年至今）；曾任Omni-Vista 公司的联合创始人、董事长兼首席执行官，Requisite 公司的董事会创始成员，BTG 公司副总裁。 学术界经历包括：科罗拉多大学行政 MBA 创业教授，前任学术主席（2006—2018）；科罗拉多大学科罗拉多斯普林斯分校的商业战略和创业教授；前 El Pomar 软件工程教授（1991—2015）。

1.一本影响全球万千软件工程师的传世经典，畅销全球26年，2021年首次落地国内。

2.IT名企软件工程师一人一本的案头宝典，书中201个原则独立成节，短小精炼，全面覆盖。

3.原则1：质量第一。原则7：尽早把产品交给客户。原则39：先确定问题，再写需求。原则64：没有文档的设计不是设计。原则66：不要重复造轮子。

4.原则92：程序首先是写给人看的。原则104：编程语言的知识没那么重要。原则123：不要在单元测试之前集成。原则127：好的管理比好的技术更重要。原则185：软件会持续变化。
5.本书为百度“代码的艺术训练营”指定教材。




★很高兴看到201 Principles of Software Development的中译本即将出版。这本书的出版对于提升国内软件工程师的素养、学习国外先进的软件工程理念，必将做出积极的贡献。这本书通俗易懂，每一个原则短小精悍，既独立成文，又相互联系，是难得一见的软件工程领域的好书，特别适合用于企业培训中心对在职工程师的培训，可使受训者的工程能力和工程素养得到较大提升。

——陈尚义 百度技术委员会理事长
★虽然书中的201个原则总结于20多年前，但是其中绝大多数原则还能很好地适用于当今这个时代。我相信，这本书一定会对中国的广大软件工程师起到很大的帮助作用，并且对推动中国软件工程行业的健康发展产生良好的影响。我在此向中国广大软件工程师们强烈推荐这本书！
——裴丹 清华大学计算机系长聘副教授、博士生导师；清华大学计算机系本科生必修课“软件工程”课程的任课教师
★从以过程为中心到以人为中心，再到以工具链为中心，这些年软件工程经历了令人眼花缭乱的变革。未来，软件新技术、新架构和新业务还会不断涌现，软件工程仍然会变革，但不变的是Alan这本书中介绍的201个原则。
——钱岭 中国移动云能力中心首席科学家
★《软件开发的201个原则》是软件工程领域不可多得的经典图书，内容简明扼要、历久弥新。书中所述原则是工程师开发过程中的一盏明灯，在困惑彷徨时翻阅使人茅塞顿开。本书是百度“代码的艺术训练营”的教材，受到工程师的广泛好评；受益于本书所述的原则，百度的工程师自发翻译此书，希望惠及更多工程师。
——陈竞凯&吴华 百度技术委员会主席
★去年在Gopher China大会上第一次听章博士分享《软件开发的201个原则》这本书，我非常震撼。之前自己在软件开发过程中摸索的一些规则，在这本书中都有讲述。自此之后只要提到工程师提升，我必定首推这本书，因为它把软件工程师所需具备的软实力进行了细致分解和精辟总结。这本书的中文版终于正式出版了，强烈推荐大家去读一读，将使你终生受益。
——谢孟军 Gopher China社区创始人，积梦智能CEO

★此书总结的不仅是软件开发的基本原则，而是适用领域更广的工程师哲学提炼。相信你和我一样，会从中找到共鸣，并激发思考，得到如获至宝的喜悦。融会贯通这201个原则会是一个漫长的过程，（软件）工程师“内力修为”的提升却已从你翻开这本“心法秘籍”的那一刻开始了……
——胡成臣 Xilinx亚太区CTO office和亚太区实验室负责人
★软件工程是一个系统性学科。从需求、编码、测试到管理，每一位工程师都要了解其基础方法论。本书通过短小精炼的不同篇章，串连起了软件开发中的内核和上层指导思想。原著虽写于1995年，但其阐释的“知识、方法、精神”却没有随时间的更迭而褪色。
——单致豪 腾讯开源联盟主席
★这是一本软件工程的经典图书，是一本将软件开发从“术”升华为“道”的著作。本书不仅总结了软件开发的一般性原则，还将软件开发过程中从需求分析、设计到编码、测试等全链条所需要遵守的原则一一进行了列举。作为百度“代码的艺术训练营”的教材，本书极具操作性。百度团队不辞辛劳将该书翻译为中文，是广大软件工程师的福祉。
——龙飞 中国搜索技术研发部主任
★经典之所以成为经典，在于它历久弥新，常看常新。本书是软件工程领域的一本经典著作，虽然自其发表至今的26年间，软件开发的语言、工具、技术、方法都发生了巨大的变化，但这201个原则中的绝大部分在当下仍然适用。这些原则不仅覆盖了软件开发从需求分析到设计、编码、测试的各个工作环节，同时还针对相关的团队和项目管理总结了很多宝贵经验，对于参与软件开发的每个人以及管理者都有很好的借鉴意义。
——陆薇 昆仑数据创始人&CEO
★这本书的英文原版写于1995年，当时我还在读大学本科。限于当时的信息还不是很发达，很遗憾没有了解和读到这本书。时隔20多年，软件产业的规模和迭代速度发生了很大的变化，但其核心的原则和方法并未发生根本性改变。编写高质量的软件仍然因为其高度的灵活性和复杂性以及高速迭代，是一件需要持久追求的目标，本书中总结的原则也仍然是软件行业从业者的宝典。非常感谢章淼博士及其同事将这本书带到国内并进行了翻译，希望每一位读者都能从阅读此书中受益！
——叶航军 小米集团技术委员会主席
★当今的社会是软件驱动世界，软件工程的基本原则不可不知。讲述软件工程方法论的图书汗牛充栋，本书是一本很好的索引和汇编，是软件行业从业者应该考虑的一本枕边书。少即是多，当你无所适从时，想一下这本书。读者朋友们将会发现，这些原则是我们思考、讨论、发现、分析、解决问题的百宝箱，如何融会贯通地使用、与时俱进地发展，需要不断修炼，这也是软件行业从业者的乐趣所在。
在这个行业，翻译20多年前的书可称之为“考古”。非常佩服翻译小组追求“先贤”智慧、寻求软件工程底层驱动、无私奉献的精神。
——李中杰 高德研发效能中心负责人

★近日人社部的一份报告提出了“新生代农民工”的概念，引起了IT朋友圈的一阵自嘲和调侃。新的技术、框架甚至编程语言层出不穷，年轻一代从业者对新技术如数家珍，而“设计模式”“原则”等集前人智慧之大成之作，却因年代久远而被逐渐遗忘。感谢章淼博士和百度的同事将这本经典图书精心翻译出来，相信对当代管理者、产品设计、研发、测试等岗位有重要指导意义。许多夜不能寐的苦思冥想，也许前人早有答案。
——马越 开源中国CEO
★日复一日的工作使我们很多时候不再有更深层次的思考，解决事情的方式不再追求本质、高效、突破，久而久之，对很多事情没有了好奇心，对于应极具创造性的工程师来说这是很可怕的。真正的优秀来自不断更新自我，向往有意义、有追求的创新目标，同时坚守基本原则、回归技术本质。这本书的内容具有导师般的智慧，简短有力，直击本质，希望能对每一位软件工程师有所启迪，帮助大家多多交付杰出产品。
——刘付强 麦思博（msup）创始人兼CEO
★软件与芯片是电子信息领域的核心技术。当前，我国正面临核心关键技术上的挑战，《软件开发的201个原则》的出版正逢其时。正如本书推荐序中所说，软件工程、软件研发的理念在我国的普及程度还不高，需要更大力度地宣传与学习。以百度公司章淼博士为代表的诸位专家是软件开发先进理念与原则的实践者与推广者，相信他们完成的这本精品译著将给广大读者带来巨大的收获与惊喜！
——喻文健 清华大学计算机系软件所所长

★本书让我联想起了哲学领域的《沉思录》，虽然创作时代久远，但每次阅读总能从中得到新的启发，常读常新。这是一本可以时常翻阅的手册，对于初学者和有一定经验的开发人员都非常有用，通俗易懂又内涵深刻。书中的每个原则背后都凝练了软件开发者的智慧，相信能够在一定程度上帮助软件开发人员写出更规范、更优雅的代码。
——祁宁 思否（SegmentFault）创始人、CTO，Typecho开源博客系统作者
★软件是一个程序员最看重的宝贝，是心血所系。怎样把这个宝贝培养好，让其茁壮成长甚至面对变化不断蜕变涅槃，恐怕会有很多事与愿违的烦恼。感谢译者的努力，为大家提供了一本专业的“育儿指南”。
——王龙 华为北冥实验室主任
★最近常听到10x 程序员的说法，意思是，优秀程序员的生产效率可以达到普通程序员的10倍。我的确遇到过特别优秀的程序员，也许没有10倍那么夸张，但他们的确是团队甚至企业的中流砥柱。据我观察，10x程序员并非天生。他们更积极地探索未知的领域，更努力地磨炼自己的技艺，不知不觉间达到了出神入化的境界。每个程序员都可以不断修炼提升自己的境界。修炼过程中借鉴前人的经验可以事半功倍。本书是一本简洁实用的软件工程经典，其中的原则覆盖了从需求分析到产品演进的软件研发全流程。经过了20多年，书中超过95%的原则都没有过时，可谓经得起时间的检验。谨把此书推荐给软件从业者，希望中国软件行业能涌现出更多的10x程序员。
——张迎辉 敏捷教练/DevOps教练

★理解深层次的软件开发原则将帮助工程师更好地利用开发方法构建高质量的软件工程。《软件开发的201个原则》是一本软件工程原则集，覆盖管理、需求、设计、编码、测试、演变等软件开发全流程。这本书不涉及具体技术、语言或工具，系统地梳理了软件开发趋势背后的基本原理，历时26年，仍广受认可。相信阅读此书的软件从业者或即将从事软件开发行业的人员都将受益匪浅。
——郭雪 中国信通院云大所云计算部副主任
★什么是软件工程能力？如何定义一个人、一个组织的工程能力？是有趣并值得深入探讨的事情。《软件开发的201个原则》这本书给了我们很多启发和指引。
软件工程师只有对软件研发有系统性的认知，才有可能持续成长，一个团队亦然。这本书沉淀了大量软件工程领域的理念及洞察，它们不是zui xin的，却是zui稳定的那部分。希望大家在工作和学习的同时，能够在软件开发的各生命周期，不断去验证、去回顾这201个原则，真正的深度思考将会让我们受益匪浅。
——陈曦 招商银行首席IT工程师

作者序 在1995年版的序言中，我写道， 如果软件工程真的是一门工程学科，那么它是对经过验证的原则、技术、语言和工具的智慧的运用，用于有成本效益地创造和维护能够满足用户需求的软件。本书是有史以来本成册的软件工程原则集。原则是关于软件工程的基本原理、规则或假设，不管所选的技术、工具或语言是什么，其都有效。 26年后的今天，当我审视这201条原则时，我很高兴地宣告，几乎所有的原则都经受住了时间的考验，像物理学中的基本原理一样。 然而，在这26年里，因为软件造成的问题相当之多。举几个例子： 波音 737 MAX 机动特增强系统（MCAS）的单点故障导致了两起空难，共造成 346 人死亡，调查结果是软件测试不。 全球范围的软件系统反复被勒索软件攻击，表明软件存在漏洞。 一个无法预测且未被发现的溢出错误导致人类飞行控制员必须在发射后立即销毁阿丽亚娜 5 型运载火箭。 火星气候轨道飞行器坠毁在火星上，原因是两个程序员关于变量的单位出现错误沟通：一个认为是磅，另一个认为是牛顿。 当桥梁或建筑物倒塌时，调查人员会尝试确定是什么地方出了问题。通常，是因为建筑商未能遵守建筑规范（即施工期间要遵循的一套规则或原则），或者检查员未能找到物理损坏的位置。当软件失败时，通常是因为软件工程组织没有遵守某个原则。 理解和实践一门学科的所有原则是否可以所有灾难？不是。它只降低因你而导致灾难的可能。正如亚历山大&mot;波普所说，“犯错是人之常情。”只有通过犯错，我们才能学制定新的原则。 在这本书中发表的大部分原则并非原创，很多是从软件工程从业者和研究者的著作中摘录而来的。这些人无私地和我们分享他们的经验、想法和智慧。我并不认为这201个原则是相互独立的。不像Boehm提出的7个“基本”软件工程原则，本书中的一些原则的组合可能蕴涵另一个原则。但我也不认为这201个原则中的某两个或某几个原则是 兼容的。俗话所说的，“距离产生美”和“眼不见，心不烦”都是真理，每个原则都可以应用在我们的生活中，但是它们却不能同时用来证明同一个决定是正确的。本书含的原则都是有效的，它们都能够用来提升软件工程的，但也许并不能将某些组合应用到同一个项目中。 本版中的原则与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，谨以此向我的朋友汤姆&mot;麦克凯布致以崇高的敬意，我认为他的指标已经不再有用。我知道没有人再使用它了。对不起，汤姆。 对于原则 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.一本影响全球万千软件工程师的，全球26年，2021年落地国内。 2.IT名企软件工程师的案头宝典，书中201个原则独立成节，短小精炼，覆盖。 3.原则1：质量。原则7：尽早把产品交给客户。原则39：先确定问题，再写需求。原则64：没有文档的设计不是设计。原则66：不要重复造轮子。 4.原则92：程序首先是写给人看的。原则104：编程语言的知识没那么重要。原则123：不要在单元测试之前集成。原则127：好的管理比好的技术更重要。原则185：软件会持续变化。 5.本书为百度“代码的艺术训练营”指定教材。