当前位置: 首页 > Go语言, 代码艺术, 工程能力 > 正文

读《软件开发的201个原则》有感

在之前关于软件工程能力的系列文章中,笔者参考了百度章淼老师在工程能力方面的思考。并且老师也是推荐了《软件开发的201个原则》作为参考辅导资料。刚好在2024程序猿节之前章老师预告的译作终于出版了,笔者也是立马订购抢先阅读起来。不过讲句实在的,本书并没有给我眼前一亮的感觉,可能是因为大多数原则其实笔者在工程开发中就是这样实践的了,有些理所然,所以也不足为奇罢了。

本书成作于十几年前,作为一个经过现在软件工程理论深入“洗礼”过的工程师,笔者认为文中有些原则还是过时了的。我们在阅读时不可一概而论,既可不全面肯定,也不可予以否定掉。应该选择性的吸收,取其精华,弃其糟粕,作为为我所用才行。本篇文章将主要列举其中一些笔者认为重要或感触较深的原则,顺带谈谈自己的思考与感悟。

在谈这些原则之前,笔者想先介绍下本书引言中谈到的关于原则、技术、语言和工具的关系。这四者的关系本书讲的还是非常不错的,作为一个追求向上、有思考的工程师,我们需要思考这中间的概念及其联系。

(1)原则在技术和工具的支持下落地

(2)技术使用语言,并得到工具的支持

(3)语言得到工具的支持

原则(Principle)是工作的准则:原则代表了许多人从经验中总结出来的集体智慧。它们往往被描述为绝对真理(总是正确)或用作推论(当X发生时,Y将会发生)。

技术(Technique)是一种按部就班的流程,它帮助软件开发者执行一部分软件工程过程。技术倾向于强制遵循基本原则的一个子集。大部分技术会创建文档和(或)程序。许多技术也会分析现有的文档和(或)程序,或将其转变为产品。

语言(Language)由一组基本元素(如单词或图形符号)、规则和语义组成,规则可以让人们用基本元素构造出更复杂的实体(如句子、图表、模型),语义则赋予每个实体组合以意义。语言用于表达所有软件工程的产出,无论是过程中的还是最终的,那些通过技术创建或分析的文档和程序通常也会用某种语言来表达。

工具(Tool)是软件程序,可帮助软件工程师执行软件工程师中的某些步骤,它们可以是:

  • (1)作为工程师的顾问(如基于知识的需求助理)
  • (2)分析某些内容是否符合某种技术(如数据流图检查器或原则的子集)
  • (3)使软件工程师中的一些工作现实自动化(如编译器)
  • (4)辅助工程师完成一些工作(如编辑器)

 

No.原则1:质量第一

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

 

No.原则2:质量在每个人眼中都不同

软件质量没有唯一的定义。对开发者来说,质量可能是优化的设计或优雅的代码。对在紧张环境中工作的客户来说,质量可能是响应时间或高吞吐量。对成本敏感的项目来说,质量可能是低开发成本。对一些客户来说,质量可能是满足他们所有已知和未知的需求。这里的难题是,以上要求可能无法完全兼顾。当优化某人关注的质量时,可能会影响其他人关注的质量。项目必须确定各因素的优先级,并清晰地传达给所有相关方。

 

No.原则7:尽早把产品交给客户

在需求阶段,无论你多么努力地试图去了解客户的需求,都不如给他们一个产品,让他们使用它,这是确定他们真实需求的最有效方法。如果遵循传统的瀑布式开发模型,那么在90%的开发资源已经耗尽之后,才会第一次向客户交付产品。如此一来,大部分的客户需求反馈将发生在资源耗尽之后。

和以上方法相反,可在开发过程的早期构建一个快速而粗糙的原型。将这个原型交付给客户,收集反馈,然后编写需求规格说明并进行正规的开发。使用这种方法,当客户体验到产品的第一个版本时,只消耗了5%-20%的开发资源。如果原型包含合适的功能,就可以更好地理解和把握最有风险的客户需求,最终产品也就更有可能让客户满意。这有助于确保剩余的资源用于开发正确的系统。

 

No.原则29:和组织荣辱与共

业界普遍认为:日本软件工程师对待bug的态度,和美国工程师不同。尽管有许多影响因素,但有一个日本的观念与此密切相关:产品中的缺陷是公司的耻辱;软件工程引起的公司的耻辱,是工程师的耻辱。这种观念在日本比在美国更深入人心,因为日本劳动者倾向于一辈子只服务一家公司。不管在一家公司工作的时间是长还是短,这种心态是很重要的。

一般而言,当任何人发现你在产品中犯的错误时,你应该心存感激,而不是试图辩解。人非圣贤,孰能无过。过而能改,善莫大焉!当发现一个错误时,导致错误的人应该使其被周知,而不是藏着掖着。将错误广而告之有两个好处:(1)帮助其他工程师,避免同样的错误,(2)对后续的错误修正,也可以不那么抵触。

 

No.原则41:立即修复需求规格说明中的错误

如果在需求规格说明中有错误,你将付出以下代价:

  • (1)如果错误保持到系统设计阶段,定位和修复要多花5倍的代价。
  • (2)如果保持到编码阶段,要多花10倍的代价。
  • (3)如果保持到单元测试阶段,要多花20倍的代价。
  • (4)如果保持到交付阶段,要多花200倍的代价。

这是“要在需求分析解读修复错误”的最令人信服的证据。

 

No.原则66:不要重复造轮子

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

 

No.原则74:为变化而设计

在软件开发中,我们经常会遇到错误、新需求或早期错误沟通导致的问题。所有这些都会导致设计的变化,甚至在设置基线之前。而且,在设置基线和交付产品后,会出现更多的新需求。这些都意味着,你必须选择架构、组件和规范技术,以适应重大和不断的变化。为了适应变化,设计需要做到:

(1)模块化,即产品应该由独立的部分组成,每一部分可以很容易地升级或替换,以对其他部分造成最小的影响。

(2)可移植性,即产品应该很容易修改以适应新的硬件和操作系统。

(3)可塑性,即产品可以灵活地适应预期外的新需求。

(4)保证最小智力距离

(5)在智力可控范围内

(6)做到概念一致

 

No.原则82:优秀的设计出自优秀的设计师

较差的设计与较好的设计的差异,可能源于完善的设计方法、出众的训练、更好的教育或其他因素。无论如何,真正优秀的设计,是真正优秀设计者的智慧结晶。优秀设计的特征是:简洁(Clean)、简单(Simple)、优雅(Elegant)、快速(Fast)、可维护(Maintainable)、易于实现(Easy to Implement)。优秀的设计源于灵感和洞察力,而不仅是努力工作或按部就班的设计方法。对于最好的设计者要重点支持。他们才是未来。

 

No.原则92:程序首先是写给人看的

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

 

No.原则126:对“错”不对人

编写软件需要的细节和完善程度,是任何人都无法达到的。我们应该致力于不断进步,而不是尽善尽美。当你或他人在你的代码中发现错误时,公开坦诚地讨论它。与其责骂自己,不如将它当作自己和他人的学习经历。

 

No.原则126:好的管理比好的技术更重要

好的管理能够激励人们做到最好,糟糕的管理会打击人们的积极性。所有伟大的技术(CASE工具、技术、计算机、文字处理器等)都弥补不了拙劣的管理。好的管理,即使是在资源匮乏的情况下,也能产生巨大的效果。成功的软件初创公司,不是因为它们有强大的流程或者强大工具(或与此相关的优秀产品)而成功。大多数的成功都源于成功的管理和出色的市场营销。

作为一个管理者,你有责任做到最好。对于管理,没有一个普遍的“正确”等风格。管理风格必须适应于场景。在某种情形下,你是一个独裁者;仅仅几分钟后,在另外一个场景中,你又变为基于共识的领导者,这对一个成功的领导这来说并不是罕见的事件。有些管理风格是与生俱来的,有些是靠后天学习培养的。如果有必要,可以阅读书籍,并参加关于管理风格的短期培训。

 

No.原则131:人是成功的关键

具备合适经验、才能、培训的能人,是在预算内按时完成满足用户需求的软件都关键。即使没有足够的工具、语言和流程,有合适的人也会成功。即使有合适的工具、语言和流程,没有合适的人(或者由合适的人,但没有足够的培训或者经验)也很可能会失败。根据构造性成本模型(COCOMO)估算,最优秀的人的效率是普通人的四倍。如果最优秀的人话费四倍的薪水,你可以做到收支平衡,那么雇佣他们是值得的,因为最终你很可能会得到一个更好的产品。如果他们的花费没有那么多,你降低了成本,还得倒了更好的产品。这是双赢。

在面试候选人时,记住,人才质量是无法替代的。在面试完两个人后,公司HR经常说,“面试者x比y更好,但是y已经足够好了,而且成本更低”。你不可能有一个全明星阵容的组织,但是,除非你现在拥有的超级明星过多,否则雇佣这些明星吧!

 

No.原则162:预先了解风险

在任何软件项目中,都无法准确预测会出现什么问题。然而,总有地方会出现问题。在项目计划的早期阶段,要梳理与你的项目相关的最大风险列表。对于每个风险,要量化其真正发生时会带来的破坏程度,并量化这种损失发生的可能性。这两个数字的乘积,是你对待定风险的“风险敞口”。

在项目开始时,构建一棵决策树,梳理所有可能降低风险敞口的方法。然后要么立刻对可能造成的后果采取行动;要么制订计划,在风险敞口超过可接受范围时,采取某种措施。(当然,需要预先说明如何识别这些风险,以便趁早采取纠正措施。)

附 《软件开发的201个原则》(中译本)https://mp.weixin.qq.com/s/VQi2LjRYQyVHkz-yABWd2Q



这篇博文由 s0nnet 于2021年10月30日发表在 Go语言, 代码艺术, 工程能力 分类下, 通告目前不可用,你可以至底部留下评论。
如无特别说明,独木の白帆发表的文章均为原创,欢迎大家转载,转载请注明: 读《软件开发的201个原则》有感 | 独木の白帆
关键字: , ,
【上一篇】

读《软件开发的201个原则》有感:目前有2 条留言

  1. 0楼
    athena:

    大佬你好。

    2021-12-02 上午10:26 [回复]
  2. 0楼
    athena:

    你们公司招软件逆向人员吗

    2021-12-02 上午10:28 [回复]

发表评论

快捷键:Ctrl+Enter