前言我开发的开源文档工具在github上已经升至5300+star，受到一些开发者的欢迎。所以我想写一篇文章来和大家分享我在整个创作过程中使用的技巧和相关技巧。任务管理，无论是做自己规划的产品功能，还是用户反馈的bug，最终都需要将这些点提炼成一个个的小任务，并串联执行（毕竟我是一个人）。在这一点上，我主要使用团队看板进行任务管理。团队看板工具有很多，随便搜一下。我个人使用tower.im看板。我创建了五个列表，分别是“正在做”、“待办-高优先级”、“待办-低优先级”、“待定”和“遗留问题”，我很擅长这样分类。首先，它有优先级，确保最重要的事情先做。其次它有状态管理，方便我随时打断某项任务，过一会再回来继续任务。同时，它也可以处理新的任务——比如有新的需求进来，我先把它放在“pending”，等我有空再分配到其他列表。最后，它还有一个“剩余问题”列表，让我可以快速推进到下一个任务，而不会在某个“难题”上停留太久。使用Linux或者MAC进行本地开发，在开发、搭建测试环境等方面都会非常方便，对于开发者的方便是毋庸置疑的。但是电脑有时候需要玩游戏，需要安装一些专业的大型软件。从兼容性和广泛性来看，我个人还是使用windows系统。在win上，我使用Vagrant+virtualbox的组合。Vagrant是一套工具，帮助大家使用virtualbox在win系统上快速搭建虚拟机，方便使用linux或者MAC（比如我上架苹果app需要MAC虚拟机）).关于这一点，可以参考我几年前写的一篇教程：blog.star7th.com/2015/06/1538.html代码管理我使用git作为代码版本管理工具，使用tortoisegit进行可视化操作。说说我是怎么维护官网在线版showdoc和开源版showdoc的。我在我的服务器上安装了一个私有版本的gogs作为一个私有的git管理平台。功能开发好后，我会推送到github。官网版和开源版本来是同一个仓库的不同分支。它们之间的区别（尤其是后端代码的区别）越来越大，所以我干脆把它们分成了两个不同的仓库。做开发的时候，我一般都是在官网版本上做开发和测试验证，然后用tortoisegit的代码修改差异比较功能，将功能迁移到开源版本。谈谈分行经营策略。我至少创建了两个分支-master和development。新的功能会在开发分支实现，验证后合并到主分支。使用开发分支时也有技巧。比如一个大的功能可以在开发分支的基础上再开一个新的分支来做。比如我今天要做功能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框架。比如showdoc我选择的是ElementUI，而runapi用的是museUI（runapi是辅助showdoc的在线api测试工具）。showdoc使用的编辑器是editor.md，这是几年前的产品了。虽然它的代码组织可能有点落后，而且原作者似乎有放弃维护的倾向。但是我觉得它功能强大而且简单美观，所以花时间把它封装成一个vue组件并修改了它的源码来增加安全性。我使用vue组件vuedraggable进行项目拖拽和页面排序，还是蛮好用的。如果以后有拖拽的需求，估计还是会用。图标设计方面，可以使用UI框架自带的字体图标，也可以使用阿里妈妈的矢量图标库。或者使用Iconion自己设计图标。这里我强调Iconion。这个工具可以非常容易和快速地使用一些预定义的图案和背景来组合成一个快速可用的产品图标。Showdc的产品图标就是这样制作的，可以快速省时的达到专业的效果。如果以后想把产品做大，可以考虑请设计师来设计。但是在项目初期，Iconion就足够了。这里要提一下前端技能的重要性。虽然UI框架和相应的工具可以帮你节省很多时间。但是如果要做出好的产品体验，涉及到的UI和交互可能就超出了框架的范围。因此，我必须学会使用原生css，与js交互，封装组件。而且，前端技能和下面要说的app的多端开发也有帮助。App多端开发关于移动App产品的原型设计，我强烈推荐使用“墨刀”进行简单的原型规划。有了可视化原型，真的可以节省很多脑力，让你在开发阶段就专注于代码，而不用写代码，然后回过头来思考下一步要做什么功能。这样的来回切换相当拖延效率。我使用uniapp进行app开发，使用html5等前端技术将代码打包成手机本地app，包括安卓app，苹果app，甚至小程序。这项技术已经存在了几年，但性能一直不温不火。2019年，我看到这方面的发展还是可以的。于是萌生了做一个showdocapp的想法。不过由于showdoc专注于pcweb端，手机端只是起辅助作用，所以没有做的很仔细。大概简化web版，复用一些组件，重写前端，然后上线。顺便说一句，我做的比较精致的app是TimeTreeHole（blog.star7th.com/2019/09/2380.html），这个app的UI花了一点心思。如果让我评价这种hybridapp和nativeapp，我会说nativeapp绝对是最好的。只是出于成本和人力的考虑，这种h5技术可以用于一些对交互体验要求不高的显示产品。如果你正处于验证市场的阶段，你可以利用类似的技术快速做出一个可用的产品。另外，再说说苹果的app上架的问题。我用虚拟机安装了一个黑苹果系统，然后安装了相应的工具，把app上传到AppleStore。可以搜索如何开通苹果开发者账号，如何在虚拟机上安装苹果系统。用户反馈和社区运营一开始，用户反馈消耗了我很多精力。敢当客服。然后我开始做一些改变，基本上把自己从反馈中移除了。首先，我把官网在线版和开源版的反馈分开了。开源版的反馈统一到github（gitbug的使用门槛可以过滤掉一些很新手，避免新手问题），在线版的反馈统一发到邮箱。如果有需要修改的功能或者bug，我会先记录在teamboard上。对于一些常见的问题，我整理了文档和一些固定的回复条款。另外，我还开了三个QQ群，供showdoc用户自己交流。但是有一点我要提的是，不要在qq群里问的每一个问题都一一回复，那样会让人抓狂的。于是我改了群公告，重写了群定位，把qq群定位为用户自己交流的地方。让热心网友解答新手在使用showdoc时遇到的问题。我只需要偶尔看看它。需要官方支持或者让用户通过github或者email渠道。不过值得一提的是，我的操作思路并不适合所有团队。我人手有限，优先考虑效率，所以我过滤掉了很多不必要的反馈。如果人手充足，我建议多花点时间帮助用户解决问题，这样不仅能扩大用户数量，还能提高产品口碑。
