4 保险科技中高昂的软件维护花销从何而来?

我们直觉认为软件的花销来自于开发的花销和运行的花销,但是它的花销主要来在于改变和维护的花销。软件和汽车这样的工业品不一样,比如你花80%的钱买了汽车以后,你逐渐地花20%的钱维护汽车直到报废。软件的30%的花销在第一次开发,接着用70%的钱在改变,应对新的需求和维护。

进一步推理维护和改变的花销来自于,众大改变的花销。改变的花销服从长尾分布,一系列小开销的修改和少有的花费巨大的重大修改。比如,你修改了工资计算的模块,但突然会计部门的某个应用模块崩了,这种脆弱性会增加花销。再比如,你需要修改一个BUG,但是为了修改这个BUG,你需要修改另一个模块,为了修改那个模块,你还需要再修改一个模块,顽固性和弹性不够会增加开销。再比如,你希望复用同事的某些代码,你却发现他的代码严重依赖于某些数据库与框架。不可复用性也会增加开销。如果我们遭遇某个市场法规的重大调整,某个预期不到的商业并购,更遑论市场方向的暴涨暴跌,那花销更会呈几何级数增长。

这些现象与症状的本质是软件呈现出树状的单方向的依赖。为了尽可能降低重大改变的花销,我们需要减少软件系统中不合理的耦合。设计者不断地在耦合与聚合的交易中找到最符合当前市场需要的平衡点。

4.1 编程时有哪些窍门可以尽可能降低重大花销?

4.1.1 分清楚结构变化与行为变化,需要放在两个不同的PR中。

因为软件行为变化的修改通常是不可逆的,所以频次相对结构变化要更低,更具体。软件结构的变化是可逆的,结构变化需要比行为变化更高频,更抽象。

4.1.2 用间接力,而非直接力

程序员的第一反应是让改变简单而不是想着如何改变,当然现实中面对同事、上司和客户的压力,本能反应总是着急改变。这时候就需要相信原则而不是动物本能。 程序员宝贵的注意力首先用于如何让改变简单而不是一上来想着做简单的改变。当然,有时候让改变简单也很困难。这种情况下,就要对代码库做一些仁慈的关怀,比如加一层界面,加一些帮助函数,抽象一些逻辑,直到你觉得可以做些什么让改变变得更简单。最后,才是完成简单改变的致命一击。在事情变好前,事情总是越变越糟糕,只有你觉察到变糟糕的加速度在不断减小,你就在正确的道路上。将欲取之,必先予之。

4.1.3 如果不当心闯入了一个到处耦合的代码库而改变的需求很紧急怎么办?

这时候不是想着去改变一系列耦合的函数或者类,比如如果你发现自己不断地再重命名一个变量三次以上或许就应该停下来。可以考虑为系统加入一些冗余,在物理层面的本质上就是为电路加上一个并行的元器件,而不是连续更改N个串行的元器件。直到系统稳定运行以后再考虑解耦工作。