diff --git "a/\347\254\2544\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" "b/\347\254\2544\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" index 24524fa8fafef3c3faf005031df388219b5af4eb..5e7b064d97aee6136f50a6e60919cf9b0bba9ff9 100644 --- "a/\347\254\2544\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" +++ "b/\347\254\2544\351\203\250\345\210\206\342\200\224\342\200\224\345\220\257\345\212\250\350\207\252\345\267\261\347\232\204\345\274\200\346\272\220\351\241\271\347\233\256/\346\234\211\344\272\206\345\274\200\346\272\220\347\232\204\346\203\263\346\263\225\345\220\216\344\273\216\344\275\225\345\274\200\345\247\213.md" @@ -2,8 +2,6 @@ 如果你有开源的想法，面临的第一个问题应该就是要做一个什么样的项目。这一步至关重要，很多想要开源的同学就因为这步选错了，导致了项目刚开始或者做到一半就放弃了。 - - 那在聊你要做什么这个问题之前，我们先聊下你不做什么。 - 大型的框架或软件，比如做一个 IDE 工具，开发一门新的脚本语言，一来涉及面太广，短期内做不完，二来你也并不一定有能力去解决处理到大型框架软件所涉及的技术细节。 @@ -11,8 +9,6 @@ - 无法通用的项目，比如只能在你公司某个特定业务场景中起到作用，这个场景非常单一。对于其他的用户来说，这个项目就没多大价值。 - 非常小众的东西，即便你做出来，因为对大多数人来说，并用不到这东西。所以最后影响你项目的推广。 - - 那如何选择你要做什么呢。选择一个相对合适的赛道非常重要，有几点建议可以供你参考： - 尽量选择一个比较精准的痛点，而市面上的相关开源软件选择相对比较少，做一个小而美的项目，比做一个大而全的项目要来的更容易起步，开发周期也比较快。 @@ -20,24 +16,16 @@ - 尽量选择可以持续发展的项目，小到可以解决某一个痛点，大到持续发展可以帮助一个领域解决问题。 - 做大众化的项目，能被大多数场景运用，这样有利于你的推广。 - - ## 同赛道的项目都做了些什么 如果你已经选择好了项目的赛道，先别慌着动手，建议在开源社区内寻找下你这个赛道里其他的开源项目。 一开始最好去找开源社区里最活跃的同类型项目，评判一个项目是否活跃，一是看这个项目的 star 数，二是看这个项目是否一直在更新，三是看 issue 数量和评论数量。找到这样的一个项目后，可以去看看这个项目的特性，这会帮助你在设计你的项目时了解所需要关注的点，有可能有些特性你是没有想到的。然后最好去 clone 这个项目的代码到本地，如果有时间，最好还是仔细的去阅读下人家的代码。如果读不懂，一般成熟的项目总有例子和单元测试。最好亲自去跑下别人的例子和单元测试，再结合项目的特性，能帮助你对这个项目有更好直观上的理解。 - - 然后再去找一下这个赛道里其他的项目，挑一些 star 数相对比较高的项目看看。再和最活跃的那个项目，进行一个横向对比。思考下为什么这个赛道里排名最高的那个项目会得到使用者的青睐。这样总结一番，你会对在这个赛道里如何脱颖而出有一个大致的判断。这会对你的项目要做成什么样有很大的帮助。 - - 同时也建议去看看赛道里高 star 项目的 issue，issue 基本能反映出一个项目历史的迭代过程和目前的进展，这当中有用户提出的改进，有作者自己加的一些特性。每个 issue 有一个标签，能反映出这个 issue 是 bug 还是增强，还是新特性。建议你只过滤出增强和新特性。这基本上就是一个项目迭代的历史过程了。如果一个项目都没有 issue，只能说明迭代度比较差，或者受到的关注度使用度比较少。这种项目也基本没有看的必要。 - - 如果你发现在这个赛道里有一大批活跃高 star 的项目，他们也各有特点。基本上可以解决所有的这个领域的痛点。那么还是建议你换一个赛道。你的项目一定要有自己的特点，如果你的项目的特性，使用方式都和其他项目差不多或者还不如其他项目，那为什么指望用户用你的项目呢。 那有些同学就会说，现在开源项目那么多，在每个领域都有很多已经做的非常好的项目了，我怎么做都感觉是在造轮子，既然造轮子无意义，那我也没有做的必要了。 @@ -48,24 +36,16 @@ 同理可以类比于我们的项目，比如这个领域里头部的项目是一个功能非常全的项目，但是某一个功能点可能用的不那么爽，你就可以针对这个点做一个小而精的项目，在这个功能点上做到极致，让使用者觉得很爽。差异化是一个比较好的思路，相信如果你对这个领域的项目作出足够的研究后，一定能找到一个差异化的点去挖掘。 - - -## 短期目标&中长期目标 +## 短期目标 & 中长期目标 如果你已经选好了赛道，你需要为你的项目制定一个短期目标。 所谓短期目标其实就是你的项目第一个稳定版本应该达到的预期。在做短期目标的时候，应该以实际为主，切勿目标定的很宏大，过大的目标会消耗你太多的开发周期，正所谓一鼓作气，再而竭，三而衰。一口气吃不成胖子，长周期的开发本身就是一件需要毅力的事情，而很多人会在这漫长的周期内会被消耗掉原先的激情。 - - 相对确定，短小的目标可以令你缩短开发周期，迅速达成。本来开源软件就是一个漫长的迭代过程，假设你有一些宏大的目标，都是可以通过慢慢迭代实现的。而快速放到开源社区的另外一个好处是，可以通过社区的正向反馈来调整你的迭代的过程。毕竟开源项目一开始的所有特性和功能基本上都是你一个人拍板的，但是开源之后，你可以了解到更多人的反馈。有些一开始的想法会随着反馈的增加而进行改变。这也是自我思想迭代的一个过程。 - - 对于中长期目标我的建议是，在你第一版的时候可以先计划下大概的方向，在项目架构层面留好可以扩展的方向。但是细节点可以不用在这个阶段过多考虑。 - - ## 设计好你的项目架构 开源项目的初始架构至关重要，你之后的迭代都是围绕这个整体架构进行的，当然中间也可以进行重构，但是付出的成本要大很多。在设计项目架构时，有以下几点建议： @@ -75,21 +55,13 @@ - 一开始就要考虑到扩展性，模块之间的松耦合做好，边界定义清晰，这对项目之后的良性循环很重要。 - 在设计之初就要考虑到使用者环境的多样性，比如同一个选型的不同版本，不同操作系统等等。 - - ## 为你的项目定一个名称 -一个好的项目名称能让你的项目更加引人关注，虽然起名字没有什么讲究，随你的喜好，但是为了能使你的项目被人所关注，还是建议尽量起和这个领域有关的单词，最好简洁，不要过于复杂。容易让人记住的名字。 - - +一个好的项目名称能让你的项目更加引人关注，虽然起名字没有什么讲究，随你的喜好，但是为了能使你的项目被人所关注，还是建议尽量起和这个领域有关的单词，最好简洁，不要过于复杂，容易让人记住的名字。 还有就是起名字的时候不易太精确，这样不利于扩展。比如你想做数据库的性能监控框架，如果你起名为 `mysql-monitor`，那你之后迭代万一想兼容其他数据库，那这个名字就有点局限性了。如果叫 `db-monitor`，就比较贴切点。 - - -项目名是项目的门面，就像一个人的名字。在定名字的时候，也不要过于花哨。以贴切简洁为主。 - - +项目名是项目的门面，就像一个人的名字。在定名字的时候，也不要过于花哨，以贴切简洁为主。 ## 为你的项目写一个 Readme 文件 @@ -107,8 +79,6 @@ 5）作者的介绍和联系方式（或者提供提 Issue 或者 Pull Requests 的方式等）。让别人碰到问题时能快速联系到你。 - - ## 建立严格的版本号规范 如果你想做成一个成熟规范的开源项目，那么版本号应当遵从开源项目的规范，对你的迭代也有帮助。 @@ -119,9 +89,7 @@ - beta：测试版，BUG 相比 alpha 少一点，但同样不建议用于生产环境，一般用于面向急于使用新功能的群众进行公测，并向开发人员进行反馈 - rc：release candidate，即将作为正式版发布，BUG 较少，正式版之前的最后一个测试版 - ga：general availability，首次发行的稳定版，比较稳定，可以用于生产 -- release/或者干脆啥都不加：最终释放版，可以面向广大的一般用户 - - +- release/或者干脆啥都不加：最终发布版，可以面向广大的一般用户 那对于 3 位数的版本号的管理策略如下： @@ -130,8 +98,6 @@ - 项目有新特性发布时，中间一位数加 1，同时最后一位复位为 0，比如 `1.1.0` - 项目有重大特性发布，同时结构可能不向下兼容时，第一位数字加 1，其他位数复位为 0，比如 `2.0.0` - - ## 完善测试用例 我们在做企业级项目的时候，测试用例是必不可少的。同样我们在做开源项目的时候，测试用例其实更为重要，测试用例能检查出你的任何改动是不是对其他功能产生了影响。这从根本上就保证了你的项目质量。 @@ -142,16 +108,12 @@ 一份完善的测试用例，能够使你的开源项目质量成倍的提高，当然你在这之中所付出的时间精力也是巨大的。 - - ## 为你的项目建立一份使用文档 首先得清楚，使用文档是给用户阅读的。所以在你的使用文档里面，你应该尽可能的避免阐述你的一些实现细节。 一份好的使用文档应当是能让用户和你的项目快速建立连接的，这里有一些写作文档的建议： - - 1）使用主动语态：尽可能使用“你可以这样更改配置”，而避免过多的使用“配置可以这样更改"，这样在阅读体验上会更加容易，反之就会显得你的文档比较拗口。 2）使用简洁明了的句子：写文档不是写小说，不是写诗歌，不需要用过多的修饰词，能让用户明白你想表达的意思即可。 @@ -162,10 +124,8 @@ 5）注意拼写和语法：必须检查文档中是否有词语的拼写错误和语法错误，尤其是程序的关键词语。 - - 只要在文档的写作和编辑过程中应用到良好的技巧，你就能和读者建立起沟通和信任，读者会觉得你的项目很专业，印象上也会加分不少。 ## 开源项目可以和自媒体结合 -如果开源项目分值数太少，可以和开源课程，自媒体，公众号、短视频、写书等集成结合在一起可以为项目加分，又可以传播开源项目知识，增加开源项目的流量访问，既有开源课程&项目，贡献自己的一份开源力量。 +如果开源项目分值数太少，可以和开源课程、自媒体、公众号、短视频、写书等结合在一起，既可以为项目加分又可以传播开源项目知识，增加开源项目的流量访问，同时也贡献了自己的一份开源力量。