为什么我要重构自己的开源项目？—— gdenticon 重构日志（一）

为什么我要重构自己的开源项目？—— gdenticon 重构日志（一）

gdenticon 是我用 Go 写的 identicon 生成工具。给它一个用户名、邮箱或者其他字符串，它会生成一张固定的像素头像。同样的输入会得到同样的结果，因此很适合用作用户没有上传头像时的默认图。

项目目前已经能正常使用，既可以作为命令行工具运行，也可以作为 Go 包接进其他项目，还支持 PNG、SVG、JPEG、GIF、BMP 和 TIFF 等格式。

但这个系列并不是为了介绍一个已经完成的项目。恰恰相反，我准备重新整理它。

为什么会有 gdenticon

最初写这个项目，是因为当时能找到的 Go identicon 库总有些地方不太合我的需求。

有的图案密度偏高，生成出来以后格子几乎挤满整个画面；有的输出格式比较受限，只能得到 PNG；还有一些调用步骤偏多，原本只是想生成一张头像，却要写不少准备代码。

这些项目并不是做得不好，只是它们解决的问题和我的需求不完全一样。我想要的是一个更轻量的小工具：生成的图案看着舒服，输出格式可以自由选择，用在命令行里方便，接进其他 Go 项目时也不用绕很多步骤。

既然一直没有找到完全合适的，我就自己写了一个。这就是 gdenticon 最开始的样子。

功能做完了，为什么还要重构

头像生成的功能其实已经实现了，但功能能用，并不代表当前的方案已经足够好。

随着项目一点点补全，我开始发现，有些问题不会直接表现成报错，却会在继续开发时不断增加负担。某些职责放得不够清楚，改一个地方时需要同时顾及其他模块；图案生成还有继续提高效率的空间；输出格式和使用方式越来越多以后，原来的组织方式也需要重新考虑。

这些问题暂时不会阻止程序生成头像，却会决定这个项目以后还能不能轻松地改下去。

我也不想等到代码彻底绕不动了再处理。与其继续在原来的结构上往里塞功能，不如趁项目规模还不算大，把已经发现的问题认真梳理一遍。

所以这次重构不是推倒重写，也不是为了换一套更复杂的架构。已经验证过的功能会保留下来，我更关心的是把各部分的边界理顺，减少没有必要的计算和内存开销，让调用方式保持简单，也让后续增加格式、调整算法和排查问题时少绕一些路。

我希望它最后变成什么样

我对 gdenticon 的期待没有变：它仍然应该是一个小而实用的工具，而不是为了展示技术堆出很多层抽象。

它应该能用很少的代码生成一张头像，既适合在终端里临时使用，也能自然地接进 Web 服务、后台任务或者其他 Go 项目。生成结果要稳定，图案不能过分拥挤，输出格式也不应该被限制在某一种图片上。

在这些基本体验之外，我还希望它的内部结构足够清楚。第一次打开仓库的人，能大致看懂输入是怎样变成头像的；想增加一种格式或者调整图案时，不必先理解整个项目；出现问题时，也能比较快地找到它属于哪一部分。

性能同样是这次重构的一部分，不过我不准备先给它贴上高性能的标签。每一项优化都应该有可以复现的测试作为依据，效果不明显就如实记录，不能只因为代码看起来更巧妙，就默认它一定更快。

这次把过程也记录下来

以前写自己的小项目，注意力通常都放在尽快把功能做出来。至于为什么这样设计、试过哪些方案、哪些地方后来又推翻了，当时觉得自己肯定记得，过一段时间再回头看，往往已经说不清了。

这次我想把重构过程一起留下来。除了记录最后采用的方案，也会写清楚它解决了什么问题、为什么没有选择其他做法，以及实际测试结果是不是符合预期。

后面的文章会逐步进入项目内部，包括程序入口与错误处理、生成和输出的拆分、头像图案的生成方式、性能测试，以及重构过程中遇到的其他问题。每一篇只解决一个主要问题，不急着一次把整个项目讲完。

一个人写代码难免有盲区。如果你发现代码里的不足，或者有更合适的思路，欢迎随时留言交流。

项目地址：

• GitHub：hourinX/gdenticon
• Gitee：hourinX/gdenticon

下一篇

下一篇会从项目的整体结构开始，看看一次头像生成请求从哪里进入，经过哪些部分，最后又是怎样变成图片的。