做一个小工具的正确姿势

记录一次从想法到落地的完整过程,包括中间推翻重做的那部分。

年初的时候想做一个很小的东西:把每天随手记的碎片整理成可检索的条目。

需求听起来简单,做起来才发现坑很多。这篇记录一下过程,包括中间走错的路。

第一版:想太多

第一版的设想是这样的:

  • 支持标签系统,标签之间可以有层级
  • 自动提取关键词,做语义关联
  • 支持多种输入方式:文字、语音、图片
  • 有统计面板,展示记录习惯

写了两周,一个功能都没做完。因为每个功能往下挖都有更细的需求,标签要不要支持同义词?关键词提取用什么算法?语音转文字准确率不够怎么办?

问题在于我把一个”整理碎片”的需求,做成了一个知识管理系统。

砍掉一半

停了两周之后重新想:我实际需要什么?

回想了一下自己的真实使用场景——绝大部分时候,我只是想快速记下来,之后能搜到。就这么简单。

于是第二版砍成了三条:

  1. 输入框,回车保存
  2. 全文搜索
  3. 本地文件存储

代码量不到第一版的五分之一,三天写完了。

关键决定

有几个决定回头看是对的:

不做数据库。 直接用纯文本文件,一天一个。好处是随时能打开看,不会因为程序坏了就读不了数据。

不做云同步。 用系统自带的文件夹同步就够了,自己实现同步是给自己找麻烦。

不做备份功能。 文件在磁盘上,备份是系统的事,不该由这个工具负责。

现在的样子

已经用了几个月,每天用几次。真正让我满意的不是功能,而是它真的很轻——打开、输入、关闭,两三秒的事。

后来加过一个功能:给条目打星标。加了之后发现自己从来不用,又删掉了。

判断一个功能要不要加,标准不是”有没有用”,而是”不用它会不会难受”。

这个工具大概会一直这么简单下去。