做好一个开源项目其实是一件比较费时费力费心的工作,它的最大难点除了代码维护之外,还包括后期的维护和持续的跟进。我曾经做过不少开源项目,但是坚持下来的,目前有信心能够持续维护的也只有Magicodes.IE。这里请允许我来一波硬广:
导入导出通用库,支持Dto导入导出以及动态导出,支持Excel、Word、Pdf、Csv和Html。已加入NCC开源组织。
我们回归正题。如何做好一个开源项目呢?接下来来说道说道:
如果大家都在做重复的事情,但是又没有合适的轮子的时候,那么我们就可以创造一个。
如果轮子很多,但是没有好用的,或者不够通用,那么我们就可以动手写一个。
Magicodes.IE就是在这种情况下诞生的。导入导出是一个非常普遍的场景,相关的组件也很多,比如就拿导出Excel来说,主流的就有EPPlus、NPOI等等库。那么为什么我们还需要再造轮子呢?因为我们发现,在大部分场景下使用这些库我们都需要进行一些重复性的编码以及特定针对Excel的操作的编码才能满足我们的需求,那么有没有更合适的做法?所以就有了Magicodes.IE,通过设置Dto就能满足大部分导入导出的场景,并且还支持除了Excel之外的其他导入导出格式。
代码规范,易于阅读这些都是必不可少的。尤其是在多人远程协作的情况下,代码审阅,定期重构也非常有必要。否则大家就算是想贡献代码,但是也要看得懂不是?
代码写好了,上去就是干明显就是挖坑。随着项目的时间越长,代码重构或者功能迭代就越需要测试的保障,而不是个人感觉或者编译通过即可。
那么如何做好充分的测试呢?
1.完善的单元测试
每一次功能迭代或者Bug修复,均要完善好相关的单元测试。单元测试是代码可靠程度的最基本的保障。
2.尽可能提高代码覆盖率
代码覆盖率作为一个指导性指标,可以一定程度上反应测试的完备程度,是软件质量度量的一种手段。100%覆盖的代码并不意味着100%无bug的应用,代码覆盖率作为质量目标没有任何意义,而我们应该把它作为一种发现未被测试覆盖的代码的手段。
通过代码覆盖率测试,我们可以了解测试过程中覆盖和未覆盖的地方,可能存在的风险。分析未覆盖代码,反推在测试设计是否充分,进一步明确测试设计阶段的问题。
代码覆盖率测试也有助于我们发现测试死角、冗余代码、历史废弃代码,便于重构。
3.使用自动化测试来保障每次提交和验证PR
开源项目有很多DevOps的服务可以选择,我们可以基于其打造自己的自动化测试来保障开源项目的质量,以针对每次提交、PR进行验证,并且作为资源发布的参考依据。
文档一直是开源项目运作的一个难题:
友好的文档一直是开源项目吸引用户的首要标准,所以文档是必须的。
Magicodes.IE的文档也在积极补充和完善之中,希望大家能够多多支持:
对于开源项目来说,版本规划和发布版本也不应该是一件随意的事情。毕竟错误的版本可能会给用户带来灾难性的问题。不合理的规划,也可能会将项目带入沟渠。
这里分享几个经验:
其实也就是让可能需要他、真正需要他的人知道他的存在。从技术人的角度建议如下:
开源项目既需要有长期的规划,以确保长期的方向,也需要有短期的计划和目标。这样对团队对用户都是有帮助的。同时小版本规划或者考虑的功能也可以通过Issue的方式和用户探讨:
本篇仅是笔者结合Magicodes.IE讲解如何做好一个开源项目的第一篇,接下来,我们会讲解如何基于开源项目完成徽章、DevOps等等。
转载是一种动力 分享是一种美德