如何做一个比较失败的工具

17年9月底,那时我刚刚结束在谷歌的实习回到北大,在BBS上看到有个CMU实验室找人做项目的帖子,感觉自己正好也空就联系了一下。于是遇到了S学姐和C老师,聊了一下之后他们希望我做一个针对GitHub Fork的工具,没想太多就开始做了。接下来的细节我就不展开了,无非就是借此开创Startup出任CEO赢取白富美走上人生巅峰做得平平无奇,没有丝毫波澜。

简单介绍一下背景,工具目前以一个web server的形式存在,目标简单来说就是方便给项目维护者浏览并管理项目中的Fork(如,这些Fork中可能存在有用的feature,但是并没有合并进主分支),细节上涉及到对于GitHub数据的采集、处理,还有就是一些用户交互。

那么如何把这个东西做得比较失败呢?我得到了如下一些经验,拿出来和大家分享一下。

数据

  1. 没有认识到GitHub API的rate limit,发现之后没有采用合理的方式去解决它。注: GitHub限制单个用户每小时只能request 5000次API,并且短时间大量的request会被暂封。
  2. 对于数据的处理上,没有考虑完善,导致数据格式和数据量过大产生的一系列问题
  3. 没有考虑http, API requests的不稳定性
  4. 在对网页的爬取中,由于GitHub前端本身的显示方式有区别,需要case by case地解决一些,同时一开始爬虫设计中在html中定位某类元素的代码会随着GitHub本身前端的改版而不适用
  5. 多进程环境下出现的各种问题,如:NLP模块中nltk库对多进程支持存在问题;Python爬虫进程假死等

用户

虽然我们前期有一些用户调研一定程度上表明该项目存在一定的意义,但是最终也没有太多用户使用这个工具,说明其中存在着问题,举例来说,我们在后来做得差不多之后,和一个开源项目维护者聊关于这个工具,他提到用户fork之后可能会开很多分支进行自己的开发,而我们一开始想当然地就将fork和upstream(也就是fork来源的主项目)的各自主分支进行比较,这个就是没有抓住用户需求的典型例子。做产品的时候,我们往往会想我用上什么技术可以给用户什么,但往往忽视了用户想要什么。

前端

由于工具最后定位为一个web server,所以花时间在前端上做了很多工作。对于之前对前端一无所知,踩了一些坑。采用了flask+jinja2的方式后发现一次性将所有数据加载比较慢,随之在前端使用javascript/jquery来进行异步传输,在代码上修修补补比较多。

总结

  1. 要去善于使用现用工具/轮子,去做足够的技术调研
  2. 要谨慎地对待数据的采集和处理
  3. 要考虑清楚用户需求,要去做足够的用户调研
  4. 要多写代码

后记

为什么说比较失败而不是完全失败呢?因为这个工具毕竟还是发表了一篇poster,同时启发了我们之后的研究工作。

发表评论

电子邮件地址不会被公开。 必填项已用*标注