讨论:开源项目的 customization

2022-12-25 15:56:03 +08:00
 ericgui

今天想到这个问题:

如果你的公司 /团队需要用到某个开源项目,但这个项目又不是完全契合你们的需求,需要进行一些定制化( customization ),这个时候,就很难搞。

一般有两种选择:

第一种方案是我上一个东家喜欢的方案,结果是几乎所有流行的库,都有一个自己的版本,这简直太扯了

第二种方案,其实也很麻烦,因为有时候你不修改源代码,就很难实现你想要的功能,即便弄出来了,也非常别扭

所以我也不知道到底怎么弄了

各位一般是怎么做的?

1965 次点击
所在节点    程序员
9 条回复
pengtdyd
2022-12-25 16:08:04 +08:00
fork
Biwood
2022-12-25 16:17:16 +08:00
第一种方案相当于完全抛弃了上游仓库的维护和特性更新,除非你们自己的技术实力能跟上游团队相匹配,不然大多还是采用第二种方案。实在有什么功能无法满足的,一是反馈给上游,只是开发周期会比较长,而且对方未必接受,二是自己基于扩展接口来实现,大部分工具都会预留扩展接口,如果没有预留,那说明这个工具本身就不行,可以考虑换一个。不想换的话只能自己重新造轮子,这样的结果是代码会变得臃肿。
Lighfer
2022-12-25 16:26:36 +08:00
我们用的方案 1 ,不过 main 分支是和上游的 main 保持一致,同时内部用另一个分支 A 作为主干,所有对上游的修改,按照功能独立 1~N 个分支,并保留功能分支,main 和上游同步时,所有功能分支的人员负责适配,然后再合并到 AX 。
目前除了版本适配比较耗费精力外,还没有遇到什么问题,当然,也可能是我们没有做非常深度的定制化所以才能得以施行。
charlie21
2022-12-25 16:36:54 +08:00
软件工程里的一个题目就是 “用不修改源代码的方式实现想要的功能” / 如何制作一个可扩展的软件

有时候第三方包只会给你一个闭源的 dll (买来的),连源代码都没有,它被要求呢被整合到一个消费此 dll 的项目里,这时候该怎么办呢?

所谓的 “别扭” 仅仅是一种可以克服的感受,它会被 对于 SOLID 原则这种一般原则的遵守的开心 所替代
crazyweeds
2022-12-25 17:11:24 +08:00
看项目性质。如果这个开源项目类型偏向基础设施,比如 rocketmq ,那么适合包一层。
如果是偏向业务类型的,那么就 fork 直接改。
hahadaxigua834
2022-12-25 17:24:08 +08:00
得根据引用的项目的性质(application/library)来决定。

application 性质的库(如内嵌数据库)使用包装的方式会比较累,有些应用型库暴露的接口很简单,很难做扩展。
library 性质(如解析 yaml)的则相反。

同时也不能完全信赖上游维护者,某些项目出了问题也不修,点名 badger. https://github.com/dgraph-io/badger/issues/1797
Aloento
2022-12-25 17:34:13 +08:00
一般是第一个,但是会频繁同步上游修改
lookStupiToForce
2022-12-26 17:03:07 +08:00
看团队“薪资富余度”——也就是看团队的闲人程度

富余度高,怎么折腾都无所谓,那么一般来说会做更接近底层,更倾向全套自己掌控的活儿,所以会选择方案 1 。
也因为富余度高,所以可劲儿造,必须跟随上游做配套修改,那种运筹帷幄、尽在掌控的爽感也是最好的。

但如果富余度低,项目工期紧,你还有空改底层?有的用不错了,赶紧包一层加些补丁 /外挂 /插件上线吧。
这时候你不会想要上游的修改再跟你有关系的。绝对不会想。最好上游立马去势,此项目成 legacy
netabare
2022-12-27 08:50:00 +08:00
看项目情况、这个类库的复杂度、可修改程度、完善程度和这个项目的期望(?

如果项目本身有一定的「研究或者玩票」性质,不太指望直接写出纯 prod 的产品,同时不保证以后会不会开源代码,这种情况下是尽量优先选用技术成熟、开源协议友好的类库,并且比较倾向于 fork and dev 的。

再比如说如果类库质量并不是很好,可能就有必要去自己做深度开发甚至重写,当然这个成本对于大部分项目想必都不是一件可以考虑的事情。

理想情况下当然是遵循 solid ,自己写一层扩展,但是很多场景下,受到语言、框架、具体的技术栈限制,能找到一两个可用的 lib 已经不容易,lib 也很有可能并不是遵循良好设计的。

显然的,在面向 prod 的项目里面就是另一个故事了。可能在源代码协议方面可以通过闭源(这样不道德但是也没法强求所有人)来绕过,但如果手上没有多少可选的、设计良好的 lib ,那感觉很大程度上还是需要 fork and dev 的…

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

https://www.v2ex.com/t/904585

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

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

© 2021 V2EX