开发者社区> 超努力的写代码> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

软件研发中的N条原则

简介: 软件研发中的N条原则
+关注继续查看

原则 1 质量第一 

QUALITY IS #1 


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


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

QUALITY IS IN THE EYES OF THE BEHOLDER 


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


原则 4 高质量软件是可以实现的 

HIGH-QUALITY SOFTWARE IS POSSIBLE 


尽管我们的行业中有一些表现不佳、包含 bug,或者根本无法满 足客户需求的软件系统的例子,但仍然有一些成功的例子。大型软件 系统可以以非常高的质量构建,但价格昂贵:每行代码高达 1000 美 元。例如,IBM 为美国宇航局的航天飞机开发的机载飞行软件,总共 约 300 万行代码,源于严谨的软件开发过程,产品发布后每万行代码中发现的错误少于一个。作为软件开发人员,应该学习和了解已被验证、可以极大提高软件质量的方法。这些方法包括:让客户参与(见原则 8)、原型设计 (在全面开发之前验证需求;见原则 11~13)、保持设计简单(见原 则 67)、审查代码(见原则 98)和雇用最优秀的人(见原则 130 和 131)。作为客户,在追求卓越的同时,要意识到随之而来的高额成本。


原则 5 不要试图通过改进软件实现高质量

DON’T TRY TO RETROFIT QUALITY 


质量无法通过软件的改进来获得。这适用于质量的任何定义:可 维护性、可靠性、适应性、可测试性、安全性等。即使我们在开发过 程中十分努力,使软件具备高质量也是十分不易的。如果我们不努力, 又怎么可能期望获得高质量呢?这就是绝不能将“一次性原型”转换 成产品的主要原因(见原则 11)。


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

GIVE PRODUCTS TO CUSTOMERS EARLY 


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


原则 9 促使开发者与客户的目标一致 

ALIGN INCENTIVES FOR DEVELOPER AND CUSTOMER 


项目经常会因为客户和开发人员的目标不同(或不兼容)而失败。一个简单的案例是,客户希望在特定日期前获得特性 1、2、3,而开 发人员希望最大化营收或利润。为了最大化营收,开发人员可能会尝 试完整地开发这三个特性,即使会导致项目延期。与此同时,客户可 能宁愿放弃其中一个特性的一部分功能,只要能按时交付其他特性。为使双方的目标达成一致,有如下方法:(1) 按优先级对需求排序(见原则 50),以便开发人员了解它 们的相对重要性。(2) 根据需求的优先级奖励开发人员(例如,所有高优先级的 需求必须完成;每完成一个中优先级的需求,开发人员可 获得一些额外的小奖励;每完成一个低优先级的需求,可 获得的奖励非常小)。(3) 对逾期交付实行严厉的处罚。


原则 13 要快速地开发一次性原型 

BUILD THROWAWAY PROTOTYPES QUICKLY 


如果你已经决定开发一次性原型,那么就要用最快的方式。不用担心质量。可使用“一页纸”的需求规格说明。不用担心设计或编码中的文档。可以使用任何工具。可以使用任何编程语言,只要能够方 便程序的快速开发。不用担心编程语言的可维护性。


原则 15 看到越多,需要越多 

THE MORE SEEN, THE MORE NEEDED 


在软件行业,一次次见证了:提供给用户的功能(或性能)越多, 用户想要的功能(或性能)就越多。当然,这与原则 7(尽早把产品 交给客户)、原则 14(渐进地扩展系统)、原则 185(软件会持续变化) 以及原则 201(系统的存在促进了演变)互相支持。但更重要的是, 你必须为不可避免的情况做好准备。在管理和工程处理流程的每个方 面都应该做好准备,一旦用户看到产品,他们就会想要更多的东西。这意味着,所产生的每个文档都应该以有利于更改的方式进行存 储和组织。这意味着,配置管理流程(见原则 174)必须在距离交付很长时间之前就就位。这也意味着,在软件部署后不久,你就应该准备好,以应对用户口头或书面请求的冲击。这还意味着,你选择的设计方案应使容量、输入速率和功能都很容易变更。


原则 17 只要可能,购买而非开发

IF POSSIBLE, BUY INSTEAD OF BUILD 


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


原则 22 技术优先于工具 

TECHNIQUE BEFORE TOOLS 


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


原则 30 跟风要小心 

FOLLOW THE LEMMINGS WITH CARE 


即使有五千万人说傻话,那仍然是傻话。 

安那托尔·佛朗士(Anatole France) 


大家都做的事情,对你来说也不一定是正确的。也许它是正确的, 但你也应该评估它对你所处环境的适用性。这样的例子包括:面向对 象,软件度量(见原则 142、143、149、150 和 151),软件复用(见 原则 84),过程成熟度(见原则 163),计算机辅助软件工程(CASE, 见原则 22 至 25),原型设计(见原则 11、12、13、42)。在所有案 例中,以上这些方法都提供了非常积极的帮助,体现在提高质量、降 低成本、提高用户满意度等方面。然而,这些好处只在它们能发挥作 用的组织中才会显现出来。尽管回报显著,但是它们的作用常常被过 度宣传,其实它们并不是那么必然或通用。当你学习“新”技术时,不要轻易接受与之相关的不可避免的 炒作(见原则 129)。要仔细阅读,理性考虑它的收益和风险。在大 规模应用之前要进行试验。但同时也绝对不要忽略“新”技术(见 原则 31)。


Davis, A., "Software Lemmingineering," IEEE Software, 10, 6 (September 1993), pp. 79-81, 84.


类似的原则还有很多,以上内容摘自《201 Principles of Software Development》中文版,书名是《软件开发的201个原则》。


image.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
天气软件
本文研究全球及中国市场天气软件现状及未来发展趋势,侧重分析全球及中国市场的主要企业,同时对比北美、欧洲、中国、日本、东南亚和印度等地区的现状及未来发展趋势
39 0
软件设计原则
这些天草草的看了一些软件设计的书,当昨天合上最后一本的时候,突然发现自己心里啥都没记住,难道我已经达到了学习的最高境界,心中无书胜有书,我完全在放屁。两个星期没更新了,箭在弦上,不得不发。虽然只是草草的看一遍或者一部分,但在过程中也作了一些笔记,这篇文章大部分也就是我笔记的内容,比较虚,比较空,等以后我更深入了解后,再做更深入的贡献!
63 0
软件开发中的同行评审
对于任何一个软件公司来说,几乎在所有的软件项目中,都需要同行评审。一个人不管能力多强,看问题的角度总会受到限制,写出来的程序和文档等也不会是十全十美的。如果能够让懂行的同事给参阅一下,并提出他们认为正确的意见,那么势必会弥补单个开发人员思维的缺陷,并在一定程度上提高程序和产品的质量。
1752 0
2017(二)软件安装
一、挂载命令 Mount /dev/sda1 第一个分区 /dev/cdrom 光盘 /dev/hd 挂载命令: mount -t iso9660 /dev/hdc /mn...
985 0
1940
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载