对开源项目的一些见解

经验分享 · Fecmall · 于 5年前 发布 · 1989 次阅读

1.关于开源项目

开源项目是一个相对完整的工程体系,是开发者从对领域内的某个架构设计有自己独特的看法,或者 解决某些问题,而做的项目,遵循一定的开源协议,将源代码开放到github或者其他的 一些代码托管的平台,在方便自己使用的过程中,顺便帮助其他更多的人,因此,为了达到这个目的, 开源项目除了自己的功能解决业务问题除外,还需要具备一下内容

1.1源代码:将代码100%的开放出来

1.2文档:包括安装文档,二次开发文档,帮助文档,帮助视频等等,让其他人可以通过文档 了解项目本身,因此文档要细致,条理,把需要说清楚的内容说清楚,讲明白。

1.3论坛社区:给开发使用者提供交流的平台,方便交流意见,可以使用github的issue,或者 自己搭建论坛。

1.4架构上允许扩展:在系统架构方面,要考虑其他人开发插件扩展,theme等独立包, 可以独立的对接到系统中

1.5使用的二次开发者可以持续的升级

1.6吸引更多的参与者:有更多的人参与,开源项目才能更茁壮的成长

2.为什么做开源项目

2.1积累自己的技术经验:开发者在某个领域中工作多年,在实战中对自己参与的系统或者 其他项目组的系统,以及业务运营等会有很多自己的看法和想法,而工作当中又没有条件 让自己去按照自己的想法做,而且自己的想法也有不周全的地方,需要来回打磨。

2.2在开源项目成型后,会吸引一部分开发者提意见和想法,可以吸取过来沉淀到开源项目中, 自己的视野也会随之开阔

2.3成就感:当开发者使用自己的开源系统做项目,随之而来的也有成就感,可以在全球最大同性交友github平台上,博得更多的同性友谊

3.如果想要开源项目参与者更多,不要做哪些开源:

3.1复杂的大型框架,例如UI框架,短期内做不完,使用成本高。

3.2模拟成熟的轮子,例如再造一个Jquery,业内已有成熟方案,用户不会替换。

3.3小众的东西,基本没人用

3.4没有特色,100%模仿,用户没有理由更换。

4.开源项目历程

4.1刚开始只有一个小的idea,发现工作中的一些系统的弊病,但是又没有成熟的解决方案,或者发现想要某个功能,而找不到相应的产品来解决,这个时候就可以自己写一个开源项目, 技术是为业务服务(站在技术应用的角度),因此要有一定的实际用处,有区别于目前的一些开源产品独特的地方。

4.2写雏形,功能很多,只能一快一块的写,写完后,在从其他的角度审视自己的框架结构,是否在其他的方面不满足要求,重新设计代码文件结构

4.3一步一步的成型,在技术群里面发出来给大家看,以及自己的一些难题在技术群里面讨论。

4.4前期野蛮,后期打磨。 在项目前期尽量的以功能实现为主,解决问题为主,后期细致的打磨代码格式以及注释规范(注释前期也要写)

4.5文档,代码注释,要随着代码的开发一起进行,否则,后面将会忘记以前写的代码的实现步骤,又得花时间回头看自己的代码

4.6善始善终,热爱编码,淡然看世界,有始有终。

由于开源项目不是公司线上运行的产品,因此,有了新的想法就可以尝试,即使失败也不会有大的问题,当系统发布后,有很多人使用系统, 帮助别人的同时,大家也免费测试系统的bug。

5.关于php开源项目架构的个人思路

5.1代码存放到github

5.2可以基于一个成熟的php开源框架,目前比较成熟稳定的是laravel和yii2,都很优秀,功能都很强,像比较而言,laravel的生态繁荣,yii2更加的简洁,底层代码易读性更好,代码结构比较的扁平化,laravel的代码结构封装的比较深(多少有点magento的一丝感觉), 如果开源项目需要更改重写一些框架本身的底层功能,譬如重写request,response,url初始化等,个人比较倾向于yii2框架,重写框架底层更轻松

5.3打包的方式发布代码,有利于升级,可以基于composer,使用 https://packagist.org/ 管理包, 安装后,库包文件安装在vendor下面,系统安装基于composer在线安装

5.4如果项目使用了很多软件,譬如除了mysql,还使用了redis,mongodb,elasticSearch等,可以做docker做环境部署,通过容器技术快速部署环境,方便上手

5.5解决冲突:

5.5.1冲突者:开源项目开发组,N个插件扩展开发者,本地二次开发者。三者之间的 代码文件冲突,

5.5.2解决系统升级以及插件扩展升级的矛盾冲突,因此在架构方面,各个开发者在自己的库包中编写代码,需要通过配置重写的方式进行功能重写,,而不能改动其他库包的文件

5.5.3因此在配置优先级上,扩展包开发者可以通过配置覆盖的方式重写开源项目的功能, 本地开发者可以通过配置覆盖的方式重写开源项目和第三方插件的功能

总之,系统库包以composer库包的方式发布,二次开发者可以通过composer update升级系统文件,更改系统功能可以通过 配置文件重写的方式完成功能更改。

5.6约定优于配置 约定优于配置(convention over configuration),也称作按约定编程,是一种软件设计范式,旨在减少软件开发人员需做决定的数量,获得简单的好处,而又不失灵活性。

设计不好的框架通常需要多个配置文件,每一个都有许多设置。 这些配置文件为每一个项目提供信息说明从URL到将类映射到数据库表的各种信息。大量包含太多参数的配置文件通常是过度复杂的应用设计的指标。

magento在设计方面违背该原则,当然,各有优劣,在增强扩展性方面,配置优于约定,magento强大的生态插件也是得益于灵活的配置 ,造成的后果就是定位文件难,时间开销大,排查莫名的bug方面难度加大,二次开发困难。

5.7考虑未来重构性

代码文件要尽量的解耦,减少相互依赖,这样可以方便的在将来重构功能

5.7.1可以方便的将某种搜索方式更改为elasticSearch

5.7.2可以方便的将存储到mysql的cart信息,改为存储到redis里面

5.7.3当网站业务上升,为解决高并发读写部分而引入分库分表,可以方便的在底层修改

5.7.4将来系统的某些底层,由本地的数据库获取数据,改为从远程的api调用

等等,解决公司业务上升后,系统不能满足并发,而需要进行底层重构的需求。

6.其他阅读

https://laravel-china.org/articles/5265/how-to-build-an-open-source-project-that-breaks-thousands-of-star

https://www.oschina.net/translate/starting-open-source-project?cmp

共收到 0 条回复
没有找到数据。
添加回复 (需要登录)
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册
Your Site Analytics