V2热帖:要多健壮的代码才能支撑起千变万化的需求?

一、健壮性定义

计算机科学中,稳健性(英语:Robustness)是指一个计算机系统在执行过程中处理错误,以及算法在遭遇输入、运算等异常时继续正常运行的能力。 诸如模糊测试之类的形式化方法中,必须通过制造错误的或不可预期的输入来验证程序的稳健性。很多商业产品都可用来测试软件系统的稳健性。稳健性也是失效评定分析中的一个方面。

二、高赞回答摘取

  1. 引入测试,持续重构

处理千变万化的业务,最好办法就是引入测试(单元测试、集成测试),然后根据需求持续重构,而不是在之前的代码上修修改改。代码即模型,业务变了意味着模型也变了,想用一套代码处理所有业务,意味着想用一套模型去处理所有业务,不存在这种神奇的银弹。

  1. 另辟蹊径,从产品的角度重新审视问题

典型的程序员思维。如果出现千变万化的需求说明你们公司应该换一个带脑子的产品经理。

代码不需要健壮,开发人员足够健壮就行,就可以让提需求的人主动闭嘴,把千变万化的需求消灭在萌芽里。

  1. 代码要足够简单易懂

代码要足够简单易懂,秀技术过段时间自己都看不懂,更何况别人。

  1. 问题往往来源于产品和需求,同2

很难。很多情况是,功能A不需要做,以后也不会有,不用考虑这个功能,不需要设计那么复杂,快上线。过一段时间,A功能需要做,马上就要,这周就要上线。

  1. 误用滥用“开闭原则”

开闭原则(OCP): 如果系统想要容易被改变,那么其设计就必须允许只靠增加代码来改变系统行为,而非只能修改原有代码。

以前所在的团队,我们写代码遵循两条原则:1、以前的旧代码,能不动就不动。 2、添加新代码的时候,尽可能少的对旧代码进行修改。正是因为这两条原则,使得垃圾代码越堆越高。

  1. 持续的迭代和重构

纯靠设计来防止垃圾代码越堆越高根本不现实,项目早期的时候,我们会对未来需求的预测来设计代码结构。 刚开始可能设计良好,一两年以后,新的需求与早期的预测差别越来越大,这时老的设计已经无法通过扩展代码的方式来满足新的需求了,这时如果不对部分代码进行翻新,垃圾代码就会慢慢堆积起来。

  1. 拥抱演进式设计

遗憾的是管理者、乃至技术架构师都不能真正地接受演进式设计( Evolutionary Design ),尤其不能接受一个具有良好设计的系统,应该是能够被报废的,潜意识中总会希望系统建设能够一步到位,至少是“少走几步能到位”。 摘自 [凤凰架构]

三、热帖来源

原文地址:https://www.cnblogs.com/echo1937/p/15181027.html