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