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