软件研发中的N条原则
2022-01-09点击量:127
原则1质量第一QUALITYIS#1无论如何定义质量,客户都不会容忍低质量的产品。质量必须被量化,并建立可落地实施的机制,以促进和激励质量目标的达成。即使质量没达到要求,也要按时交付产品,这似乎是政治正确的行为,但这是短视的。从中长期来看,这样做是自杀。质量必须被放在首位,没有可商量的余地。EdwardYourdon建议,当你被要求加快测试、忽视剩余的少量bug、在设计或需求达成一致前就开始编码时,要直接说“不”。原则2质量在每个人眼中都不同QUALITYISINTHEEYESOFTHEBEHOLDER软件质量没有唯一的定义。对开发者来说,质量可能是优雅的设计或优雅的代码。对在紧张环境中工作的客户来说,质量可能是响应时间或高吞吐量。对成本敏感的项目来说,质量可能是低开发成本。对一些客户来说,质量可能是满足他们所有已知和未知的需求。这里的难题是,以上要求可能无法完全兼顾。当优化某人关注的质量时,可能会影响其他人关注的质量(这就是温伯格的“政治困境”原则)。项目必须确定各因素的优先级,并清晰地传达给所有相关方。原则3高质量软件是可以实现的HIGH-QUALITYSOFTWAREISPOSSIBLE尽管我们的行业中有一些表现不佳、包含bug,或者根本无法满足客户需求的软件系统的例子,但仍然有一些成功的例子。大型软件系统可以以非常高的质量构建,但价格昂贵:每行代码高达1000美元。例如,IBM为美国宇航局的航天飞机开发的机载飞行软件,总共约300万行代码,源于严谨的软件开发过程,产品发布后每万行代码中发现的错误少于一个。作为软件开发人员,应该学习和了解已被验证、可以极大提高软件质量的方法。这些方法包括:让客户参与(见原则8)、原型设计(在全面开发之前验证需求;见原则11~13)、保持设计简单(见原则67)、审查代码(见原则98)和雇用最优秀的人(见原则130和131)。作为客户,在追求卓越的同时,要意识到随之而来的高额成本。原则4不要试图通过改进软件实现高质量DON’TTRYTORETROFITQUALITY质量无法通过软件的改进来获得。这适用于质量的任何定义:可维护性、可靠性、适应性、可测试性、安全性等。即使我们在开发过程中十分努力,使软件具备高质量也是十分不易的。如果我们不努力,又怎么可能期望获得高质量呢?这就是绝不能将“一次性原型”转换成产品的主要原因(见原则11)。原则5尽早把产品交给客户GIVEPRODUCTSTOCUSTOMERSEARLY在需求阶段,无论你多么努力地试图去了解客户的需求,都不如给他们一个产品,让他们使用它,这是确定他们真实需求的最有效方法。如果遵循传统的瀑布式开发模型,那么在99%的开发资源已经耗尽之后,才会第一次向客户交付产品。如此一来,大部分的客户需求反馈将发生在资源耗尽之后。和以上方法相反,可在开发过程的早期构建一个快速而粗糙的原型。将这个原型交付给客户,收集反馈,然后编写需求规格说明并进行正规的开发。使用这种方法,当客户体验到产品的第一个版本时,只消耗了5%~20%的开发资源。如果原型包含合适的功能,就可以更好地理解和把握最有风险的客户需求,最终产品也就更有可能让客户满意。这有助于确保将剩余的资源用于开发正确的系统。原则6促使开发者与客户的目标一致ALIGNINCENTIVESFORDEVELOPERANDCUSTOMER项目经常会因为客户和开发人员的目标不同(或不兼容)而失败。一个简单的案例是,客户希望在特定日期前获得特性1、2、3,而开发人员希望最大化营收或利润。为了最大化营收,开发人员可能会尝试完整地开发这三个特性,即使会导致项目延期。与此同时,客户可能宁愿放弃其中一个特性的一部分功能,只要能按时交付其他特性。为使双方的目标达成一致,有如下方法:(1)按优先级对需求排序(见原则50),以便开发人员了解它们的相对重要性。(2)根据需求的优先级奖励开发人员(例如,所有高优先级的需求必须完成;每完成一个中优先级的需求,开发人员可获得一些额外的小奖励;每完成一个低优先级的需求,可获得的奖励非常小)。(3)对逾期交付实行严厉的处罚。原则7要快速地开发一次性原型BUILDTHROWAWAYPROTOTYPESQUICKLY如果你已经决定开发一次性原型,那么就要用最快的方式。不用担心质量。可使用“一页纸”的需求规格说明。不用担心设计或编码中的文档。可以使用任何工具。可以使用任何编程语言,只要能够方便程序的快速开发。不用担心编程语言的可维护性。原则8看到越多,需要越多THEMORESEEN,THEMORENEEDED在软件行业,一次次见证了:提供给用户的功能(或性能)越多,用户想要的功能(或性能)就越多。当然,这与原则7(尽早把产品交给客户)、原则14(渐进地扩展系统)、原则185(软件会持续变化)以及原则201(系统的存在促进了演变)互相支持。但更重要的是,你必须为不可避免的情况做好准备。在管理和工程处理流程的每个方面都应该做好准备,一旦用户看到产品,他们就会想要更多的东西。这意味着,所产生的每个文档都应该以有利于更改的方式进行存储和组织。这意味着,配置管理流程(见原则174)必须在距离交付很长时间之前就就位。这也意味着,在软件部署后不久,你就应该准备好,以应对用户口头或书面请求的冲击。这还意味着,你选择的设计方案应使容量、输入速率和功能都很容易变更。原则9只要可能,购买而非开发IFPOSSIBLE,BUYINSTEADOFBUILD要降低不断上涨的软件开发成本和风险,最有效的方法就是,购买现成的软件,而不是自己从头开发。确实,现成的软件也许只能解决75%的问题。但考虑一下从头开发的选择吧:支付至少10倍于购买软件的费用,且要冒着超出预算100%且延期的风险(如果最后能够完成!),并且最终发现,它只能满足75%的预期。对一个客户来说,新的软件开发项目似乎最初总是令人兴奋的。开发团队也是“乐观的”,对“最终”解决方案充满了希望。但几乎很少有软件开发项目能够顺利运行。不断增加的成本通常会导致需求被缩减,最终研发出的软件可以满足的需求也许跟现成的软件差不多。作为一个开发者,应该复用尽可能多的软件。复用是“购买而非开发”原则在较小范围内的体现。可参考原则84。原则10技术优先于工具TECHNIQUEBEFORETOOLS一个没规矩的木匠使用了强大的工具,会变成一个危险的没规矩的木匠。一个没规矩的软件工程师使用了工具,会变成一个危险的没规矩的软件工程师。在使用工具前,你应该先要“有规矩”(即理解并遵循适当的软件开发方法)。当然,你也要了解如何使用工具,但这和“有规矩”相比是第二位的。我强烈建议,在投资于工具以对某项技术“自动化”之前,先手工验证这项技术,并说服自己和管理层:这项技术是可行的。在大多数情况下,如果一项技术在手工操作时不灵,那么在自动操作时也不灵。原则11跟风要小心FOLLOWTHELEMMINGSWITHCARE即使有五千万人说傻话,那仍然是傻话。安那托尔·佛朗士(AnatoleFrance)大家都做的事情,对你来说也不一定是正确的。也许它是正确的,但你也应该评估它对你所处环境的适用性。这样的例子包括:面向对象,软件度量(见原则142、143、149、150和151),软件复用(见原则84),过程成熟度(见原则163),计算机辅助软件工程(CASE,见原则22至25),原型设计(见原则11、12、13、42)。在所有案例中,以上这些方法都提供了非常积极的帮助,体现在提高质量、降低成本、提高用户满意度等方面。然而,这些好处只在它们能发挥作用的组织中才会显现出来。尽管回报显著,但是它们的作用常常被过度宣传,其实它们并不是那么必然或通用。当你学习“新”技术时,不要轻易接受与之相关的不可避免的炒作(见原则129)。要仔细阅读,理性考虑它的收益和风险。在大规模应用之前要进行试验。但同时也绝对不要忽略“新”技术(见原则31)。Davis,A.,"SoftwareLemmingineering,"IEEESoftware,10,6(September1993),pp.79-81,84.类似的原则还有很多,以上内容摘自《201PrinciplesofSoftwareDevelopment》中文版,书名是《软件开发的201个原则》。给中国软件工程师的寄语(节选)致我的兄弟姐妹们:和你们一样,我的职业生涯始于软件工程师,那是1975年,将近半个世纪之前。我认为我们在时间和国家方面的差异相当微不足道。所以,我像和我的朋友、我的同龄人一样与你交谈。26年后的今天,当我审视201PrinciplesofSoftwareDevelopment中的这201条原则时,我很高兴地宣告,几乎所有的原则都经受住了时间的考验,就像物理学中的基本原理一样。当你做软件架构设计或“抛出代码”时,不要忽视真正重要的事情。那是什么呢?是你的正直,这是你对自己的看法。如果有人要求你做一些你知道是错误的事情,你有义务阻止它。软件工程是一个美妙的职业,它使你能够进入数百个以软件为支柱的专业领域。“生生不息,繁荣昌盛。”好好享受!201PrinciplesofSoftwareDevelopment作者AlanM.Davis2021年9月全书共9章,第1章为引言,后面8章将201个软件工程的原则划分为8个大的类别:一般原则、需求工程原则、设计原则、编码原则、测试原则、管理原则、产品保证原则和演变原则。甚至你可以在空白处写上简单的,聪明的你认为的“原则”。本文由培训无忧网长沙牛耳教育课程顾问老师整理发布,希望能够对想在长沙参加影视动漫培训的学生有所帮助。更多课程信息可关注培训无忧网电脑IT培训频道或添加老师微信:15033336050...