复用的双刃剑：软件工程里的悖论与挑战

正文

请到「今天看啥」查看全文

饱受争议 的业务中台

• 天然的不确定性

技术基建不可或缺，但作为驱动业务增长的技术团队，绝大多数时间一定都是投在业务项目上。这也是为什么业务中台难做，但还是一直在尝试的主要原因。2000亿的市场但凡啃下5%，那也是百亿级的规模。

曾经我的一位主管说过，业务技术团队比中间件技术团队挑战更高。纯技术团队解决的问题是确定性的，如何减少RT、如何提高吞吐，这一整年甚至好几年都只有这一个命题。但业务团队不一样，今天要打渗透，明天要做拉新，后天又有新打法出来。并且也没人能保证这样做了业务就一定会成功，业务是极具不确定性的。

• 对现实世界的抽象

任何一个业务中台的失败都可以归咎于“我们没抽象好，并非这条路不对”。如同盲人摸象，昨天我们收集的信息认为这是一堵墙，今天我们获取到的知识又觉得像是一堵墙加一根绳子，明天我们总结的经验又告诉我们，应该是一堵墙加一根绳子加四个柱子。我们可以不断接近真相，但每一次模型的升级却并非如我们自己知识的更新这般容易。

• 高昂的成本与未知的稳定性

在中台已有的扩展能力范围内，调整业务逻辑相对是容易的。但业务的特点就是不确定性，当业务的变化需要中台团队改变来做出适配时，往往这个合作过程会相当痛苦。业务团队想用一个简单的if解决这个业务场景的变化，中台团队则倾向于再抽象一层。

而抽象性与其本身的表达能力是向左的， 抽象层次越高，表达能力越低，越难以理解。 最终业务团队越来越难用好中台系统，而中台系统离业务也越来越远。

中台的抽象往往不是针对某一单一的业务场景，而是适配所有已接入的业务系统以及面向未来可能的扩展性。这会导致任何一处的改动，产生的影响范围都具有极高的认知成本。随着人员的不断更迭，现有系统的维护者，可能不认识系统里90%的代码，于是有那张图：「系统非常稳定，请不要随意改动代码」。

软件工程的成本在哪里

In software engineering, cost estimation is often a more difficult task than in other engineering disciplines due to the intangibility of software.

译：在软件工程中，成本估算往往比其他工程学科更困难，因为软件是无形的。

Grady Booch 《Object-Oriented Analysis and Design with Applications》

复用本身最直接的目的就是降低成本，同样的事只用干一次，那软件工程的成本到底在哪里？Grady Booch在 Object-Oriented Analysis and Design with Applications 中表示「软件是无形的，软件的成本不易评估」。类似我们平常评估需求工时，到底是3人日还是还是3.5人日，其实很难有一个准确的测算。

▐ 确定性的开发成本

虽然成本无法准确测算，但我们依然给出了一个相对“确定”的工时人天，囊括从需求分析、方案设计、编码开发、协调测试、发布上线等各个流程。无论准确与否，我们也确实在按照这种模式运作。3人日或5人日，整体差异不会太大。往往我们也在追求，如何以最少的开发成本来支撑更多的业务需求，无论是在当下还是基于以后。但软件的成本，真的就是等同于开发成本吗？

▐

请到「今天看啥」查看全文