物理学家理查德·费曼说过一句被无数工程师奉为圭臬的话：“我不能创造的，我就不理解。”这句话横跨多个领域，只要对“创造”的定义稍微灵活一点，它就始终成立。作者坦言，自己真正擅长的一切，都要归功于这个原则。很多人会劝你不要重新发明轮子，但作者的观点正好相反：你应该亲手造一个轮子，因为这比阅读一千本关于轮子的书更能教会你它们的工作原理。
站在2025年这个时间点，编写软件的美感和技艺正在被侵蚀。AI 威胁着要替代我们——或者至少替代我们手艺中最令人愉悦的部分——而软件开发本身也在被日益商品化、量化、打包和工业化。整个领域需要更多单纯的快乐。作者发现，编写“玩具程序”是一个极好的方式，能让人重新记起当初为什么开始接触计算机。
玩具程序遵循二八法则：20%的工作量，实现80%的功能。重点不在于构建生产级软件——尽管确实有一些最好的生产软件最初也是以玩具形态诞生的。在实现上，要极力避免过度工程化，只编写为达成目标所必需的代码。让每个代码路径都处于崩溃状态，直到不实现它就无法推进时再去动手。你会惊讶地发现，那些你曾经认为极其困难的软件，其玩具版本的构建竟然如此简单。
这里就引出了一个常见的对立观点：既然已经有了成熟的库和框架，为什么还要花时间去造轮子？工业化的软件开发强调效率、可维护性和团队协作，重复造轮子往往被视为浪费资源。尤其在AI辅助编程兴起的今天，开发者被鼓励专注在业务逻辑上，底层细节留给别人。这种思路在商业环境中几乎无可反驳。
但作者的亲身经历提供了一个反例。他在过去15年里持续编写玩具程序，发现自己从这些项目中获得的一些冷门知识点，竟然频繁在日常工作中发挥了巨大价值——要么在追踪工具或库的某个问题时给了自己先机，要么在错误发生之前就识别出了迹象。理解塑造软件形态的各种约束，对于用好软件至关重要，而没有什么方式比亲自撞上这些约束更能帮助你洞察它们。在这个过程中，你还可能摸索出一些新颖的解决方案。
那么，到底该听谁的？作者的判断是：二者并非不可调和。工作中遵从工业化规范，效率优先，不无谓重造轮子；但在业余时间里，刻意去写那些只求功能不求完美的玩具程序，是一种高效的学习投资。它不是为了交付，而是为了理解。80%的功能往往已足够让你了解这个领域的内核，而为此付出的时间，可能只需要每天一两个小时，持续数周而已。
作者列出了一些他尝试过的玩具程序，并附上难度和所需时间的估算。这些估算基于你已经熟悉至少一门通用编程语言，并且像他一样每天只有一两个小时可用来写代码的假设。第一个例子是正则表达式引擎：能够读取一个 POSIX 风格的正则程序，并识别出与之匹配的字符串。别看正则语法简单，它的表达能力却极为惊人，而编写一个合格的正则引擎会让你在理解和使用这门语言时达到一个全新层次。第二个例子是多重引导兼容的操作系统内核：包含简单的命令行界面、键盘/鼠标驱动、ANSI 转义序列支持、内存管理器、调度器等。更具挑战性的扩展还包括编写内存中的文件系统、用户模式与进程隔离、加载 ELF 可执行文件，以及进一步的底层支持。
掌握一件事物最可靠的路，往往就是从头把它做出来。如果觉得某些技术晦涩难懂，不妨给自己一个玩具项目：用二八法则剥离掉所有非核心的部分，只保留最关键的那20%实现。你得到的不仅是理解，还有属于创造者的真正快乐。
热门跟贴