“All models are wrong, some models are useful” ——George Box
没有放之四海皆准的好与坏的标准。下面我对于衡量软件架构好坏的AAA原则:
可考核(Accountable):好的软件架构让每个团队都有自己负责的业务目标
可自主(Autonomous):好的软件架构让每个团队都一定的自主性可以独立往前跑,而不总是被其他团队阻塞
可复用(Amortized):好的软件架构鼓励对未来投资,使得基础设施的成本可以被摊销
可考核>>可自主>可复用。在上世纪90年代,代码复用是面向对象社区的热门话题。然后SOA和DDD又来告诉我们“可自主”才是最重要的。但是我发现实践中,无论是“可自主”还是“可复用”都很模棱两可。很难用这两个原则去说服其他人,用X的方式来分解问题会比用Y的方式来分解问题更好。但是如果你说,这么分解可以让每个团队更可考核,就显得特别理所当然。
开发者无法估算工作量
“可考核性”是一切的关键。我认为“缺乏可考核性”是现在的软件开发模式最大的危机,这个问题比”无法管理所谓的复杂性“还要更严重。
开发者是无法估算工作量在行业里也不算什么秘密了。这带来了很多根本性问题:
因为我们无法知道真正多少人才是必须的,所以中层管理总是比着招聘人头上限,尽可能的加人。为什么会这样做?很简单,他们的薪酬和他们所管理的人头数是成正比的。
把软件重构得”更可维护“没有商业价值。什么叫可维护性?问题如果解决不了,扔更多的人进去总是可以解决的。软件工程又不是造火箭,能有多难?根本无法证明重构可以节省多少人力,因为就没有可对标的重构前的应投入人力。
要解决这个问题,我认为不是去搞明白开发工作量的评估的魔法。恰恰相反,如果我们和业务负责人是以同一个团队的方式来工作ÿ