很多事情不去做，光是靠想象，根本不知道会有那么多弯弯绕绕。所以我们应该“先完成，再完美”，这是一个比较能拿到结果的做事心态。

5月份，因为业务方的一些调整，需求迭代速度慢了下来。给了我空档期来设计一款vscode插件。之所以打算设计一款vscode插件，有很多方面的考量：

• 我自己在开发过程中，发现了一些问题，想要解决
• 空档期是不确定的，为了避免烂尾风险和浪费公司资源的嫌疑，需要控制好开发周期
• 公司有专门的基建部门，需要避免重复建设，做一款没有差异化的产品没有意义

总之，最终我给自己定的选题就是，做一个能够管理我们代码片段的前端基建。我们以前求职，在刷题的时候，经常会开一个对象叫做memory，来给函数结果做缓存。其实开发代码也是可以有“缓存”的，或者说叫“沉淀”，因为很多代码片段其实是类似的，一直去cv再修改，体验并不好。

技术实现有点难，但不是最难

在字节的同事都非常聪明，我相信只要给足够的时间都能做一款好用的基建。但现实就是时间和资源都不是无限的。需要权衡究竟要把mvp做到什么程度，才不是浪费公司的资源，得到一个不错的roi。还有就是技术调研上，需要一定广度，在一开始就选好足够好用的技术。

我最近一直在用vscode自带的Snippets，蛮好用的，但是也有一些不足。而这个不足有些同事觉得也不是什么问题，有些同事觉得有优化空间。至于我，当然是后者。

不足的点包括：

• vscode的变量名补全如果需要进行驼峰转换，或者读取文件信息会很麻烦，需要写正则
• 创建修改代码片段的流程麻烦，需要切出vscode，在一个在线工具上做转换
• 代码片段跟着工作区走，换一个项目没法用，除非是monorepo的项目
• 代码片段不和模块依赖做关联，需要手动插入依赖语句

所以针对上面痛点的解决之道是：

• 能用js写的转换就不要用正则，引入ejs模板引擎
• 创建和修改代码都在vscode内完成，提供一个webview界面来操作
• 可以读取工作区外的代码片段，实现跨项目共享
• 创建、插入代码片段时，增加ast分析步骤，自动处理import语句

最复杂的其实就是各种ast算法，有些还没办法用ast，就得自己去分析代码的规律，用正则来处理。还有就是驾驭vscode的一些接口。好好思考，扩大知识面，多了解其他类似问题的解决思路，最终大概率能做出来。

做产品的数据思维

没有数据，谁知道你的产品究竟做的好不好。也许自己会认可，但其他人不会买账。之前有同事做过前端基建项目，不过非常定制化，没有办法扩大受众。比如你做出来，只有3个人在使用，那其实很难证明这个东西是不是好用的，也很难证明具体的提效幅度有多少。

后面在周会同步的时候+1就觉得没有数据支撑，缺乏说服力。

所以我在产品研发途中就做了数据上报，会统计各个功能的使用频次，方便追踪。

包括现在在掘金写文章也是，有些文章我取悦自己，没有什么阅读量。有些文章是可以得到广泛的共鸣，阅读会比较多。所有东西好不好，看数据。如果数据说一个功能使用频次很高，就可以加大投入，如果一个功能频次很低，可以做调研是不是不好用。

我觉得好用，用户不觉得

我在写这款插件的时候常常惊叹，因为在开发的过程中，我确实能学到不少新的东西，每一次技术突破也都很兴奋。但是对于别人来说，并不在乎你技术具体怎么样，最关心的是好不好用。

功能太多也是一种罪过

国内的软件一般是平台化的，比如支付宝，最原始的功能是支付，但后面有越来越多不相干的功能，甚至可以刷短视频。

国外的比较单一职能，一款软件专注做一件事。

谁好谁坏见仁见智，但应该观察的是，目标用户群体更能接受哪种。

在设计中，我以管理代码片段为核心，设计一个表单：

• 需要定义代码片段的名字，这个可以在编辑器内输入后调用
• 需要定义代码片段的模板
• 需要定义代码片段所依赖的import语句
• 需要设置代码片段应该存储在哪个文件
• 需要定义这个代码片段在哪种语言里可以生效，是js还是ts，还是markdown

不过用户会觉得很复杂。虽然上面的东西是必需品。我觉得很冤枉，减法做到极致了，怎么用户还嫌多？

培养用户心智，不容易

就拿git使用来说，有各种客户端，但我选择使用命令行。因为我认为学习别的客户端也不简单，不如学一个通用的。对我来说，命令行用习惯了，点点点反而麻烦。就算某款客户端真的做的很香，我也不愿意去尝鲜，因为现在其实也不太费事。

用户基本都很懒，不愿意去学习什么新东西。新东西是学不完的，但是生命的长度有限。能完成业务需求，很多人就已经觉得ok了，不会再考虑有什么流程还能够优化。

拿eslint来说，如果不是很多脚手架内置好了，估计很多人也懒得用吧。配置起来我觉得还是麻烦的。又包括webpack，基本配置一次就忘，下次配置还得查资料。但是一般配置一次就ok，修改频次不高，而且缺乏替代品，属于“刚需定位”，所以大家不得不接受。

对于我这款基建来说，就属于“改善定位”，可改可不改，主要看香不香。

和用户对话，了解他们的想法

对新产品来说，想找到一点深度用户，有点难。反正我推广了一个月，身边只有几个同事装。他们装完，基本都会来问我怎么用。我一开始以为他们只是偷懒，问我比较容易。但后面发现也的确没有告诉他们一开始应该怎么用……

插件的版本太高

终于，昨天有个同事告诉我，你这个插件我装不上去。他说要求vscode版本是1.73，而我的是1.58。我一开始说，你可以尝试升级一下vscode……

后面发现不对，如果还得升级vscode那也太麻烦了。是我也不想用了。所以我又匆匆忙忙地把依赖版本降级到1.50。

咋用，也没说呀

昨天那个同事很热心，和我开了会议50分钟，专门问我这个玩意怎么回事。怎么用起来和我宣传的文章不一样。我才意识到，对我来说很熟悉的东西，对别人来说就完全是一个陌生的领域。

我连一个新手指引都没有做好，就把各种核心功能说的天花乱坠，其实没用。我发现有些同事虽然装了我的插件，但是从没用过。都是无效用户。

所以后面得出的结论就是，让我做一个新手指引。

后面他鼓励我，说我这个东西还是能帮他们解决问题，新产品出来的时候都会很多问题，他还会帮我找多点用户来体验，来不断改进。

理解公司售卖内部产品的初衷

数据驱动的前提是有数据。假设内部产品只在内部使用，数据就太少了。没有大量反馈，最终肯定是不好用，缺乏竞争力的。

一个人的智慧太有限了。意识到这一点，就知道第一波用户的作用非常关键。可以帮你的产品提出关键改进建议。让你的产品，更契合用户需求。

如果内部的产品，在外部反响很好，对公司来说那是怎么都不亏，一不小心多了一个盈利业务，自己内部用也更好用。

多体验，慢慢优化

平时我们上网，用app，对于一些好的设计，其实并不在意。觉得那都是理所当然的。直到用到了真的很差的产品才发现，噢，原来之前那个产品蛮不错的。

如果自己不去做一个产品，其实也不会关注产品细节。只有自己做了，才是了解产品思维的开始。

像qq，微信这种产品，很多人骂。但从产品体验上来说，已经相当完善，各种逻辑也很清晰。腾讯去年因为各种原因说自己“只是一家普通公司”，不过他们的产品做的还是非常能打。

之前我买了一台安卓pad，微信是为数不多能给用户提供良好体验的app，其他一些软件甚至都没做适配。qq也适配的很晚。说起来，qq和微信虽然功能相似，但底层体验完全不同。qq最近出了一个降本的NT架构，通过牺牲性能来降低开发成本。但是微信的客户端更接近native开发，使用更顺滑。

还想到有些功能比较复杂的网站，会提供新手教程，让你不断地点击“下一步”。对用户来说还是蛮友好的。我这边本身打算加入这个功能，但实现成本有点高，还是多写几篇飞书文档好了。

做任何事情，都需要有恒心。 我和一个同事（他们的开源项目有1800个stars，算是很不戳了）吐槽，我的插件没人用不开心，他告诉我你才推了没多久。得有耐心。想做好任何一件事情，想要突然爆发都是做梦，基本都得花很长时间的积累。哪怕你的产品一直没变，就放在那，一年之后也会有更多人来用。

期望

最近应该会持续更新这款vscode插件，耐心打磨，目标是DAU破500。站在用户的角度，以人为本，为用户提供更大价值。

FE Snippets+

感兴趣的宝子可以安装试试，看看能不能给你提效。