记自己第一次把想法做到闭环的经历

记自己第一次把想法做到闭环的经历 为何开始 我一直很喜欢玩MC, 特别是无政府服务器。为了防止他人寻找我在2b2t.xin服务器中的基地, 我把它建到了很远。但这也导致了一个问题: 我很难回去。 于是我在我的服务器上用一个叫HMC的启动器挂了一个无头客户端并自己写了一个fabric mod来响应我私...
记自己第一次把想法做到闭环的经历
记自己第一次把想法做到闭环的经历

记自己第一次把想法做到闭环的经历

为何开始

我一直很喜欢玩MC, 特别是无政府服务器。为了防止他人寻找我在2b2t.xin服务器中的基地, 我把它建到了很远。但这也导致了一个问题: 我很难回去。

于是我在我的服务器上用一个叫HMC的启动器挂了一个无头客户端并自己写了一个fabric mod来响应我私聊中的触发滞留珍珠。我觉得这太不优雅了, 如此简单的任务竟然要跑一整个客户端, 这太浪费了。于是我向纯发包的机器人客户端开始了研究。

我当时找到了MCC, 但是我觉得这还是不够优雅, 它看起来太重了(其实主要是不会C#)。这些想法伴随着对想要有一个自己写的软件的渴望, 我开始了xinbot的开发

第一次拙劣的尝试

xinbot一开始其实并不叫xinbot, 它根本没有名字。当时我开发了它的第一个版本, 一个只能挂机的机器人, 代码写的非常屎, 本来只打算私用的, 后来在某个qq联系我的神秘人(我忘了)的要求下, 为给他添加了可以在服务器中发送宣传消息的功能。当然当时没有开源, 但是我把源码发给了那个神秘人。神秘人把它在我不知情的情况下把它开源了竟然还有几个star, 我也是无语。

第一次重构

我觉得这个项目不该只满足于此, 当时我接触到了自由软件运动和开源精神, 我觉得我的软件也应该是一个自由软件。我开始重构这个项目, 借鉴bukkit, 我给他设计了插件的概念, 在改良后, 我做出了这个项目中我认为最正确, 最符合我架构审美的设计: Plugin is all you need.插件在我设计的架构中处于绝对的主导地位, xinbot内核部分所做的一切都是在管理插件和为插件提供接口。它刚开始内置了一个插件来处理登录, 自动排队进服务器等不那么objective的工作。我认为功能的扩展就是插件的增加, 插件应该来处理那些subjective的工作。

第二次重构

后来上高中开始在安卓内核圈混了, KernelSU的元模块设计让我觉得我可以再把架构再精进一下, 于是我引入了元插件的概念,开启了2.x.x的大版本。它代替了原有架构中那个内置插件的角色, 允许用一个外置的插件来决定服务器的连接地址并处理登录, 这让xinbot能够支持更多服务器并且让本体中那些subject的部分独立出来成为新的项目并让本体更纯净。

插件生态

至此, 整个项目已经完全符合了我最开始对项目本体的期待, 符合了我对项目架构的审美, 也真正把一个玩具变成了工程。但这个项目最重要的注定不是本体, 而是插件, 我认为插件生态才是在这套架构之下最重要的部分。因此, 我开发了很多的插件, 比如处理移动和地形的MovementSync。此外, 第二次的重构让它不止局限在2b2t.xin这一个小圈子中, 而是可以在所有同类型的服务器使用。

何时结束

距离它的第一个快照版本发布已经过去500多天了。对这个项目, 我认为对本体的任何功能性修改已经没有意义, 要做的只是跟进依赖和修复安全问题。接下来, 这个框架将会适配更多的服务器, 有更多由插件增加的功能, 有更多喜欢这种设计的用户。我做的这些, 让它的生命永远不会结束。

1 个帖子 - 1 位参与者

阅读完整话题

来源: LinuxDo 最新话题查看原文