这是一个创建于 1051 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天想到这个问题：
如果你的公司 /团队需要用到某个开源项目，但这个项目又不是完全契合你们的需求，需要进行一些定制化（ customization ），这个时候，就很难搞。
一般有两种选择：
- fork 一个自己的版本，修改之后，使用
- 不维护一个自己的版本，但在这个库上面包一层
第一种方案是我上一个东家喜欢的方案，结果是几乎所有流行的库，都有一个自己的版本，这简直太扯了
第二种方案，其实也很麻烦，因为有时候你不修改源代码，就很难实现你想要的功能，即便弄出来了，也非常别扭
所以我也不知道到底怎么弄了
各位一般是怎么做的？
 | 1 pengtdyd 2022-12-25 16:08:04 +08:00 fork |
 | 2 Biwood 2022-12-25 16:17:16 +08:00 via Android 第一种方案相当于完全抛弃了上游仓库的维护和特性更新，除非你们自己的技术实力能跟上游团队相匹配，不然大多还是采用第二种方案。实在有什么功能无法满足的，一是反馈给上游，只是开发周期会比较长，而且对方未必接受，二是自己基于扩展接口来实现，大部分工具都会预留扩展接口，如果没有预留，那说明这个工具本身就不行，可以考虑换一个。不想换的话只能自己重新造轮子，这样的结果是代码会变得臃肿。 |
 | 3 Lighfer 2022-12-25 16:26:36 +08:00 我们用的方案 1 ，不过 main 分支是和上游的 main 保持一致，同时内部用另一个分支 A 作为主干，所有对上游的修改，按照功能独立 1~N 个分支，并保留功能分支，main 和上游同步时，所有功能分支的人员负责适配，然后再合并到 AX 。 目前除了版本适配比较耗费精力外，还没有遇到什么问题，当然，也可能是我们没有做非常深度的定制化所以才能得以施行。 |
 | 4 charlie21 2022-12-25 16:36:54 +08:00 软件工程里的一个题目就是 “用不修改源代码的方式实现想要的功能” / 如何制作一个可扩展的软件 有时候第三方包只会给你一个闭源的 dll （买来的），连源代码都没有，它被要求呢被整合到一个消费此 dll 的项目里，这时候该怎么办呢？ 所谓的 “别扭” 仅仅是一种可以克服的感受，它会被 对于 SOLID 原则这种一般原则的遵守的开心 所替代 |
 | 5 crazyweeds 2022-12-25 17:11:24 +08:00 看项目性质。如果这个开源项目类型偏向基础设施，比如 rocketmq ，那么适合包一层。 如果是偏向业务类型的，那么就 fork 直接改。 |
 | 6 hahadaxigua834 2022-12-25 17:24:08 +08:00 得根据引用的项目的性质(application/library)来决定。 application 性质的库(如内嵌数据库)使用包装的方式会比较累，有些应用型库暴露的接口很简单，很难做扩展。 library 性质(如解析 yaml)的则相反。 同时也不能完全信上游维护者，某些项目出了问题也不修，点名 badger. https://github.com/dgraph-io/badger/issues/1797 |
 | 7 Aloento 2022-12-25 17:34:13 +08:00 via Android 一般是第一个，但是会频繁同步上游修改 |
 | 8 lookStupiToForce 2022-12-26 17:03:07 +08:00 看团队“薪资富余度”也就是看团队的闲人程度 富余度高，怎么折腾都无所谓，那么一般来说会做更接近底层，更倾向全套自己掌控的活儿，所以会选择方案 1 。 也因为富余度高，所以可劲儿造，必须跟随上游做配套修改，那种运筹帷幄、尽在掌控的爽感也是最好的。 但如果富余度低，项目工期紧，你还有空改底层？有的用不错了，赶紧包一层加些补丁 /外挂 /插件上线吧。 这时候你不会想要上游的修改再跟你有关系的。绝对不会想。最好上游立马去势，此项目成 legacy |
 | 9 netabare 2022-12-27 08:50:00 +08:00 via Android  1 看项目情况、这个类库的复杂度、可修改程度、完善程度和这个项目的期望（？ 如果项目本身有一定的「研究或者玩票」性质，不太指望直接写出纯 prod 的产品，同时不保证以后会不会开源代码，这种情况下是尽量优先选用技术成熟、开源协议友好的类库，并且比较倾向于 fork and dev 的。 再比如说如果类库质量并不是很好，可能就有必要去自己做深度开发甚至重写，当然这个成本对于大部分项目想必都不是一件可以考虑的事情。 理想情况下当然是遵循 solid ，自己写一层扩展，但是很多场景下，受到语言、框架、具体的技术栈限制，能找到一两个可用的 lib 已经不容易，lib 也很有可能并不是遵循良好设计的。 显然的，在面向 prod 的项目里面就是另一个故事了。可能在源代码协议方面可以通过闭源（这样不道德但是也没法强求所有人）来绕过，但如果手上没有多少可选的、设计良好的 lib ，那感觉很大程度上还是需要 fork and dev 的… |
Select Language