From 4c878478be6546d1000b4e4ca25a7b889d9337f7 Mon Sep 17 00:00:00 2001
From: bryan31 <weenyc31@163.com>
Date: Tue, 3 Nov 2020 14:21:37 +0800
Subject: [PATCH] =?UTF-8?q?update=20=E7=AC=AC=E5=9B=9B=E9=83=A8=E5=88=86?=
 =?UTF-8?q?=E2=80=94=E2=80=94=E5=90=AF=E5=8A=A8=E8=87=AA=E5=B7=B1=E7=9A=84?=
 =?UTF-8?q?=E5=BC=80=E6=BA=90=E9=A1=B9=E7=9B=AE/=E6=9C=89=E4=BA=86?=
 =?UTF-8?q?=E5=BC=80=E6=BA=90=E7=9A=84=E6=83=B3=E6=B3=95=E5=90=8E=E4=BB=8E?=
 =?UTF-8?q?=E4=BD=95=E5=BC=80=E5=A7=8B.md.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...16\344\275\225\345\274\200\345\247\213.md" | 164 +++++++++++++++++-
 1 file changed, 163 insertions(+), 1 deletion(-)

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 18cb860..982486e 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"
@@ -1 +1,163 @@
-> 先有项目后开源，还是从零开始做开源？两种方式分别需要做些什么？不同的方式有什么利弊吗？
\ No newline at end of file
+## 你要做什么
+
+如果你有开源的想法，面临的第一个问题应该就是要做一个什么样的项目。这一步至关重要，很多想要开源的同学就因为这步选错了，导致了项目刚开始或者做到一半就放弃了。
+
+
+
+那在聊你要做什么这个问题之前，我们先聊下你不做什么。
+
+- 大型的框架或软件，比如做一个IDE工具，开发一门新的脚本语言，一来涉及面太广，短期内做不完，二来你也并不一定有能力去解决处理到大型框架软件所涉及的技术细节。
+- 重新造一个轮子，比如重新写一个RPC框架，重新写一个ORM框架。这些领域都相对比较成熟，是每个项目的基础中间件的选型，已经有非常成熟的方案，用户的使用习惯很难去改变，也意味着即便你造成了轮子，用户也最多是学习，而不会很大规模的使用到生产环境中。
+- 无法通用的项目，比如只能在你公司某个特定业务场景中起到作用，这个场景非常单一。对于其他的用户来说，这个项目就没多大价值。
+- 非常小众的东西，即便你做出来，因为对大多数人来说，并用不到这东西。所以最后影响你项目的推广。
+
+
+
+那如何选择你要做什么呢。选择一个相对合适的赛道非常重要，有几点建议可以供你参考：
+
+- 尽量选择一个比较精准的痛点，而市面上的相关开源软件选择相对比较少，做一个小而美的项目，比做一个大而全的项目要来的更容易起步，开发周期也比较快。
+- 即便赛道上有类似的开源项目，你也可以寻求差异化，在某一个方面做到极致。比如更加轻量化，易用性更强，支持的扩展更多，维度更高。
+- 尽量选择可以持续发展的项目，小到可以解决某一个痛点，大到持续发展可以帮助一个领域解决问题。
+- 做大众化的项目，能被大多数场景运用，这样有利于你的推广
+
+
+
+## 同赛道的项目都做了些什么
+
+如果你已经选择好了项目的赛道，先别慌着动手，建议在开源社区内寻找下你这个赛道里其他的开源项目。
+
+一开始最好去找开源社区里最活跃的同类型项目，评判一个项目是否活跃，一是看这个项目的star数，二是看这个项目是否一直在更新，三是看issue数量和评论数量。找到这样的一个项目后，可以去看看这个项目的特性，这会帮助你在设计你的项目时了解所需要关注的点，有可能有些特性你是没有想到的。然后最好去clone这个项目的代码到本地，如果有时间，最好还是仔细的去阅读下人家的代码。如果读不懂，一般成熟的项目总有例子和单元测试。最好亲自去跑下别人的例子和单测，再结合项目的特性。能帮助你对这个项目有更好直观上的理解。
+
+
+
+然后再去找一下这个赛道里其他的项目，挑一些star数相对比较高的项目看看。再和最活跃的那个项目，进行一个横向对比。思考下为什么这个赛道里排名最高的那个项目会得到使用者的青睐。这样总结一番，你会对在这个赛道里如何脱颖而出有一个大致的判断。这会对你的项目要做成什么样有很大的帮助。
+
+
+
+同时也建议去看看赛道里高star项目的issue，issue基本能反映出一个项目历史的迭代过程和目前的进展，这当中有用户提出的改进，有作者自己加的一些特性。每个issue有一个标签，能反映出这个issue是bug还是增强，还是新特性。建议你只过滤出增强和新特性。这基本上就是一个项目迭代的历史过程了。如果一个项目都没有issue，只能说明迭代度比较差，或者受到的关注度使用度比较少。这种项目也基本没有看的必要。
+
+
+
+如果你发现在这个赛道里有一大批活跃高star的项目，他们也各有特点。基本上可以解决所有的这个领域的痛点。那么还是建议你换一个赛道。你的项目一定要有自己的特点，如果你的项目的特性，使用方式都和其他项目差不多或者还不如其他项目，那为什么指望用户用你的项目呢。
+
+那有些同学就会说，现在开源项目那么多，在每个领域都有很多已经做的非常好的项目了，我怎么做都感觉是在造轮子，既然造轮子无意义，那我也没有做的必要了。
+
+首先我觉得造轮子并不是无意义，造轮子是有意义的，但是造轮子的意义是在于你自己可以通过造轮子来获得对技术的剖析和理解。但是如果你做开源项目的目标是想把项目推广给社区，让社区里的人来用的话，那么造一样的轮子是没有意义的。每个领域的确有一些做的非常好的项目了，绝大多数情况下，你也不太有机会去新开辟一个领域去做。但是不见得每个领域里的项目都面面俱到。正如前面开头说的那样，可以做差异化竞争。比如这个领域里头部的项目是一个功能非常全的项目，但是某一个功能点可能用的不那么爽，你就可以针对这个点做一个小而精的项目，在这个功能点上做到极致，让使用者觉得很爽。差异化是一个比较好的思路，相信如果你对这个领域的项目作出足够的研究后，一定能找到一个差异化的点去挖掘。
+
+
+
+## 短期目标&中长期目标
+
+如果你已经选好了赛道，你需要为你的项目制定一个短期目标。
+
+所谓短期目标其实就是你的项目第一个稳定版本应该达到的预期。在做短期目标的时候，应该以实际为主，切勿目标定的很宏大，过大的目标会消耗你太多的开发周期，正所谓一鼓作气，再而竭，三而衰。一口气吃不成胖子，长周期的开发本身就是一件需要毅力的事情，而很多人会在这漫长的周期内会被消耗掉原先的激情。
+
+
+
+相对确定，短小的目标可以令你缩短开发周期，迅速达成。本来开源软件就是一个漫长的迭代过程，假设你有一些宏大的目标，都是可以通过慢慢迭代实现的。而快速放到开源社区的另外一个好处是，可以通过社区的正向反馈来调整你的迭代的过程。毕竟开源项目一开始的所有特性和功能基本上都是你一个人拍板的，但是开源之后，你可以了解到更多人的反馈。有些一开始的想法会随着反馈的增加而进行改变。这也是自我思想迭代的一个过程。
+
+
+
+对于中长期目标我的建议是，在你第一版的时候可以先计划下大概的方向，在项目架构层面留好可以扩展的方向。但是细节点可以不用在这个阶段过多考虑。
+
+
+
+## 设计好你的项目架构
+
+开源项目的初始架构至关重要，你之后的迭代都是围绕这个整体架构进行的，当然中间也可以进行重构，但是付出的成本要大很多。在设计项目架构时，有以下几点建议：
+
+- 那尽量选择较新比较流行的选型。老旧过时的选型在用户使用时可能会碰到兼容等各种问题，选择一个流行的选型会最大程度上降低这种问题的发生。
+- 精简你的依赖，只选择你的项目必须的依赖。过多的依赖也会导致兼容性的问题。
+- 一开始就要考虑到扩展性，模块之间的松耦合做好，边界定义清晰，这对项目之后的良性循环很重要。
+- 在设计之初就要考虑到使用者环境的多样性，比如同一个选型的不同版本，不同操作系统等等。
+
+
+
+## 为你的项目定一个名称
+
+一个好的项目名称能让你的项目更加引人关注，虽然起名字没有什么讲究，随你的喜好，但是为了能使你的项目被人所关注，还是建议尽量起和这个领域有关的单词，最好简洁，不要过于复杂。容易让人记住的名字。
+
+
+
+还有就是起名字的时候不易太精确，这样不利于扩展。比如你想做数据库的性能监控框架，如果你起名为mysql-monitor，那你之后迭代万一想兼容其他数据库，那这个名字就有点局限性了。如果叫db-monitor，就比较贴切点。
+
+
+
+项目名是项目的门面，就像一个人的名字。在定名字的时候，也不要过于花哨。以贴切简洁为主。
+
+
+
+## 为你的项目写一个Readme
+
+基于Git规范的代码托管平台，一般Readme都能直接展示在你的项目首页，可以起一个快速介绍，快速上手的作用。
+
+一个好的Readme应该包含以下几点：
+
+1）项目的名称，简短介绍，基本上简短概括为主，说明你的项目主要用在哪些领域，能解决哪些问题。
+
+2）项目的特性，也是以简洁的语言进行概括几点。
+
+3）简单的快速开始用例，这部分旨在用最快的方式让别人通过用例了解你的项目。你项目中细节的说明和配置不应该放到这里。否则就会显得太冗长了。
+
+4）个人不太建议把项目的文档写在readme中，因为文档本身是项目使用的详细说明，会涵盖各个方面，放到readme里面不太妥当，如果你有自己的文档页面，应当在readme里面放一个超链进行跳转。
+
+5）作者的介绍，和联系方式。让别人碰到问题时能快速联系到你。
+
+
+
+## 建立严格的版本号规范
+
+如果你想做成一个成熟规范的开源项目，那么版本号应当遵从开源项目的规范，对你的迭代也有帮助。
+
+版本号建议为3位数字，比如`1.1.0`，`1.5.1`这样，但是我们经常看到在版本号后面还有一些修饰词，比如`beta`,`release`等等，对于这部分的规范如下：
+
+- alpha：内部测试版本，BUG可能比较多，一般用于开发人员内部使用
+- beta：测试版，BUG相比alpha少一点，但同样不建议用于生产环境，一般用于面向急于使用新功能的群众进行公测，并向开发人员进行反馈
+- rc： release candidate，即将作为正式版发布，BUG较少，正式版之前的最后一个测试版。
+- ga：general availability，首次发行的稳定版，比较稳定，可以用于生产。
+- release/或者干脆啥都不加： 最终释放版，可以面向广大的一般用户
+
+
+
+那对于3位数的版本号的管理策略如下：
+
+- 项目初始版本可以是`1.0.0`
+- 项目进行BUG修正时，最后一位加1，比如`1.0.1`
+- 项目有新特性发布时，中间一位数加1，同时最后一位复位为0，比如`1.1.0`
+- 项目有重大特性发布，同时结构可能不向下兼容时，第一位数字加1，其他位数复位为0，比如`2.0.0`
+
+
+
+## 完善测试用例
+
+我们在做企业级项目的时候，测试用例是必不可少的。同样我们在做开源项目的时候，测试用例其实更为重要，测试用例能检查出你的任何改动是不是对其他功能产生了影响。这从根本上就保证了你的项目质量。
+
+在企业级项目上做测试用例，很多同学可能只是针对于功能点进行做。确保每个接口都能正常运行。但在开源项目中，测试用例可能就变得更加苛刻了。
+
+你不仅要建立对功能点的测试用例，还要考虑到兼容性，边界情况，使用者的环境这些因素。针对于这些情况同样要建立相应的测试用例。
+
+一份完善的测试用例，能够使你的开源项目质量成倍的提高，当然你在这之中所付出的时间精力也是巨大的。
+
+
+
+## 为你的项目建立一份使用文档
+
+首先得清楚，使用文档是给用户阅读的。所以在你的使用文档里面，你应该尽可能的避免阐述你的一些实现细节。
+
+一份好的使用文档应当是能让用户和你的项目快速建立连接的，这里有一些写作文档的建议：
+
+
+
+1）使用主动语态：尽可能使用“你可以这样更改配置”，而避免过多的使用“配置可以这样更改"，这样在阅读体验上会更加容易，反之就会显得你的文档比较拗口。
+
+2）使用简洁明了的句子：写文档不是写小说，不是写诗歌，不需要用过多的修饰词，能让用户明白你想表达的意思即可。
+
+3）保持条理性：你可以再文档中通过写标题，划重点，引链接等方式，把各类信息划分为不同的部分，避免将所有内容都揉在一大段冗长的文字当中。
+
+4）提高可读性：除了文字之外，使用图标也是从多种角度表达的方式之一。
+
+5）注意拼写和语法：必须检查文档中是否有词语的拼写错误和语法错误，尤其是程序的关键词语。
+
+
+
+只要在文档的写作和编辑过程中应用到良好的技巧，你就能和读者建立起沟通和信任，读者会觉得你的项目很专业，印象上也会加分不少。
-- 
Gitee