Martin Fowler 通知咱们，不能！
那怎么办？咱们能够用以下的过程指标来领导日常的改良：
会议工夫
如果 Autonomy 的问题是高沟通老本，那么是否能够间接度量整个沟通老本。例如参加会议的工夫，这是一个可能的指标。这样的指标会有什么问题呢? 有没有更好的指标?
度量会议工夫会有如下的问题：
- 会议没有蕴含全副的沟通老本，包含面对面沟通，IM 沟通等
- 不散会可能是因为没有新需要
- 散会多可能就是因为需要多，阐明业务方兴未艾
- 散会多少只阐明了老本的高下，只有最终的效力好不就 OK 了么? 或者换句话说，只有业务赚钱不就 OK 了么?
最无效的当然是总收入，总利润这样的后果指标。然而不能一竿子判定所有的过程指标都没有意义。不可能所有人都背最终的后果指标，也不可能所有的改良都要从后果指标动手。会议工夫显然能阐明老本形成，只是这个老本是否花得值很难判断。一个劳动者只有 8 个小时的合乎劳动法的工作工夫，如果有 7 个小时都在会议上，显然可能阐明一些问题。所以我认为会议工夫做为察看性的过程指标还是有肯定意义，次要的作用是划个红线，超过了红线阐明会议太多了。
会议工夫这个指标的问题在于无奈领导改良。因为散会多，可能仅仅是需要变多了。
“接口改变”/“实现改变”比率
咱们把文件分为两种类型，负责接口的文件和负责实现的文件。现实的状况下，应该尽可能少的改接口，而是次要去改实现，这样能力缩小跨模块的人员沟通。如果一个新需要，须要同时改变 N 个模块。然而只有不须要改变接口（包含用 Map<string, any> 这样模式搞的隐式接口），依然是现实的状况。尽管产品经理须要和多个团队沟通每个局部的需要是什么，然而开发团队之间的沟通依然能够比拟少。要每个新需要都只改变一个模块由一个团队负责，这是不太事实的：
- 新商业玩法往往是破坏性的。咱们不要去做提前预测
- 需要大小是任意的，产品经理分工也是有随机性的。总是有方法把一个需要弄大到全公司只做这么一个需要的境地。
接口齐全不批改，开发人员之间齐全不沟通也是不可能的。咱们要关注的是目前的业务逻辑拆分是不是正当，多个 Git 仓库之间的接口如果须要频繁调整，那么阐明 Git 仓库是不是分得过多了，或者边界不是最佳的。要依据新的输出，一直去扫视过来做过的拆分决策。而“接口改变”/“实现改变”比率能够量化目前业务逻辑拆分是否让每个 Git 仓库有 Autonomy。这个值越小，阐明仅改变实现状况占比越高。
为了数据统计比较稳定：
- 仅做到文件级别的区别。一个文件要么属于接口，要么属于实现。个别通过技术手段都能够做到这样的隔离。
- 一天无论改了多少次，改了多少个文件都记为“1 次”改变。这样防止了分屡次提交，或者文件数量多寡引起的数据稳定。
极其状况下，咱们能够不分 Git 仓库，或者只有两个 Git 仓库，从而让“接口改变”/“实现改变”比率比拟难看。这个也阐明了分 Git 仓库的老本。把业务逻辑拆得越碎，必然会导致跨团队的沟通会回升。Git 仓库不是分得越多就越好，而是满足了团队的并发数就能够了。
这个指标的另外一个问题是日常性的文案批改会导致实现改变十分多。所以咱们要以“Consistency”维度的指标去均衡。假如咱们曾经有了一种对立的文案配置机制。那么须要有一个“文案配置机制”接入率的指标。这样就能够防止日常性的例行批改毁坏这个指标的真实性。
《A Philosophy of Software Design》很重要的一个观点就是 “Modules should be deep”，这样的隐喻让人们把注意力放在了动态的构造上。其实作者的本意是接口如果比实现要小很多的话，接口被批改绝对于实现被批改的概率也就小了很多。这样咱们大部分时候就能够只改实现，而不改接口。“业务逻辑拆分”其老本和收益都要在接下来做新需要的过程中体现，抽离了业务变更的时间轴，动态的代码构造无奈度量其好坏。
接入率
不认为去辨认“代码反复率”是有意义的指标。代码反复并不一定是问题，很难说明天是一摸一样的代码，今天还会放弃一摸一样。不管三七二十一的“复用”反而可能造成耦合，升高团队自主性（Autonomy）。一个典型的背面案例就是 utils 包，utils 类。没有人说得分明啥时候要用你抽取进去的这个 utils 类，也说不清楚啥时候不应该用。如果要抽出可复用的代码，出发点应该是 consistency，是在团队要害成员达成了统一之后的无意识行为。
每个可复用的 Git 仓库，要定义分明本人的适用范围。在适用范围内须要度量接入率。如果说不清楚啥状况该复用，啥状况不该复用的货色，就应该当成一次性的业务逻辑，不要让其余 Git 仓库对其产生依赖关系。接入率基于代码扫描主动计算，可接入的通过 pattern match 算得，已接入的间接看代码符号的援用关系。
阻断率
当咱们应用了 Java 这样的编程语言的时候，Java 会阻断你在代码中应用汇编语言间接操纵 CPU。这是比拟典型的“阻断”。阻断同样是为了保障一致性。
如果应用了 C++ 这样的编程语言，很有可能 Git 仓库之间对什么是一个 string 都没有共识。这样就必须要在肯定范畴内（比方某个我的项目，某个部门），强制要求所有的 Git 仓库都接入同样的 string 库，从而保障互操作的低摩擦。
相似的，一个彼此相互 RPC 调用的分布式应用，各个过程都用不同的 RPC 协定，用不同的 RPC 实现库来相互通信会导致很多问题。例如，A 调用 B 又调用 C，一旦调用失败，层层加码地去重试，就可能导致最底层模块被重复重试，最终被击垮。解决办法是须要分布式调用链上的所有过程都遵循同样的重试规定。如果没有方法“阻断”手撸 RPC 的实现，看见一个 http url，就间接随便找个 http 规范库去调用，那就很难保障重试规定的一致性。
阻断率指所有可接入的中央，有多少处上了强制查看，确保了违规行为会被阻断。
征询量
当一个定位为“可复用模块”的团队，是孤独寂寞的。如果被拉去参加了某重点项目的 Feature Team，那是莫大的光荣。然而为了保障 Consistency，可复用的 Git 仓库，应该致力升高使用者的老本。使用者的最大老本来自于沟通问询。如果文档不分明，接入开明形式是手工的，必然会体现在征询量上。
征询量这个指标怎么计算就很难说得分明了。在不同的团队里，征询量的体现形式各有不同。总之这个指标就是越靠近零越好。
工单流转时长
企业的内部用户创立的工单，如果最终发现须要开发来处理，到转到对应的开发手里。这个从工单创立工夫，到开发开始处理的时间差，就是工单流转提早。度量这个指标次要是为了防止后盾模块不足对企业最终用户的体验不足同情心，缩小两头的档次。这里工单指的是偶发的个案。对于大面积故障造成的工单，一天之内的工单合并为记录为一条。也就是数据采样的时候，一天只抽取一条工单纳入指标。
故障定位时长
孤立的一个过程很难实现所有工作。业务逻辑不可避免地要拆分成多个过程。如何找到出问题的过程。一个过程也很难仅由一个 Git 仓库构建而来。业务逻辑不可避免地要拆分成多个 Git 仓库。如何找到过程的问题是哪个 Git 仓库造成的。故障定位提早是指故障从开始定位，到找到根本原因所花的工夫。过程边界，Git 仓库的边界，越不依赖人的教训，越不依赖人的现场沟通，就越可能升高故障定位提早。
代码集成时长
从批改一行代码，到把这行代码批改和其余过程集成到一起，用实在流量验证，这个端到端的提早是多少。开发本人的笔记本能把所有的过程都能启动起来是一种方法。开发能用单元测试模仿试也是一种方法。每个小时上一次线也是一种方法。只有能对方才改的那行代码，集成起来不出问题有信念就能够。所以咱们没有把“本地开发环境设置工夫”做为一个指标，因为可能本地启动过程是伎俩，而集成到一起测才是理论目标。
业务逻辑拆分模式
以上是咱们整理出来的可能有用的指标，全文撰写中 taowen/modularization-examples