查看原文
其他

豆瓣9.1分:软件开发的201个原则

程序猿DD 2021-12-11

给中国软件工程师的寄语

(节选)

致我的兄弟姐妹们:

和你们一样,我的职业生涯始于软件工程师,那是1975年,将近半个世纪之前。我认为我们在时间和国家方面的差异相当微不足道。所以,我像和我的朋友、我的同龄人一样与你交谈。

26 年后的今天,当我审视201 Principles of Software Development中的这201 条原则时,我很高兴地宣告,几乎所有的原则都经受住了时间的考验,就像物理学中的基本原理一样。

当你做软件架构设计或“抛出代码”时,不要忽视真正重要的事情。那是什么呢?是你的正直,这是你对自己的看法。如果有人要求你做一些你知道是错误的事情,你有义务阻止它。

软件工程是一个美妙的职业,它使你能够进入数百个以软件为支柱的专业领域。

“生生不息,繁荣昌盛。”好好享受!

201 Principles of Software Development 作者 Alan M.Davis

2021年9月

  • 有些人重视代码编写技巧,而轻视软件开发的工程属性。
  • 有些人在对需求缺乏真正理解的时候就急于编写代码。
  • 有些人重视软件的功能实现,轻视文档对于软件开发和软件作品的重要性。

这些问题导致软件宕机、返工等质量问题时有发生。

01 了解基本原则的工程师,代码质量和开发效率更胜一筹

关于软件质量,业界普遍认为有3个决定性要素:人、过程和工具。如何基于这些要素提升代码的质量和开发效率,是软件工程研究者和实践者一直在努力的方向。

不同的公司有不同的文化背景,虽然开发不同的软件项目有不同的实践过程,但所要遵守的基本原则都是一样的。大量实践证明——

了解软件开发基本原则的工程师,比那些不了解基本原则的,编写代码的质量和开发效率明显胜出一筹。

原则 1 质量第一QUALITY IS #1

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

原则 7 尽早把产品交给客户GIVE PRODUCTS TO CUSTOMERS EARLY

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

原则 17 只要可能,购买而非开发IF POSSIBLE, BUY INSTEAD OF BUILD

要降低不断上涨的软件开发成本和风险,最有效的方法就是,购买现成的软件,而不是自己从头开发。确实,现成的软件也许只能解决 75% 的问题。但考虑一下从头开发的选择吧:支付至少 10 倍于购买软件的费用,且要冒着超出预算 100% 且延期的风险(如果最后能够完成!),并且最终发现,它只能满足 75% 的预期。对一个客户来说,新的软件开发项目似乎最初总是令人兴奋的。开发团队也是“乐观的”,对“最终”解决方案充满了希望。但几乎很少有软件开发项目能够顺利运行。不断增加的成本通常会导致需求被缩减,最终研发出的软件可以满足的需求也许跟现成的软件差不多。作为一个开发者,应该复用尽可能多的软件。复用是“购买而非开发”原则在较小范围内的体现。

原则 22 技术优先于工具TECHNIQUE BEFORE TOOLS

一个没规矩的木匠使用了强大的工具,会变成一个危险的没规矩的木匠。一个没规矩的软件工程师使用了工具,会变成一个危险的没规矩的软件工程师。在使用工具前,你应该先要“有规矩”(即理解并遵循适当的软件开发方法)。当然,你也要了解如何使用工具,但这和“有规矩”相比是第二位的。我强烈建议,在投资于工具以对某项技术“自动化”之前,先手工验证这项技术,并说服自己和管理层:这项技术是可行的。在大多数情况下,如果一项技术在手工操作时不灵,那么在自动操作时也不灵。

原则 37 要承担责任TAKE RESPONSIBILITY

在所有工程学科中,如果一个设计失败,工程师会受到责备。因此,当一座大桥倒塌时,我们会问“工程师哪里做错了?”当一个软件失败了,工程师很少受到责备。如果他们被责备了,他们会回答,“肯定是编译器出错了”,或“我只是按照指定方法的 15 个步骤做的”,或“我的经理让我这么干的”,或“计划剩余的时间不够”。事实是,在任何工程学科中,用最好的方法也可能产出糟糕的设计,用最过时的方法也可能做出精致的设计。不要有任何借口。如果你是一个系统的开发者,把它做好是你的责任。要承担这个责任。要么做好,要么就压根不做。

02 一部亚马逊评分4.5分、豆瓣9.1分的领域经典著作,用【原则】讲透软件研发重要思想

对于一个软件工程师,具备正确的意识比掌握具体的知识更重要。如果有正确的意识,即使不记得具体的知识点,也可以在需要的时候查阅相关资料,而反过来则不是这样的。

畅销全球26年、软件开发领域经典著作201 Principles of Software Development,就是第一本以“原则”形式讲透软件研发重要思想,并影响无数从业者的传世宝典。

(亚马逊官网评分4.5分)

这本书沉淀了大量软件工程领域的理念及洞察,它们不是最新的,却是最稳定的那部分。书中每一个原则短小精悍,既独立成文,又相互联系,全面覆盖软件工程生命周期中的需求、设计、编码、测试和维护。

由于之前没有中文版,对于部分英文基础不太好的读者来说,阅读有些困难。在2019 年年底,十多名百度技术学院毕业生自发组织起来,开始了对此书的翻译工作。

03 《软件开发的201个原则》中文版正式出版

经过两年多的打磨,《软件开发的201个原则》中文版终于落地中国。

本书的英文版写于1995 年,距今已经有26 年。这也是很多人担心的地方——计算机技术发展得如此之快,这本书是不是已经过时了?正如译者所说,

是软件研发的方法变化太慢,还是书的内容太深刻?我想两者兼而有之。

内容介绍

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

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

  • 用【原则】讲透软件研发底层方法

从需求分析到产品演进,覆盖产品研发全流程。

  • 首本实现【轻阅读】的研发工具书

201个原则独立成文,简练深刻,轻松阅读。

  • 中文版采用【精装珍藏版】设计,向经典致敬。

一经上市,读者热情反馈:

献给每一位追求卓越的软件工程师

软件工程是一个美妙的职业,它使你能够进入数百个以软件为支柱的专业领域。

正如斯波克所说,“生生不息,繁荣昌盛。”

好好享受!

如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连


抽奖赠书


截止时间:2021年11月26日 17:00

如何抽奖:点击下方卡片,关注并回复关键词 :20211122



下次你更希望我们送哪本书呢?

留言告诉我们!

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存