diff --git "a/\347\254\254\345\233\233\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\254\345\233\233\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 982486e0dbaf52d2a5d00770ab7c375db711eb05..f8d0f8cd756ed87051f63b4fc68caeb498280fb9 100644 --- "a/\347\254\254\345\233\233\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\254\345\233\233\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" @@ -6,8 +6,8 @@ 那在聊你要做什么这个问题之前，我们先聊下你不做什么。 -- 大型的框架或软件，比如做一个IDE工具，开发一门新的脚本语言，一来涉及面太广，短期内做不完，二来你也并不一定有能力去解决处理到大型框架软件所涉及的技术细节。 -- 重新造一个轮子，比如重新写一个RPC框架，重新写一个ORM框架。这些领域都相对比较成熟，是每个项目的基础中间件的选型，已经有非常成熟的方案，用户的使用习惯很难去改变，也意味着即便你造成了轮子，用户也最多是学习，而不会很大规模的使用到生产环境中。 +- 大型的框架或软件，比如做一个 IDE 工具，开发一门新的脚本语言，一来涉及面太广，短期内做不完，二来你也并不一定有能力去解决处理到大型框架软件所涉及的技术细节。 +- 重新造一个轮子，比如重新写一个 RPC 框架，重新写一个 ORM 框架。这些领域都相对比较成熟，是每个项目的基础中间件的选型，已经有非常成熟的方案，用户的使用习惯很难去改变，也意味着即便你造成了轮子，用户也最多是学习，而不会很大规模的使用到生产环境中。 - 无法通用的项目，比如只能在你公司某个特定业务场景中起到作用，这个场景非常单一。对于其他的用户来说，这个项目就没多大价值。 - 非常小众的东西，即便你做出来，因为对大多数人来说，并用不到这东西。所以最后影响你项目的推广。 @@ -18,7 +18,7 @@ - 尽量选择一个比较精准的痛点，而市面上的相关开源软件选择相对比较少，做一个小而美的项目，比做一个大而全的项目要来的更容易起步，开发周期也比较快。 - 即便赛道上有类似的开源项目，你也可以寻求差异化，在某一个方面做到极致。比如更加轻量化，易用性更强，支持的扩展更多，维度更高。 - 尽量选择可以持续发展的项目，小到可以解决某一个痛点，大到持续发展可以帮助一个领域解决问题。 -- 做大众化的项目，能被大多数场景运用，这样有利于你的推广 +- 做大众化的项目，能被大多数场景运用，这样有利于你的推广。 @@ -26,23 +26,27 @@ 如果你已经选择好了项目的赛道，先别慌着动手，建议在开源社区内寻找下你这个赛道里其他的开源项目。 -一开始最好去找开源社区里最活跃的同类型项目，评判一个项目是否活跃，一是看这个项目的star数，二是看这个项目是否一直在更新，三是看issue数量和评论数量。找到这样的一个项目后，可以去看看这个项目的特性，这会帮助你在设计你的项目时了解所需要关注的点，有可能有些特性你是没有想到的。然后最好去clone这个项目的代码到本地，如果有时间，最好还是仔细的去阅读下人家的代码。如果读不懂，一般成熟的项目总有例子和单元测试。最好亲自去跑下别人的例子和单测，再结合项目的特性。能帮助你对这个项目有更好直观上的理解。 +一开始最好去找开源社区里最活跃的同类型项目，评判一个项目是否活跃，一是看这个项目的 star 数，二是看这个项目是否一直在更新，三是看 issue 数量和评论数量。找到这样的一个项目后，可以去看看这个项目的特性，这会帮助你在设计你的项目时了解所需要关注的点，有可能有些特性你是没有想到的。然后最好去 clone 这个项目的代码到本地，如果有时间，最好还是仔细的去阅读下人家的代码。如果读不懂，一般成熟的项目总有例子和单元测试。最好亲自去跑下别人的例子和单元测试，再结合项目的特性，能帮助你对这个项目有更好直观上的理解。 -然后再去找一下这个赛道里其他的项目，挑一些star数相对比较高的项目看看。再和最活跃的那个项目，进行一个横向对比。思考下为什么这个赛道里排名最高的那个项目会得到使用者的青睐。这样总结一番，你会对在这个赛道里如何脱颖而出有一个大致的判断。这会对你的项目要做成什么样有很大的帮助。 +然后再去找一下这个赛道里其他的项目，挑一些 star 数相对比较高的项目看看。再和最活跃的那个项目，进行一个横向对比。思考下为什么这个赛道里排名最高的那个项目会得到使用者的青睐。这样总结一番，你会对在这个赛道里如何脱颖而出有一个大致的判断。这会对你的项目要做成什么样有很大的帮助。 -同时也建议去看看赛道里高star项目的issue，issue基本能反映出一个项目历史的迭代过程和目前的进展，这当中有用户提出的改进，有作者自己加的一些特性。每个issue有一个标签，能反映出这个issue是bug还是增强，还是新特性。建议你只过滤出增强和新特性。这基本上就是一个项目迭代的历史过程了。如果一个项目都没有issue，只能说明迭代度比较差，或者受到的关注度使用度比较少。这种项目也基本没有看的必要。 +同时也建议去看看赛道里高 star 项目的 issue，issue 基本能反映出一个项目历史的迭代过程和目前的进展，这当中有用户提出的改进，有作者自己加的一些特性。每个 issue 有一个标签，能反映出这个 issue 是 bug 还是增强，还是新特性。建议你只过滤出增强和新特性。这基本上就是一个项目迭代的历史过程了。如果一个项目都没有 issue，只能说明迭代度比较差，或者受到的关注度使用度比较少。这种项目也基本没有看的必要。 -如果你发现在这个赛道里有一大批活跃高star的项目，他们也各有特点。基本上可以解决所有的这个领域的痛点。那么还是建议你换一个赛道。你的项目一定要有自己的特点，如果你的项目的特性，使用方式都和其他项目差不多或者还不如其他项目，那为什么指望用户用你的项目呢。 +如果你发现在这个赛道里有一大批活跃高 star 的项目，他们也各有特点。基本上可以解决所有的这个领域的痛点。那么还是建议你换一个赛道。你的项目一定要有自己的特点，如果你的项目的特性，使用方式都和其他项目差不多或者还不如其他项目，那为什么指望用户用你的项目呢。 那有些同学就会说，现在开源项目那么多，在每个领域都有很多已经做的非常好的项目了，我怎么做都感觉是在造轮子，既然造轮子无意义，那我也没有做的必要了。 -首先我觉得造轮子并不是无意义，造轮子是有意义的，但是造轮子的意义是在于你自己可以通过造轮子来获得对技术的剖析和理解。但是如果你做开源项目的目标是想把项目推广给社区，让社区里的人来用的话，那么造一样的轮子是没有意义的。每个领域的确有一些做的非常好的项目了，绝大多数情况下，你也不太有机会去新开辟一个领域去做。但是不见得每个领域里的项目都面面俱到。正如前面开头说的那样，可以做差异化竞争。比如这个领域里头部的项目是一个功能非常全的项目，但是某一个功能点可能用的不那么爽，你就可以针对这个点做一个小而精的项目，在这个功能点上做到极致，让使用者觉得很爽。差异化是一个比较好的思路，相信如果你对这个领域的项目作出足够的研究后，一定能找到一个差异化的点去挖掘。 +首先我觉得造轮子并不是无意义，造轮子是有意义的，但是造轮子的意义是在于你自己可以通过造轮子来获得对技术的剖析和理解。但是如果你做开源项目的目标是想把项目推广给社区，让社区里的人来用的话，那么造一样的轮子是没有意义的。每个领域的确有一些做的非常好的项目了，绝大多数情况下，你也不太有机会去新开辟一个领域去做。但是不见得每个领域里的项目都面面俱到。正如前面开头说的那样，可以做差异化竞争。 + +> 就像洗发水一样的，这个品牌的洗发水主打清香的功效，洗完可以飘香十里，那么它对于需要增加回头率的女孩子就是十分有吸引力的。那个品牌的洗发水主打夏季的清爽，洗完感觉有薄荷的那种凉凉的感觉，那么它对于汗多油腻的男孩子们就相当有吸引力了。这就是差异化竞争。 + +同理可以类比于我们的项目，比如这个领域里头部的项目是一个功能非常全的项目，但是某一个功能点可能用的不那么爽，你就可以针对这个点做一个小而精的项目，在这个功能点上做到极致，让使用者觉得很爽。差异化是一个比较好的思路，相信如果你对这个领域的项目作出足够的研究后，一定能找到一个差异化的点去挖掘。 @@ -66,7 +70,7 @@ 开源项目的初始架构至关重要，你之后的迭代都是围绕这个整体架构进行的，当然中间也可以进行重构，但是付出的成本要大很多。在设计项目架构时，有以下几点建议： -- 那尽量选择较新比较流行的选型。老旧过时的选型在用户使用时可能会碰到兼容等各种问题，选择一个流行的选型会最大程度上降低这种问题的发生。 +- 尽量选择较新比较流行的选型。老旧过时的选型在用户使用时可能会碰到兼容等各种问题，选择一个流行的选型会最大程度上降低这种问题的发生。 - 精简你的依赖，只选择你的项目必须的依赖。过多的依赖也会导致兼容性的问题。 - 一开始就要考虑到扩展性，模块之间的松耦合做好，边界定义清晰，这对项目之后的良性循环很重要。 - 在设计之初就要考虑到使用者环境的多样性，比如同一个选型的不同版本，不同操作系统等等。 @@ -79,7 +83,7 @@ -还有就是起名字的时候不易太精确，这样不利于扩展。比如你想做数据库的性能监控框架，如果你起名为mysql-monitor，那你之后迭代万一想兼容其他数据库，那这个名字就有点局限性了。如果叫db-monitor，就比较贴切点。 +还有就是起名字的时候不易太精确，这样不利于扩展。比如你想做数据库的性能监控框架，如果你起名为 `mysql-monitor`，那你之后迭代万一想兼容其他数据库，那这个名字就有点局限性了。如果叫 `db-monitor`，就比较贴切点。 @@ -87,11 +91,11 @@ -## 为你的项目写一个Readme +## 为你的项目写一个 Readme 文件 -基于Git规范的代码托管平台，一般Readme都能直接展示在你的项目首页，可以起一个快速介绍，快速上手的作用。 +基于 Git 规范的代码托管平台，一般 Readme 都能直接展示在你的项目首页，可以起一个快速介绍，快速上手的作用。 -一个好的Readme应该包含以下几点： +一个好的 Readme 应该包含以下几点： 1）项目的名称，简短介绍，基本上简短概括为主，说明你的项目主要用在哪些领域，能解决哪些问题。 @@ -99,9 +103,9 @@ 3）简单的快速开始用例，这部分旨在用最快的方式让别人通过用例了解你的项目。你项目中细节的说明和配置不应该放到这里。否则就会显得太冗长了。 -4）个人不太建议把项目的文档写在readme中，因为文档本身是项目使用的详细说明，会涵盖各个方面，放到readme里面不太妥当，如果你有自己的文档页面，应当在readme里面放一个超链进行跳转。 +4）个人不太建议把项目的文档写在 readme 中，因为文档本身是项目使用的详细说明，会涵盖各个方面，放到 readme 里面不太妥当，如果你有自己的文档页面，应当在 readme 里面放一个超链进行跳转。当然如果你的项目非常的小，基本上一页纸就能说完的事情，放到 readme 中也是可以的。 -5）作者的介绍，和联系方式。让别人碰到问题时能快速联系到你。 +5）作者的介绍，和联系方式（或者提供提 Issue 或者 Pull Requests 的方式等）。让别人碰到问题时能快速联系到你。 @@ -109,22 +113,22 @@ 如果你想做成一个成熟规范的开源项目，那么版本号应当遵从开源项目的规范，对你的迭代也有帮助。 -版本号建议为3位数字，比如`1.1.0`，`1.5.1`这样，但是我们经常看到在版本号后面还有一些修饰词，比如`beta`,`release`等等，对于这部分的规范如下： +版本号建议为 3 位数字，比如 `1.1.0`，`1.5.1` 这样，但是我们经常看到在版本号后面还有一些修饰词，比如 `beta`,`release` 等等，对于这部分的规范如下： - alpha：内部测试版本，BUG可能比较多，一般用于开发人员内部使用 -- beta：测试版，BUG相比alpha少一点，但同样不建议用于生产环境，一般用于面向急于使用新功能的群众进行公测，并向开发人员进行反馈 -- rc： release candidate，即将作为正式版发布，BUG较少，正式版之前的最后一个测试版。 -- ga：general availability，首次发行的稳定版，比较稳定，可以用于生产。 -- release/或者干脆啥都不加： 最终释放版，可以面向广大的一般用户 +- beta：测试版，BUG 相比 alpha 少一点，但同样不建议用于生产环境，一般用于面向急于使用新功能的群众进行公测，并向开发人员进行反馈 +- rc：release candidate，即将作为正式版发布，BUG 较少，正式版之前的最后一个测试版 +- ga：general availability，首次发行的稳定版，比较稳定，可以用于生产 +- release/或者干脆啥都不加：最终释放版，可以面向广大的一般用户 -那对于3位数的版本号的管理策略如下： +那对于 3 位数的版本号的管理策略如下： -- 项目初始版本可以是`1.0.0` -- 项目进行BUG修正时，最后一位加1，比如`1.0.1` -- 项目有新特性发布时，中间一位数加1，同时最后一位复位为0，比如`1.1.0` -- 项目有重大特性发布，同时结构可能不向下兼容时，第一位数字加1，其他位数复位为0，比如`2.0.0` +- 项目初始版本可以是 `1.0.0` +- 项目进行 BUG 修正时，最后一位加 1，比如 `1.0.1` +- 项目有新特性发布时，中间一位数加 1，同时最后一位复位为 0，比如 `1.1.0` +- 项目有重大特性发布，同时结构可能不向下兼容时，第一位数字加 1，其他位数复位为 0，比如 `2.0.0` @@ -154,7 +158,7 @@ 3）保持条理性：你可以再文档中通过写标题，划重点，引链接等方式，把各类信息划分为不同的部分，避免将所有内容都揉在一大段冗长的文字当中。 -4）提高可读性：除了文字之外，使用图标也是从多种角度表达的方式之一。 +4）提高可读性：除了文字之外，使用图标也是众多种角度表达的方式之一。 5）注意拼写和语法：必须检查文档中是否有词语的拼写错误和语法错误，尤其是程序的关键词语。