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

2022-01-14 19:06:01 +08:00
 FranzKafka95

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

4991 次点击
所在节点    程序员
28 条回复
wudaye
2022-01-14 19:27:39 +08:00
不太懂，说两点废话：1. 拆分代码，模块化 2. 主线分支做好版本管理
lscho
2022-01-14 19:34:08 +08:00
这不就是微服务干的事吗？
bigfatDone
2022-01-14 19:37:14 +08:00
前端就直接开发 npm 包，哪个版本有哪些更新，需要哪些功能就拉哪个包就可以了。做好版本管理
vance123
2022-01-14 19:41:46 +08:00
monorepo
tomczhen
2022-01-14 19:49:01 +08:00
你以为是一个问题，实际上是一堆问题。
gengchun
2022-01-14 21:42:48 +08:00
这么玩能不能成功，取决于项目性质。

和流程管理没有太大关系。

真要共享，开发一个框架，框架开发好以后，只做 bugfix ；然后把各项目的功能需求拆开成插件形式。项目的发布当于框架再集成加各种插件。框架和插件的代码统统分开。框架有 bug 所有项目都升级一次框架。

当然，这么玩，没有太多功力，玩不转。
3dwelcome
2022-01-14 21:48:35 +08:00
把偏特化需求写成插件的形式。
mineralsalt
2022-01-14 21:52:09 +08:00
参考 IDEA, 所有额外功能都做成插件
vanton
2022-01-14 21:57:25 +08:00
按我的经验，基本没法做到。

这是一大堆问题的集合。
darkengine
2022-01-14 22:00:39 +08:00
“但是原量产项目 A 会定期更新迭代，迭代时怎样才能不引入由于这些新的特性而增加的代码呢？”，如果后续项目 A 的代码有改掉一些共有的 bug ，基于项目 A 平台代码的 B/C/D/E/F 要不要跟进？

项目 A 应该拆成两个项目，一个是承载业务的项目 A'，一个是平台化的项目（ SDK 项目）。
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

分大版本嘛，互不兼容🐶
zoharSoul
2022-01-14 22:51:52 +08:00
我选择跑路
rekulas
2022-01-15 00:16:41 +08:00
这个就是类似我们以前遇到的问题，最开始也是采用独立版本，但是这样同步修改比较麻烦
所以后面就直接整合在一个版本里了，相当于你每个不同项目就是一个子站，数据库上能直接数据独立就独立实在不能独立就分别存储，程序上根据不同子站实现定制化功能需求，这样做的缺点是前期整合起来很痛苦，耦合性也过高，但优点就是维护方便
我感觉大型公司处理这个问题也是整合到一起的，不然随着版本号的不断累加，拆分后即使是大公司也难以承担越来越高的维护成本
没有优雅的解决方案
zjsxwc
2022-01-15 08:47:10 +08:00
之前 bilibili 泄漏的 golang 源码就是所有子项目都在一个项目里面
wuby
2022-01-15 10:11:49 +08:00
之前也遇到类似的问题，但是一直拖着没解决。我个人认为这个跟版本控制有关系，可以参考各个开源社区的方式，设置分支，基库一个分支，其他是各个项目分支的，修改某个项目分支的时候发现这个是通用的就合并到基库。这个工作需要一个人维护分支的。
iv2ex
2022-01-15 11:48:05 +08:00
以前做 App 遇到过，最开始用一套代码仓库，后面发现随着项目发展，各项目可能出现差异化，耦合太高，B 项目发版本，很难保证Ａ、Ｃ项目不受影响，维护成本极高（要熟悉业务、熟悉代码哪些耦合了）；如果人员变动，这套代码维护起来就没完没了；

后面直接拆分项目，各自一套仓库，随便项目怎么变动迭代，哪个更新测哪个，如果多个更新就复制粘贴。从技术的角度说这种方式很“低级”，从业务的角度来说，出错几率极低，而且不会影响其他项目。
YYyoung
2022-01-15 12:04:33 +08:00
现在的项目也遇到几乎一样的场景问题。在接手前已经有从，耦合度高的一套代码模式转变为相对解耦的多套代码维护模式。但一直以来也发现有不少问题，如：过多的复制粘贴，很多时候还会漏，维护起来很麻烦，大家都对修复一个问题或者加一个通用的功能要去多个版本中去改动代码感觉比较繁琐，所以近期又在打算重构为使用一套代码的模式。考虑使用插件化的方式进行，但是估计后续还是会有一些问题，但至少能解决当前的一些项目痛点吧。就是不断折腾。
jones2000
2022-01-15 12:46:22 +08:00
基础库+丰富的扩展接口就可以了呀。 每个项目特性的东西都通过扩展接口定制修改， 不需要修改底层基础库。 公共通用的东西就修改底层的基础库。
ligiggy
2022-01-15 15:22:07 +08:00
Any problem in computer science can be solved by another layer of indiretion.

计算机科学领域的任何问题都可以通过添加一个间接的中间层来解决。
FACEB00K
2022-01-15 17:07:58 +08:00
同一套代码，最后项目之间的依赖太复杂了

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/828310

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX