开源代码的使用二次开发

开源开发&＃xff0c;就我的理解&＃xff0c;有三种。

1、当作底层基础&＃xff0c;使用。例如大家使用mysql就算。有人会认为我说错了。但我认为&＃xff0c;开发不代表就是要同一个语言&＃xff0c;甚至修改代码。例如我们使用动态库&＃xff0c;原先的动态库是什么写的并不重要。重要的是作为自己的组成部分。你即便用mysql的接口甚至命令&＃xff0c;去实现系统&＃xff0c;也算是二次开发。

2、作为参考设计&＃xff0c;这通常是在针对标准的实现上。这类代码&＃xff0c;本身最大的价值是作为一个对比版本&＃xff0c;检验自身的代码的正确性使用。如果都打算推倒重写了&＃xff0c;要么原先代码很烂无法实用化&＃xff0c;要么你的目标任务更明确&＃xff0c;针对特定任务类型&＃xff0c;你有更好的求解方式。

3、作为整体&＃xff0c;局部修改&＃xff0c;或引出新的分支。这类情况前者很常见&＃xff0c;后者不常见。但通常更有意义的在于你的修改能符合规范并且纳入版本中&＃xff0c;因为一旦开源代码的版本调整&＃xff0c;而你只是修改而自行发布&＃xff0c;这产生了统一和分裂的矛盾。主要功能希望统一&＃xff0c;但代码实现存在分裂。

针对上述三种不同的情况&＃xff0c;对代码的使用和学习分以下几种方式&＃xff1a;

1、代码不看&＃xff0c;或最多在实际应用中去局部理解&＃xff0c;主要是为了更好的了解开源的底层是规模和情况&＃xff0c;便于你的系统确定目标范围。

2、代码需要看&＃xff0c;但以理解为主&＃xff0c;主要是针对函数的目标进行理解&＃xff0c;而不是针对函数内部实现进行理解。

3、这个比较痛苦&＃xff0c;需要对函数内的代码进行理解&＃xff0c;特别是跨模块&＃xff08;C文件作用域&＃xff09;的变量&＃xff0c;函数的理解。

你要先搞清楚&＃xff0c;你打算干什么才能针对目标进行不同模式的开源处理。

以上三种方式我都折腾过。但方法还是不太一样。

对于第一种方式我就不说了&＃xff0c;很简单你去用就行了。如同你怎么学mysql就怎么来。下面说下后面两种方法的不同。

举例&＃xff1a;

重写代码。我折腾过两套系统&＃xff08;都是好几年前的故事&＃xff09;&＃xff0c;1套是JM系列和X264系列&＃xff0c;针对H264标准&＃xff0c;而出的代码&＃xff0c;前者不算真正开源&＃xff0c;后者算。另一套&＃xff0c;是国家标准AVS&＃xff0c;有个类JM的代码。曾经骂JM的代码有多烂&＃xff0c;看了国家标准AVS的参考代码&＃xff0c;才知道什么叫学生水平&＃xff08;我甚至怀疑就是国内的普通没有代码设计能力的非专业程序员级别的研究生写的&＃xff09;

这类开源的代码理解&＃xff0c;是通过输入输出数据&＃xff0c;在运行态下&＃xff0c;分析代码。

另一类&＃xff0c;是我目前在做的&＃xff0c;对GIT的代码的二次开发。但是这类&＃xff0c;我暂且不会考虑对GIT的后续版本的统一问题。因为我的目标是多文件&＃xff0c;多用户权限的分布式版本管理系统的开发&＃xff0c;而GIT对多权限貌似支持并不好。所以我也无法统一&＃xff0c;这是没有办法的办法。对这类的二次开发&＃xff0c;确实比较痛苦&＃xff0c;主要是针对独立的行为的一一理解和分析 。

对代码的理解&＃xff0c;也是反复调整局部变量或结构&＃xff0c;以判断实际效果的方式来处理。理解代码后&＃xff0c;后续的工作是&＃xff0c;逐步替换内部模块&＃xff0c;或者改变内部模块的调用逻辑&＃xff0c;来实现新的功能。

特别针对第三种的开发&＃xff0c;个人建议不要重新列个工程&＃xff0c;对已经识别和分析清楚的模块整体转入到新的工程中去。用我平时说的非常多的一句来形容&＃xff0c;也就是说&＃xff1a;

”不要尝试用理想改变现实&＃xff0c;尽可能的通过现实实现理想“