第15章 软件架构要引入控制吗

软件架构向软件项目引入结构和远见，是否也引入了控制？如果答案是肯定的，那控制是好还是坏？

提供指导，追求一致性

很多软件架构的实践都会向软件项目引入指导和一致性。如果你见过一个软件系统内的常见问题或横切关注点有多种实现方式，就会明白为什么这很重要。我想起不少案例。我见过一个代码库里用到了好多个ORM框架，还有的软件系统有好几种跨栈的组建配置方式，有用XML文件的，也有用数据库表的。部署和维护这些系统太有挑战性了。

只有引入一定程度的控制和约束，比如，阻止团队成员偏离正轨，指导和一致性才可能成为现实。如果你为了满足一些主要的非功能性需求，专门设计了一个分布式软件系统，就不能让人把数据库操作的代码写在网页中。控制也可以只是保证你的代码库有一个清晰一致的结构，以包、命名空间、组件、层等形式合理地组织你的代码。

控制的程度

真正的问题是需要引入的控制量。一种方法是独裁，任何人都不能擅自做决策；另一种方法是放手，没有人会得到任何指导。在软件项目中，这两种我都见过。我也接手过混乱的项目，每个人基本上都只管自己的设备。毫不意外，最后的代码库简直一团糟。在这样的项目中引入控制真是艰苦的工作，如果这个团队还打算交付一份令最初推动者满意的软件，就需要控制。

控制因文化而不同

我也注意到，不同国家和文化对控制的看法也不尽相同。有些国家（比如英国）就认同控制以及它带来的约束，而另一些（比如斯堪的纳维亚地区的国家）则偏向授权和主动性。举个现实中的例子，就是完全控制软件项目使用的全部技术（从编程语言到登录库的选择），还是接受团队里任何人做的决策。

操纵杆，而非按钮

我喜欢把控制看作操纵杆，而不是某些非黑即白、只有两种状态的东西。一端是由你独裁的方法，另一端则宽松得多。两者之间你可调整，这让你能够在需要时引入足够的控制。那么，你要引入多少控制？我得承认，我只能给出一个咨询式的回答，在不清楚的情况下，这取决于以下这些事。

❑ 团队是否经验丰富？

❑ 团队以前一起工作过吗？

❑ 团队有多大？

❑ 项目有多大？

❑ 项目的需求复杂吗？

❑ 有没有需要考虑的复杂的非功能需求或限制？

❑ 日常的讨论是什么样的？

❑ 团队或已有的代码库是否看起来已经混乱不堪？

❑ 等等。

我的建议是，先从部分控制开始，倾听反馈，以便随着项目的推进再微调。如果团队老是问“为什么”和“怎么办”，那可能就需要更多指导。如果团队好像总是在和你对着干，可能你就是把操纵杆推得太多了。这没有一个标准的答案，但有一些控制是好事，因此很值得花几分钟看看你的团队适合引入多少控制。