糟糕，我正在构建一个框架

在之前的文章中，我讨论了一个正在进行的项目，旨在提升我作品集的复杂度。经过几天的思考和原型设计，我决定使用 Rust 来实现这个应用程序，并通过 WebAssembly 将其渲染到 HTML5 Canvas 上。

我以之前的实验为例，用一些可点击的按钮做了一个原型，但它很脆弱。每个区域都有自己独立的检测和处理逻辑——调整或修改起来非常麻烦。考虑到血压测量，我决定在继续开发之前，先对画布进行更好的抽象。

又过了两天，我已经基本完成了 UI 框架的框架设计。我已经将渲染逻辑与游戏逻辑完全分离，甚至可以将其拆分成一个独立的外部库。该库提供了一系列特性，你可以为游戏的各种类型实现这些特性，它们可以完整地处理画布元素的创建、应用挂载以及点击事件的处理。你只需要插入可绘制组件，它就会自动帮你组织布局。

为什么这种情况并非总是发生？或者说，这种情况总是发生吗？任何足够大的项目最终都会出现像这样高度解耦的逻辑模块吗？我从零开始编写代码是否意味着我应该使用一个“真正的”框架？对于这个项目我并不在意，它纯粹是一次学习经历，所以我不介意额外的工作量，但在“真正的”项目中，这种情况会让你觉得有问题吗？在探索生态系统之前，你会允许自己从零开始实现多少这样的功能？额外的控制固然很好，但很耗时，而且这个问题可以通过众包来解决。

此外，如果你在编写应用程序的过程中自己搭建了一个框架，是什么促使你决定是否将其拆分并通用化，供公众使用呢？我不知道世界是否需要另一个自制的 Canvas UI 框架，但既然我已经写了一个，也许值得把它分享出来。话虽如此，这也会带来一系列与本项目无关的耗时任务。

照片由 Chris Abney 拍摄，来自 Unsplash