想问各位一套代码应用到几十个项目该怎么管理

各位程序员朋友，我们团队一直有一个问题，基于项目 A 我们构建了一套平台化代码，项目 A 稳定后平台化代码也趋于稳定直至项目 A 量产。后续又有项目 B/C/D/E/F…，都是基于这套平台化代码，同时由于这些项目上一些新的特性，不断在这套代码上进行扩充。但是原量产项目 A 会定期更新迭代，迭代时怎样才能不引入由于这些新的特性而增加的代码呢？随着量产项目越来越多，如果管控好真的难到我们团队了。如果各个项目分开管理，代码同步上又会比较困难，很难做到真正的平台化。想问一下大家是怎么做管理的呢？我们目前能想到的是为每一个量产项目定版时的软件打上 TAG ，更新迭代如果无必要则拉取对应 TAG 的代码进行编译组版，如果确有更新，则同步修改 TAG 。想请问大家有更好的方式吗？

jsion

2022-01-18 15:52:11 +08:00

最狗屎的问题，我们也有类似的：
A 项目代码，仅供内部使用（实际上也算是客户），beta 和 lastest 标准化的版本均在其发布，项目主体团队自己消化，如果不是公司内部的，找个标杆的客户项目为主干来开发。
B 项目代码，基于 A 的 V1.0.0 版本，因对外客户要求，需要定制开发各类东西，页面样式改版，认证和组织架构变更等等，一般交给交付团队来实现。
C 项目代码，基于 B 的 V1.0.5 版本的某几个阉割后的微服务模块，也是一通改造定制，客户看中了 A 项目的代码，但因为 A 的代码早就不断更迭很多次，要同步上来就得 rebase 整理原来多次变更过的所需模块微服务代码。而前端代码则需要定制化开发，一般交给交付团队来做。
...

过程的东西，如版本发布，需要严格一点的流程管理，每次发布版本都要经过各角色评审，才允许放入制品库，不允许私自定义版本，所有版本需要控制输出。

如果团队人数>10 ，那么就不要一个团队干多个项目的交付实施的活，牵扯过多很容易出问题。分配几个小组（人数>3 ）分别负责不同的项目（ 3<n<5 ），主力核心则至少保证>5 ，因为个项目有些需求必定要核心成员来对交付工作做决策，并不是简单的做出来就不管，另外找外包或者专项招交付岗位的人来负责 1-N 个项目的交付开发工作

如果团队人数<10 ，原则上，每个人承担负责项目不要超过 3 个，不然离职交接和沟通就等着炸吧，项目多就多招人

项目和人多了真就不是技术规范能解决的问题了，必须要考虑流程和推进的工作保障，哪些项目由谁管理，怎么管。可以考虑从如何对人员角色划分和放权管理去下手。

另一条路就是售前和交付团队的有效沟通，让客户自愿吃下这坨，然后还说不出啥，觉得自己就是弱，你们做出来的就是牛皮，需求不满足那是自己还不会用你们的系统，做不到的东西是根本不存在这样的需求。