为架构填坑的正确姿势

看看下面的问题是否经常出现在你的团队中：

1，项目中经常出现循环依赖的问题

2，开发者日常开发出现问题，总是被管教

3，项目架构实际情况和目标差距只能靠拍着脑袋说百分比。

4，作为架构师除了开会沟通、画架构图、了解业务，不清楚还做些什么

如果你也遇到上述问题并寻找解决方法，这篇文章或许适合你。解决上面的问题可以使用“适应度函数”。

什么是适应度函数 ？

简单来讲一个适应度函数就是度量某个目标的函数。下面是一个简单的适应度函数：

function plus(a, b) {
	return a + b;
}

一个函数有入参有结果，同样自适应函数的同样有入参和结果。

适应度函数同样也是个函数，只是形式和 Javascript 代码中的函数格式不同。下面是一些例子比如：

一个适应度函数叫测试覆盖率，那么该函数入参是业务代码，结果是测试覆盖率。
一个适应度函数叫循环依赖检测，那么该函数的入参是某个 package 下的类，结果是该 package 下是否有循环依赖。
一个适应度函数叫集成是否成功，那么入参是最近提交的代码，内部运行单元测试，结果集成成功或者集成失败。

在之前的文章中我们介绍过 PMD、CheckStyle、ArchUnit 等工具，通过这些工具的语法就能够定义一些适应度函数。例如 用 ArchUnit 来完成一个循环依赖的检测的测试，就是为工程添加了一个循环检测的适应度函数。并在运行测试的时候，能够得到结果包含循环依赖 or 不包含循环依赖。

如何使用适应度函数 ？

在架构设计时了解功能、非功能性需求后就定义适应度函数，例如：测试覆盖率，系统每秒处理的事务数。并在项目变化环节、搭建 pipeline 是去实现这些适应度函数。

适应度函数可以出现在项目代码中，可以出现在pipeline中、性能测试中。

所以适应度函数并不是一个函数，而是根据目标定义出来的验证这些目标客观装填的一个或者多个函数。

如何实现一个适应度函数，请参考 ArchUnit 中介绍的一些测试。通过这些测试即可建立约束。

那我们看看适应度函数怎么解决问题的：

####（1）“项目中经常出现循环依赖的问题”怎么解决？

架构师首先定义循环依赖的适应度函数，然后在项目代码中实现该循环依赖的适应度函数，使其起到约束作用。在后续代码中如果破坏了规则，在执行代码测试环节就可以发现问题。

适应度函数能做的就是将项目实际情况可变展示出来，尽早把问题暴露出来，促使根据错误信息进行修复的。添加了几行测试代码，后续代码中出现循环依赖，不用完全运行代码就能发现问题。

如果出现了其他问题，同时发现也没有适应度函数怎么办？先添加适应度函数，将规则建立起来，不要把适应度函数当做次要事情来处理，因为它可以建立一张安全网。以此来保护架构。

####（2）细心的朋友或许对“开发者日常开发出现问题，总是被管教”已经有了答案。

还是上面循环依赖的问题，如果没有适应度函数守护架构，当团队多次出现循环依赖，很多人管不住自己的脾气，开始声音变大，态度变差，管教频繁犯错的同事。

换一种思路，发现问题后，第一时间添加适应度函数，并帮助同事学习如何根据错误定位问题。队友不但提升了自己的能力，后续再发现问题也能自己解决，这个团队不用为这种频繁易错的地方而重复花费时间。

我们经常看到：“懒”能驱动着很多问题找到更好的解决办法。

这里的“懒”指的是创建可复用的工具，减少自己重复，而不是真的懒。管教别人往往起不到未来“懒”的效果，解决问题并传递知识才是一个更好的选择。

（3）对“项目架构实际情况和目标差距只能靠拍着脑袋说百分比”也有了答案。

适应度函数结果是成功 or 失败，或者一个具体的值。而不同纬度的适应度函数能够让我们更了解自己创建的程序。例如：测试覆盖率、每秒处理事务的数量、并发量、是否测试通过等。

架构师在做架构时应该先定义适应度函数，这样开发团队才能在测试、代码建立起来的约束下朝着架构的目标前进。当项目进行的时候，我们拿到适应度函数产生的结果，就能根据实际情况作出下一步决定。

例如前年一个创业团队在做东南亚市场，开始的测试测试覆盖率只有15%，保证部分质量的同时去市场验证产品。当市场认可产品后，产品、团队规模变得更大，需要保证产品质量，从而守住市场，可以逐渐添加测试覆盖率的阀值30%，60%。

日程工作中适应度函数也是我们工作的一部分，缺少了它们似乎都是拍着脑袋说主观感受，但是有了它们也就知道了客观的情况，从而可以将精力专注于业务。不用担心做到一半发现架构有问题。

（4）“作为架构师除了开会沟通、画架构图、了解业务，不清楚还做些什么”

架构师能做的事情很多，了解业务上的问题是必要的，否则业务和技术就脱节了，技术也就无法响应业务需求了。

架构师可以根据了解的业务上的功能需求和非功能性需求，设计软件架构，然后定义适应度函数，并合理使用耦合来得到价值最大化。

架构设计时可以使用 1 至 3 级的架构图，架构图上添加技术选型。然后根据功能、非功能性需求来定义适应度函数，开发过程中实现并完善适应度函数（将适应度函数放在工程中、CI/CD、各类测试中），并得到真实的数据反馈，根据反馈做出具体调整，实现增量更新。

总结：

细心的同学已经发现了，适应度函数、增量更新、适当的耦合都是演进式架构的构件。感兴趣的同学可以在详细的了解演进式架构的具体内容，也可以赶紧行动起来，尝试添加适应度函数到项目中，并从盲目变得基于客观实施来做决策。

在之前的创业经历中，我也为什么时候引入新事物而思考过，但是当时没有任何依据，担心当前团队有问题的前提下，引入新技术后团队效率会降低，事实上我的做法错了。引入一部分新技术后，虽然短暂的一段时间效率可能会降低，但是紧接着这一部分就由不可控成为可控，从而有精力再去改进了其他地方，这也体现了团队的实际效率，只开发而不关注质量就导致了“演示必败”，而且浪费每一次产品出现在消费者眼前的机会（因为总是出问题，被打上了质量差的标签）。