软件开发的201个原则 必读经典简装本

"1.一部英文原著亚马逊4.5高分，畅销全球26年的领域经典——首次落地中国。 2.用【简单原则】讲透软件研发重要思想——从需求分析到产品演进，覆盖产品研发全流程。 3.首本实现【轻阅读】的研发字典书——201个原则独立成文，简练深刻，轻松阅读。 4.百度技术学院【指定用书】——掌握科学的方法，效率提高不止100%。 5.原则1：质量第一。原则7：尽早把产品交给客户。原则39：先确定问题，再写需求。原则64：没有文档的设计不是设计。原则66：不要重复造轮子。 6.原则92：程序首先是写给人看的。原则104：编程语言的知识没那么重要。原则123：不要在单元测试之前集成。原则127：好的管理比好的技术更重要。原则185：软件会持续变化。"

本书汇总了软件工程原则。原则是关于软件工程的基本原理、规则或假设，不管所选的技术、工具或语言是什么，这些原则都有效。
全书共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 封装
……