这是一个创建于 1366 天前的主题，其中的信息可能已经有所发展或是发生改变。
各位程序员朋友，我们团队一直有一个问题，基于项目 A 我们构建了一套平台化代码，项目 A 稳定后平台化代码也趋于稳定直至项目 A 量产。后续又有项目 B/C/D/E/F…，都是基于这套平台化代码，同时由于这些项目上一些新的特性，不断在这套代码上进行扩充。但是原量产项目 A 会定期更新迭代，迭代时怎样才能不引入由于这些新的特性而增加的代码呢？随着量产项目越来越多，如果管控好真的难到我们团队了。如果各个项目分开管理，代码同步上又会比较困难，很难做到真正的平台化。想问一下大家是怎么做管理的呢？ 我们目前能想到的是为每一个量产项目定版时的软件打上 TAG ，更新迭代如果无必要则拉取对应 TAG 的代码进行编译组版，如果确有更新，则同步修改 TAG 。想请问大家有更好的方式吗？
 | 1 wudaye 2022-01-14 19:27:39 +08:00 不太懂，说两点废话：1. 拆分代码，模块化 2. 主线分支做好版本管理 |
 | 2 lscho 2022-01-14 19:34:08 +08:00 这不就是微服务干的事吗？ |
 | 3 bigfatDone 2022-01-14 19:37:14 +08:00 前端就直接开发 npm 包，哪个版本有哪些更新，需要哪些功能就拉哪个包就可以了。做好版本管理 |
 | 4 vance123 2022-01-14 19:41:46 +08:00 monorepo |
 | 5 tomczhen 2022-01-14 19:49:01 +08:00 via Android 你以为是一个问题，实际上是一堆问题。 |
 | 6 gengchun 2022-01-14 21:42:48 +08:00 这么玩能不能成功，取决于项目性质。 和流程管理没有太大关系。 真要共享，开发一个框架，框架开发好以后，只做 bugfix ；然后把各项目的功能需求拆开成插件形式。项目的发布当于框架再集成加各种插件。框架和插件的代码统统分开。框架有 bug 所有项目都升级一次框架。 当然，这么玩，没有太多功力，玩不转。 |
 | 7 3dwelcome 2022-01-14 21:48:35 +08:00 via Android 把偏特化需求写成插件的形式。 |
 | 8 mineralsalt 2022-01-14 21:52:09 +08:00 参考 IDEA, 所有额外功能都做成插件 |
 | 9 vanton 2022-01-14 21:57:25 +08:00 按我的经验，基本没法做到。 这是一大堆问题的集合。 |
 | 10 darkengine 2022-01-14 22:00:39 +08:00 “但是原量产项目 A 会定期更新迭代，迭代时怎样才能不引入由于这些新的特性而增加的代码呢？”，如果后续项目 A 的代码有改掉一些共有的 bug ，基于项目 A 平台代码的 B/C/D/E/F 要不要跟进？ 项目 A 应该拆成两个项目，一个是承载业务的项目 A'，一个是平台化的项目（ SDK 项目）。 |
 | 11 xiangyuecn 2022-01-14 22:37:08 +08:00 A：1.0 2.0 3.0 B/C/D 引用的 1.0 E/F/G 引用的 2.0 A 更新：1.0 2.0 3.0 更新成 1.1 2.1 3.1 B/C/D 更新成引用的 1.1 E/F/G 更新成引用的 2.1 分大版本嘛，互不兼容 |
 | 12 zoharSoul 2022-01-14 22:51:52 +08:00  1 我选择跑路 |
 | 13 rekulas 2022-01-15 00:16:41 +08:00 这个就是类似我们以前遇到的问题，最开始也是采用独立版本，但是这样同步修改比较麻烦 所以后面就直接整合在一个版本里了，相当于你每个不同项目就是一个子站，数据库上能直接数据独立就独立实在不能独立就分别存储，程序上根据不同子站实现定制化功能需求，这样做的缺点是前期整合起来很痛苦，耦合性也过高，但优点就是维护方便 我感觉大型公司处理这个问题也是整合到一起的，不然随着版本号的不断累加，拆分后即使是大公司也难以承担越来越高的维护成本 没有优雅的解决方案 |
 | 14 zjsxwc 2022-01-15 08:47:10 +08:00 之前 bilibili 泄漏的 golang 源码就是所有子项目都在一个项目里面 |
 | 15 wuby 2022-01-15 10:11:49 +08:00 之前也遇到类似的问题，但是一直拖着没解决。我个人认为这个跟版本控制有关系，可以参考各个开源社区的方式，设置分支，基库一个分支，其他是各个项目分支的，修改某个项目分支的时候发现这个是通用的就合并到基库。这个工作需要一个人维护分支的。 |
 | 16 iv2ex 2022-01-15 11:48:05 +08:00 以前做 App 遇到过，最开始用一套代码仓库，后面发现随着项目发展，各项目可能出现差异化，耦合太高，B 项目发版本，很难保证Ａ、Ｃ项目不受影响，维护成本极高（要熟悉业务、熟悉代码哪些耦合了）；如果人员变动，这套代码维护起来就没完没了； 后面直接拆分项目，各自一套仓库，随便项目怎么变动迭代，哪个更新测哪个，如果多个更新就复制粘贴。从技术的角度说这种方式很“低级”，从业务的角度来说，出错几率极低，而且不会影响其他项目。 |
 | 17 YYyoung 2022-01-15 12:04:33 +08:00 现在的项目也遇到几乎一样的场景问题。在接手前已经有从，耦合度高的一套代码模式转变为相对解耦的多套代码维护模式。但一直以来也发现有不少问题，如：过多的复制粘贴，很多时候还会漏，维护起来很麻烦，大家都对修复一个问题或者加一个通用的功能要去多个版本中去改动代码感觉比较繁琐，所以近期又在打算重构为使用一套代码的模式。考虑使用插件化的方式进行，但是估计后续还是会有一些问题，但至少能解决当前的一些项目痛点吧。就是不断折腾。 |
 | 18 jones2000 2022-01-15 12:46:22 +08:00 基础库+丰富的扩展接口就可以了呀。 每个项目特性的东西都通过扩展接口定制修改， 不需要修改底层基础库。 公共通用的东西就修改底层的基础库。 |
 | 19 ligiggy 2022-01-15 15:22:07 +08:00 Any problem in computer science can be solved by another layer of indiretion. 计算机科学领域的任何问题都可以通过添加一个间接的中间层来解决。 |
 | 20 FACEB00K 2022-01-15 17:07:58 +08:00 同一套代码，最后项目之间的依赖太复杂了 |
 | 22 yurong333333 2022-01-15 17:48:30 +08:00 和我司差不多。真的无语。这是一大堆问题的集合，不一定是技术问题。 |
 | 23 einq7 2022-01-15 18:22:33 +08:00 git subModule 不香吗 |
 | 24 qza1212 2022-01-15 21:10:34 +08:00 1.单代码库 monorepo ，对程序员要求高，任一 lib 项目 merge 都必然影响其他项目 2.多代码库做 stable 分支依赖，需要自己管理依赖以及反向构建来保证 stable 分支可用 不建议 tag 依赖 |
 | 25 ychost 2022-01-16 11:35:29 +08:00 考验抽象能力了，api 层尽可能的轻量化，实现都是各个 Plugin ，Java 的话可以参考 SF4j |
 | 26 SmiteChow 2022-01-17 10:01:36 +08:00 搜索 sass |
 | 27 jsion 2022-01-18 15:07:13 +08:00 最狗屎的问题， |
| 28 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 个，不然离职交接和沟通就等着炸吧，项目多就多招人 项目和人多了真就不是技术规范能解决的问题了，必须要考虑流程和推进的工作保障，哪些项目由谁管理，怎么管。可以考虑从如何对人员角色划分和放权管理去下手。 另一条路就是售前和交付团队的有效沟通，让客户自愿吃下这坨，然后还说不出啥，觉得自己就是弱，你们做出来的就是牛皮，需求不满足那是自己还不会用你们的系统，做不到的东西是根本不存在这样的需求。 |
Select Language