我是如何把github开源项目作到5300+ star的

前言

我开发的开源文档工具在github上上升到了5300+的star ，受到了部分开发者的欢迎。因而便想写文章与你们分享一下我在整个创做过程当中所用到的技术以及相关技能。

任务管理

不管是作本身规划的产品功能，仍是作用户反馈过来的bug，最终都须要把这些点细化成一个个单独的小任务，串联执行（毕竟本身是单我的力）。在这点上，我主要是利用团队看板来实现个人任务管理。团队看板工具备好多，搜索一下就好，我我的目前在用tower.im

看板上我新建五个清单，分别是“在作”、“要作-高优先级”、“要作-低优先级”、“待定”、“遗留问题”，我这样分类是有技巧的。首先，它有优先级划分，保证先作重要的事。其次，它有状态管理，方便我随时中断某个任务，过一段时间再回来继续任务。同时，它也能应对新任务——好比说新需求进来，我先放在“待定”，等有空了再分配到其余清单去。最后，它还有“遗留问题”清单，可让我不在某个“疑难杂症”上卡住太多时间，快速推动下一个任务。

本地开发

用Linux或者MAC会很是方便开发、搭建测试环境等，对开发者的方即是毋庸置疑的。可是电脑有时候须要玩游戏，须要装一些专业大型软件。从兼容性和普遍性的角度来考虑，我我的仍是使用windows系统。在win上，我使用的是Vagrant + virtualbox这个组合。Vagrant是一套工具，帮助你快速在win系统上，利用virtualbox搭建起虚拟机，从而方便使用linux或者MAC(好比上架苹果app的时候我须要MAC虚拟机)。关于这点，能够参考我几年前写的一篇教程：blog.star7th.com/2015/06/1538.html

代码管理

我用git做为代码版本管理工具，同时使用tortoisegit进行可视化操做。
说一下我是怎么维护官网在线版showdoc和开源版showdoc的。我在本身的服务器安装一个私有版的gogs做为私有git管理平台。功能开发好了，我再推送到github上去。官网版和开源版一开始是同一个仓库里的不一样分支。后面它们的差别（尤为是后端代码的差别）愈来愈大，因此我干脆把它们分红两个不一样的仓库了。作开发的时候，我通常是如今官网版上作开发以及测试验证，而后再用tortoisegit的代码修改差别比较功能，把功能迁移到开源版去。

说一下分支管理策略。我至少创建两个分支——主分支和开发分支。新功能会在开发分支作，验证好了再合并到主分支来。用开发分支的时候也有技巧。好比说，一个大的功能能够基于开发分支再新开一个分支去作。例如我今天想作A功能，那就在A分支上操做。可是A功能遇到瓶颈了，这会儿我暂时没精力去找bug，因此此时我能够再基于开发分支开启B分支，继续作B功能。这很重要，由于在人力有限的状况下，我作什么事情都是串联的，同一时刻只能作一件事。这样的策略有利于保证本身随时中断、随时上手任务，灵活地安排不一样的时间去处理容易的或者棘手的问题。这个过程也须要配合上面说到的团队看板使用。中断前要记录好进度，方便本身随时恢复工做。

shell自动化脚本

我为showdo写了三个shell自动化脚本。其做用分别是自动化部署showdoc，自动生成api文档到showdoc，自动生成数据字典到showdoc。之因此选择shell而不是其余脚本语言（如python），是由于shell基本能够运行在绝大部分linux上，部分运行到win上（须要安装工具），兼容性超好，依赖很是少。根据反馈，受到的好评比负面评论多得多。自动化脚本大大节省了使用者安装环境的麻烦，下降了showdoc的使用门槛。showdoc大部分的用户不是php开发者，要他们安装php环境仍是挺折腾的。有了一键脚本，他们用得方便，我也省心，不须要在解决新手反馈上花太多功夫。这个方法是具备普适性的，而且语言无关（由于一键脚本使用docker跑服务）。是能够大量应用到开源项目中，很是有利于开源项目的代码分发。

顺便强调一下，作web应用开发的人，尤为须要克服一下对shell脚本的疏远感。我之前以web开发为主的时候就会潜意识地疏远shell。在腾讯的时候向另外一个技术栈的同事请教了下，发现其实仍是蛮简单的。只是由于本身过去心理上的疏远感致使本身没想过要去写shell。跨过这个心理槛，就会扩展自身的能力边界，写起来跟其余语言没有太多区别，仅仅是须要多搜索查询下语法而已。

后端开发

多是由于showdoc仅是一个小产品，涉及到的后台逻辑并不复杂，因此我在开发后端花的时间很少，基本上都是CRUD，对数据库进行增删改查操做。须要多动点脑力的地方在于团队管理功能，新建多几张数据表联合实现精细化权限控制。

showdoc后端主要采用的是国产框架thinkPHP。这个框架有好也有很差。很差的地方在于它的框架约定、生态共享比较通常，好的地方在于它能够快速撸出一个东西来，并且兼容性还能够。这是四年前我刚开发showdoc时的决定，后来也懒得换框架重写了，因此沿用至今。技术是相对落后了一些，可是也胜在兼容性好，能够兼容老的php环境和一些老的服务器。这个仍是挺重要的，由于showdoc是开发辅助性质的工具，协助写文档。兼容性越好就越容易被各类各样的群体接受。我的以为这一点比用各类先进技术要更实用一些。固然了，若是是如今新开发其余项目，我应该会使用laravel，或者NodeJS写的eggjs。

前端开发和UI

我在前端开发上花费的时间比后端开发时间多不少。多是由于这是个体验型产品，须要把前端体验作好。起步一个产品的前端页面时候，我建议必定要选好一个UI框架。好比我选择的是ElementUI作showdoc，而runapi则使用museUI（runapi是辅助showdoc用的一个在线api测试工具）。

showdoc用的编辑器是editor.md，是几年前的产品。虽说它代码组织方式可能有点落后，且原做者彷佛有放弃维护的趋势。但我以为它功能强大且简洁美观，因此我花了时间将它封装成了vue组件，而且修改其源码增长了安全性。

项目拖拽和页面排序我用的是vue组件vuedraggable，还蛮好用的。之后有拖拽的需求我估计仍是用它。

图标设计方面，可使用UI框架内置的字体图标，也能够用阿里妈妈的矢量图标库。或者本身使用Iconion进行图标设计。这里我强调一下Iconion。这个工具能够很是简单快捷地使用一些预约的图案和背景，组合成一个快速可用的产品图标。showdc的产品图标就是这样制做的，快速省时地作到媲美专业的效果。若是之后把产品作大了，能够考虑请设计师设计。但在项目前期，用Iconion就够了。

在这里要提一下前端技能的重要性。虽说UI框架以及相应的工具可以帮助你节省不少时间。但若是想作好一个产品的体验，那么其涉及到的UI和交互可能超出框架自带的范围。所以本身必须学会使用原生css，会js交互，会封装组件。并且，前端技能跟下面要说的app多端开发也有帮助。

app多端开发

关于移动app产品原型设计，我很建议使用“墨刀”来作简单的原型规划。有了一个可视化的原型，真的能节省不少大脑时间，让你在开发阶段的时候能够专一代码，而不须要写一下代码，又回头思考下一步作什么功能，这样的来回切换至关耽误效率。

app开发我用的是uniapp，使用html5等前端技术把代码封装成手机本地app，包括安卓app、苹果app，甚至小程序。这种技术几年前就有了，可是性能一直不温不火。2019年的时候我看到了这块发展得仍是能够的。因此就产生了作showdoc app端的想法。不过因为showdoc重在pc web端，手机只是起到辅助做用，因此我没有很精心去作。大概把web版简化一下，复用一些组件，重写下前端，而后就上线了。顺便说一下，我作得比较精细化的app是时光树洞（blog.star7th.com/2019/09/2380.html) ，这款app的UI就花了点心思。

若是要让我评价这种混合型app和原生app，我会说，确定原生app最好。只是出于成本和人力的考虑，对一些展现型的、交互体验要求不那么高的产品，能够采用这种h5技术处理。你们若是在验证市场阶段，能够采用相似技术快速作一个可用产品出来。

此外说一下苹果app上架的问题。我是利用虚拟机安装了一个黑苹果系统，而后装相应工具，把app上传到苹果商店去。关于如何开通苹果开发者帐号，如何在虚拟机安装苹果系统，这个你能够自行搜索。

用户反馈和社区运营

一开始，用户反馈消耗了我很多精力。敢情本身成为一个客服了。后来我开始作了一些改变，基本把本身从这些反馈中抽身出来了。

首先我分开了官网在线版和开源版的反馈，开源版的反馈统一到github（gitbug的使用门槛能过滤掉一些很是新的新手，避免新手问题），在线版的反馈统一发邮箱。有功能或者bug要改，我先记在团队看板。而对于一些常见问题，我整理好了文档，和一些固定的回复术语。另外我也开了三个qq群，供showdoc使用者自身交流。不过我要提的一点是，千万别试图回答qq群里提的每个问题，会把人逼疯的。因此我更改了群公告，改写了群定位，将qq群定位为用户自行交流的地方。让热心用户去回答新手在使用showdoc时遇到的问题。而我则只须要很偶尔看一下。须要官方的支持仍是让用户走github或者邮件通道。

不过值得一提的是，我这种运营思路是不适合全部团队的。我是人力有限，效率优先，因此过滤了不少不太必要的反馈。假如说有很足够的人力，我倒建议能够多花时间帮助用户解决问题，既扩大用户量，又提升产品口碑。