原文链接: 团队解耦-应当大型软件复杂度的方法
本文是廖雪峰老师博客学习笔记, 老师博客原文: 团队解耦-解决软件工程的最大难题
解决开发大型软件复杂度的问题, 这篇文章给出了一个很好的思路. 其中团队解耦, 以及关于架构师保证代码和团队可以正确解耦的职责描述, .让人耳目一新, 另外 本篇文章记录下学习心得.
更多的新成员其实会降低其他人的生产率,一个普遍现象是团队规模越大,每个人的平均生产率越低。
大项目的开发效率不高,把这个问题归咎于程序员的技术水平低和管理不善,都是没用的。 根本原因是软件规模的增长,必然使得代码和团队变得笨重。
解决这个问题,要从代码和团队两方面着手。
代码解耦
代码层面的解决方法是,将软件解耦,拆分成组件或者模块,防止各个部分紧密地耦合在一起。每个组件和模块,都可以独立开发,通过公开的接口被其它部分调用。
这样的话,就大大减轻了开发者的负担,只需要负责自己的代码即可,不需要关心其他部分的实现。每个部分都可以单独重构,不担心影响到其他部分。
团队解耦
除了代码解耦,团队层面也需要解耦,要把人员分开。
这可以参考互联网的架构。互联网是迄今为止最成功的大型软件解耦实例,它之所以能够扩展,是因为它由一个个独立的节点组成。为了防止节点之间互相依赖,各个节点都遵循以下规则:
- 遵守公开的通信协议。
- 不需要了解其它节点的内部实现,就可以与之通信。
- 节点之间不直接共享状态,只通过通信交换数据。
- 每个节点单独开发和部署。
大团队也应该参照类似的规则进行解耦:
- 每个子团队都可以独立运作,不依赖外部人员。
- 子团队内部的运作,不需要被外部知道。
- 子团队之间的协调,应该按照公开的协议和规则,最好能够自动完成,避免私下协商。
团队解耦的注意点
- 子团队的人数不宜过多,每个子团队最好不要超过5个人。
- 子团队应该是一个小型的全功能软件开发组织。
很多大团队按照人员角色分组,比如架构组、开发组、DBA 组、测试组、工程组等等,这是错误的。这样完全没有解耦,还是瀑布式流程,各组之间依然互相依赖,工作时必须与别组单独协商。而且,可能会产生利益冲突,比如,开发组希望尽快交付,而测试组希望多一点时间测试。
**正确做法是按照软件的业务功能分组,每组负责一个全流程的软件大功能,设计、编码、测试、部署、支持等人员都在同一组。**这样才能做到解耦,以及独立的交付和重构。每组内部使用什么工具、如何实现某个功能,都是自己决定,各组之间不需要共享内部细节,也不依赖别组的工作。
- 大团队应该保障子团队的自主权,按照子团队提供的功能和商业价值,进行资源分配。
- 软件架构师的角色很重要。
软件架构师的关注点,不应该是团队使用的工具和技术,而是各种服务与整个系统运行状况之间的协议和通信,保证代码和团队可以正确解耦。
- 代码解耦和团队解耦的关系。
理想情况下,代码解耦与团队解耦保持一致,形成一对一的关系,一个子团队负责一个独立的模块。实际运作中,一个子团队负责几个模块也可以,但是一个模块不能由多个子团队来参与。
- 通信(模块之间的、子团队之间的)尽量规范化,争取做到过程简单、文档充分,最好有规范的 API,这样无需任何人员交流,就能建立通信。