数据库管理-第176期 浅析代码团队建设（20240425）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Associate: Database（Oracle与MySQL）
PostgreSQL ACE Partner
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家、专家百人团成员，OCM讲师，PolarDB开源社区技术顾问，OceanBase观察团成员
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著 名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

其实本篇的内容，是上次在广州SACC，与崖山团队一朋友线下面基时plus我一个做Linux、K8s的老大哥一起聊天的时候，听我老大哥讲起的，即应该如何合理的去维护一个代码团队，让产品健康的迭代下去。

1 国内现状

下面的一些例子，都是道听途说， 如有雷同，纯属不幸：

• 在与某国产数据库私下沟通的时候，我们很疑惑，为什么产品体系结构会如此复杂，对面大佬一声叹气：因为政治斗争和团队利益。
• 预测某个功能需要投入50W，10个人，经过老板“审核”，只给30W，但是必须配置两个10人团队竞争。
• 在技术主管之上总会找一个不懂技术or不是技术出身的来管理团队，美其名曰把控团队，其实是“外行领导内行”，后面干脆CTO都换成这样的人了。
• 某数据库功能规划，是各个分支团队开会“吵架”争取，然后CTO拍板决定的，最后有一部分功能脱离了实际生产需求。
• 版本迭代，升级过后以前好不容易解决了的BUG顺利“迎回”。
• …

为什么会出现上面这些问题，其实还是代码团队管控和代码项目管理的问题。

2 需求管控

其实很多时候，我们去看某个产品，会发现不少让人“眼前一亮”但又丝毫没有落地可能性的“新功能”，为什么会出现这一现象，我认为，归根结底还是需求来源的问题。需求收集往往都不是根据实际可能面向的生产而来，很多是从“全量”（来源不明）的列表中一拍脑袋决定的。
其实很多时候，数据库并不需要太多“颠覆性”的玩意儿，有些地方连最基础的CRUD和ACID都有些吃力就去卷“高大上”的东西了，是不是算是本末倒置（当然没有亮点就没有机会）。
我认为，就目前的实际发展情况来看，咱们远远没有达到“不止领先，全面超越”，与国际上优秀数据库产品之间还有很大的差距，因此闭门造车是万万不可的，我们还需要去学习别家的先进经验，结合自身特色（发展程度、业务适配、广度深度等）来选择合适的路线发展自己的数据库产品。当然更多的需求是需要去聆听实际客户的心声。

3 竞争与迭代

在一个产品发展中，肯定会存在内部竞争和迭代的现象。就很多场景的竞争来说，简言而之就是在内耗，因为从整体角度来看，就是一场你死我活的斗争，干不过对方就可能面临着失势甚至是失业，这个却是管理者希望看到，他们认为下面人越卷，发展会越好。而在产品迭代之中，也会因为版本间、团队间的很多不良竞争因素，导致一些问题的出现。
这里说一个我看到的一个我认为比较合理的基于版本迭代的团队配置，首先我们需要了解，大多数的产品迭代，不是1.0彻底结束后才做2.0，而是1.0内部发展甚至还没有进入维护周期的时候就会启动2.0相关工作。在这个时候，A、B团队就倾向于各自对应1.0和2.0版本：

• 在各自版本的设计&开发周期内，从整体角度以本版本优先，人员向本团队倾斜，优先解决本的研发需求
• 在版本相对稳定之后开启新版本研发工作，人员逐步向新版本倾斜，而老版本从功能扩展逐渐向稳定维护转变
• 新老版本交替过程中，老版本的创新可以向新版本输出，新版本的增强可以向老版本回迁
• 由于团队间人员存在复用与交替，因此创新下移和功能回迁的难度不会太大
• 版本内不同周期，版本之间也存在一定的竞争关系，也有合作关系

我认为这样的团队假设是相对合理，但是也需要管理者好好理顺发展路线，让所有团队为了相同的目标努力而不是各自为战。

总结

说真的最后我完全不知道写了些啥。