为什么我选择自建所有工具

> “如果你想让事情按你的方式运行，最好自己动手。” —— 某位老兄

大家好，今天想跟你们聊聊我为什么一直坚持自己动手打造所有工具。不是什么高大上的理由，更多是出于一种“自己动手，丰衣足食”的执念。下面的几段文字，算是我这几年折腾的碎碎念，希望能给还在犹豫要不要自己造轮子的朋友一点参考。

1. 掌控力与自由度

首先，最直接的感受就是掌控感。当你使用别人的工具时，总是会有这样那样的限制：功能被阉割、接口要付费、升级要等官方排期。更有时候，某个小需求明明可以实现，却因为官方没有开放接口而被卡住。

我自己写的脚本或者小工具，完全可以按自己的节奏迭代。比如我常用的 Markdown 转 HTML 的脚本，最开始只是把标题和段落转成对应的标签，后来陆陆续续加入了代码高亮、数学公式、目录生成等功能。换成商业软件，可能要等好几个月才更新一次，而我自己只需要几行代码就能搞定。

#!/usr/bin/env bash
simple-md2html: 将当前目录下的 *.md 转成 *.html
for file in *.md; do
base="${file%.md}"
pandoc "$file" -o "$base.html" \
--standalone \
--self-contained \
--highlight-style=pygments
done

这种“想加就加、想改就改”的自由度，是自建工具最吸引我的地方。

2. 学习与成长的机会

第二个原因可能有点“理想主义”，但对我而言非常重要：自建工具是最佳的学习途径。每当我需要解决一个痛点，就会去调研现有的实现方案，然后挑选合适的技术栈自己动手实现。这个过程往往涉及：

- 新技术调研：比如去年我想做一个本地化的搜索工具，于是顺便学了 Elasticsearch 的基本原理和倒排索引。

- 性能调优：工具跑起来慢了，得去分析 profiling 结果，学会用 Cython、Numba 或者 Go 优化。

- 代码质量：为了以后好维护，开始学习单元测试、CI/CD、代码审查等最佳实践。

说白了，每次“造轮子”都像是给自己安排了一次实战训练。相比之下，直接下载现成的库或服务，往往只能学到“怎么用”，而很难深入到“为什么这么设计”。

3. 定制化满足真实需求

第三个理由是“真实需求”。很多商业工具或者开源项目，都是为了满足“通用”场景设计的，往往会留下“不太适合我的地方”。我自己做的东西，完全可以针对自己的业务场景进行深度定制。

举个小例子：我在团队内部需要一个 每日站会提醒，但市面上的日程管理工具要么界面太重，要么不支持自定义的提醒模板。于是我用 Python 写了一个命令行小工具：

#!/usr/bin/env python3
import datetime, subprocess, sys

def daily_standup():
now = datetime.datetime.now()
# 设定每天上午10点提醒
if now.hour == 10 and now.minute == 0:
subprocess.run(['notify-send', '站会提醒', '今天的议题：\n1. 昨天完成\n2. 今天计划\n3. 阻碍'])
else:
print('还没到站会时间')

if __name__ == '__main__':
daily_standup()

这个脚本只用了不到 30 行代码，却完美贴合我们团队的节奏。若是换成大厂的协作平台，光是配置权限、挑选插件就要耗费大半天。

4. 成本与长期收益

很多人会担心自建工具的 成本——时间、人力、维护费用。的确，短期内自己写东西要比直接买或用开源方案“贵”。但如果把时间线拉长到一年、三年，甚至五年，情况往往会逆转。

- 一次性投入，长期免费：很多 SaaS 服务是按月收费的，长期累积下来费用相当可观。自建工具只需要付服务器或云资源的费用，往往比订阅制便宜不少。

- 可复用、可迁移：自己写的代码可以随时迁移到别的平台，不会被供应商锁定。比如我把原来在 AWS Lambda 上的自动备份脚本，改到自建的 Docker 容器里，只需要改几行配置。

- 故障快速定位：遇到问题时，自己写的工具可以立刻查看源码、打印调试信息，而商业软件只能提交工单、等客服回复。

这也是我在决定是否自建时，会先问自己的几个问题：“这功能会长期使用吗？”、“现有的解决方案成本是否过高？”、“我对这块技术是否有兴趣？” 只要答案偏向“是”，我就会动手。

5. 社区与自我提升

最后一点，可能有点“情怀”，但对我影响很大：自建工具让我更容易融入社区。当我把自己做的小工具开源到 GitHub，或者在技术论坛上分享实现细节，往往会收到其他开发者的反馈、Issue、PR。这种“大家一起打磨”的过程，既能提升代码质量，又能结识志同道合的朋友。

更重要的是，分享出去之后，别人的使用场景会给我带来新的需求和灵感。比如我之前写的一个 CLI 日志聚合工具，最初只是给自己用，结果有网友提了“支持 JSON 输出”的需求，我顺势加入了该功能，后来这个功能也成为我自己工作流中必不可少的一环。

总结

说了这么多，总结下来，我选择自建所有工具，主要是因为：

1. 掌控力与自由度——想改就改，想加就加。

2. 学习与成长的机会——每一次实现都是一次技术实战。

3. 定制化满足真实需求——完全贴合自己的业务场景。

4. 成本与长期收益——一次性投入，长期省订阅费。

5. 社区与自我提升——开源分享，获得反馈，共同进步。

当然，也不是所有工具都值得自己造。如果是那种已经非常成熟、几乎没有定制需求、并且成本可接受的商业方案，我还是会直接使用。关键在于 “是否值得” 这把尺子——只要我觉得这套工具能满足我的长期需求、提升我的技术栈、并且成本可控，我就会毫不犹豫地自己动手。

好了，以上就是我的碎碎念，希望对你们有所启发。如果你们也有类似的经历或者想法，欢迎在评论区一起聊聊，咱们互相交流、互相学习。祝大家“造轮子”愉快！