软件开发的201个原则

1星价 ¥57.8 (5.5折)

2星价￥57.8 定价￥105.0

作者：（美）AlanM.Davis（艾伦·M．

出版社：电子工业出版社

本类榜单：计算机/网络

分类：计算机/网络 > 软件工程/开发项目管理

暂无评论

图文详情

ISBN：9787121419973
装帧：一般纯质纸
册数：暂无
重量：暂无
开本：其他
页数：288
出版时间：2021-10-01
条形码：9787121419973 ; 978-7-121-41997-3

本书特色

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

内容简介

本书汇总了软件工程原则。原则是关于软件工程的基本原理、规则或结论，不管所选的技术、工具或语言是什么，这些原则都有效。全书共9章，章为引言，后面8章将201个软件工程的原则划分为8个大的类别：一般原则、需求工程原则、设计原则、编码原则、测试原则、管理原则、产品保证原则和演变原则。

节选

★原则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语言”。如果由于项目选择了其他语言而导致一些人退出，那么这个项目很可能会更好！

作者简介

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

本类五星书