经常听到有人说，数据库很重要，所以应该有一个经验丰富的团队来把关。架构很重要，所以应该由一些架构师来统筹。
先不说这些高级团队到底能做到多大改善。但这种组织架构会带来致命的问题——组织的开发速度上限受限于这些高级团队，甚至是效率最低的那个。
如图，首先问题是，这些团队会在整个开发流程中成为瓶颈，我们无法通过横向扩展团队来提升组织的开发速度。这对软件产生价值的组织来说是致命的。
第二个问题是，开发中的沟通成本大量增加，团队间的沟通成本会远远大于团队内的沟通成本。如果功能开发团队依赖于大量其他团队，就会使整个开发成本变高，价值流速度降低。
第三个问题是，核心团队成员需要长时间培养，人员流动往往会造成致命的打击，就好像组织中有一根软肋，如果竞争花钱把某一个核心团队成员全部挖走，该组织可能会立刻消失。
由此可见，为了保持某些看起来很重要的东西（比如数据库，架构）运行良好，就让专业团队去做的想法有很多致命问题。
那怎么样才是好的实践呢？
特性团队 + 微服务
团队自己负责所有事务，从一开始就避免大型数据库和大型架构的设计，每个功能根据自己的需求，完成相应的服务设计、开发、测试、部署和上线。如果需要修改其他服务，也由该团队自己完成。通过自动化测试去保障质量，而不是由某个高级团队。
如果遇到遗留系统怎么办？
因为遗留系统可能没有足够的自动化测试去保障质量，所以首选的一定不是去修改它。把遗留系统API化，给遗留系统补测试，把一部分功能拆出来另外实现，都是我们常用的方法。
当然，我们还是避免不了去修改它，这种时候，修改还是由团队自己来完成，因为没有人能代替你去理解业务，没有人能代替你提供实现方案。只是团队需要自己足够谨慎，通过增加对遗留系统的了解以及找曾经在系统上工作过的人沟通，从而具备修改它的能力。
总之，指望把当前团队解决不了的问题扔给另一个团队去解决是不靠谱的，我们应该提升团队能力，使该团队具备解决问题的能力，而不是把希望寄托在别的团队上。
No comments:
Post a Comment