做好一个开源项目其实是一件比较费时费力费心的工作，它的最大难点除了代码维护之外，还包括后期的维护和持续的跟进。我曾经做过不少开源项目，但是坚持下来的，目前有信心能够持续维护的也只有Magicodes.IE。这里请允许我来一波硬广：
Magicodes.IE
导入导出通用库，支持Dto导入导出以及动态导出，支持Excel、Word、Pdf、Csv和Html。已加入NCC开源组织。
- Github： https://github.com/dotnetcore/Magicodes.IE
- 码云（手动同步，不维护）： https://gitee.com/magicodes/Magicodes.IE
如何打造一个好的开源项目？
我们回归正题。如何做好一个开源项目呢？接下来来说道说道：
1）有一个好的理念和创意
如果大家都在做重复的事情，但是又没有合适的轮子的时候，那么我们就可以创造一个。
如果轮子很多，但是没有好用的，或者不够通用，那么我们就可以动手写一个。
Magicodes.IE就是在这种情况下诞生的。导入导出是一个非常普遍的场景，相关的组件也很多，比如就拿导出Excel来说，主流的就有EPPlus、NPOI等等库。那么为什么我们还需要再造轮子呢？因为我们发现，在大部分场景下使用这些库我们都需要进行一些重复性的编码以及特定针对Excel的操作的编码才能满足我们的需求，那么有没有更合适的做法？所以就有了Magicodes.IE，通过设置Dto就能满足大部分导入导出的场景，并且还支持除了Excel之外的其他导入导出格式。
2）写好代码
代码规范，易于阅读这些都是必不可少的。尤其是在多人远程协作的情况下，代码审阅，定期重构也非常有必要。否则大家就算是想贡献代码，但是也要看得懂不是？
3）充分的测试
代码写好了，上去就是干明显就是挖坑。随着项目的时间越长，代码重构或者功能迭代就越需要测试的保障，而不是个人感觉或者编译通过即可。
那么如何做好充分的测试呢？
1.完善的单元测试
每一次功能迭代或者Bug修复，均要完善好相关的单元测试。单元测试是代码可靠程度的最基本的保障。
2.尽可能提高代码覆盖率
代码覆盖率作为一个指导性指标，可以一定程度上反应测试的完备程度，是软件质量度量的一种手段。100%覆盖的代码并不意味着100%无bug的应用，代码覆盖率作为质量目标没有任何意义，而我们应该把它作为一种发现未被测试覆盖的代码的手段。
通过代码覆盖率测试，我们可以了解测试过程中覆盖和未覆盖的地方，可能存在的风险。分析未覆盖代码，反推在测试设计是否充分，进一步明确测试设计阶段的问题。
代码覆盖率测试也有助于我们发现测试死角、冗余代码、历史废弃代码，便于重构。
3.使用自动化测试来保障每次提交和验证PR
开源项目有很多DevOps的服务可以选择，我们可以基于其打造自己的自动化测试来保障开源项目的质量，以针对每次提交、PR进行验证，并且作为资源发布的参考依据。
4）友好的文档
文档一直是开源项目运作的一个难题：
- 代码写的欢，文档难产。
- 本地化文档（中文文档）没问题，其他语言文档（英文文档）难以编写。
- 文档的更新永远跟不上代码的更新，版本的迭代。
友好的文档一直是开源项目吸引用户的首要标准，所以文档是必须的。
Magicodes.IE的文档也在积极补充和完善之中，希望大家能够多多支持：
- Magicodes.IE之导入学生数据教程
- Magicodes.IE基础教程之导出Excel
- Magicodes.IE基础教程之导出Pdf
- Excel模板导出之导出教材订购表
- 使用Magicodes.IE.Excel完成Excel图片的导入和导出
5）版本规划和管理
对于开源项目来说，版本规划和发布版本也不应该是一件随意的事情。毕竟错误的版本可能会给用户带来灾难性的问题。不合理的规划，也可能会将项目带入沟渠。
这里分享几个经验：
- 版本规划我们通过收集反馈来进行规划。如Magicodes.IE就通过Issue收集用户反馈、讨论以推出新的版本：
- 资源发版提供详细的版本日志，以供用户参考和追踪：
- 测试版预先发布Beta版的包，如上图中的2.2.0-beta2。
6）做好推广
其实也就是让可能需要他、真正需要他的人知道他的存在。从技术人的角度建议如下：
- 和技术社区合作，分享干货，不水群，不瞎聊
- 加入知名开源组织，比如Magicodes.IE就加入了NCC开源组织
- 不要理会喷子。干自己认为有价值的事情，不要理会那些只会喷但是啥也不会做的麻瓜。对于开源作者伤害最大的其实就是喷子和嘴炮，大家都是利用业余精力去支持和付出，为社区做贡献，不图你支持，但是希望你别图一时嘴快！不爱用那你就滚啊，不好用那你写个更好用的分享出来啊！
7）关注反馈，持续更新
- 从Issue中来，到代码中去。 在开源项目达到一定规模时，社区就会给出非常多的反馈。这是单兵作战肯定是不适合的，那么适时组成自己的开源团队或者开源管理委员会就非常有必要了。同时，社区反馈的很多问题往往都是过于偏具体业务的需求，这时就需要我们去抽取出通用的需求了。
- 欢迎PR，及时处理PR！ 开源项目在前期往往均只能利用业余精力运作，那么每一个PR都是非常宝贵的，团队一定要及时验证并处理。先以功能优先，再适当重构。
- 大小版本提前规划，小版本快速迭代！
开源项目既需要有长期的规划，以确保长期的方向，也需要有短期的计划和目标。这样对团队对用户都是有帮助的。同时小版本规划或者考虑的功能也可以通过Issue的方式和用户探讨：
最后
本篇仅是笔者结合Magicodes.IE讲解如何做好一个开源项目的第一篇，接下来，我们会讲解如何基于开源项目完成徽章、DevOps等等。
转载是一种动力 分享是一种美德