最近做的一些事情

自从年初的时候发了关于fastbin的文章之后就没更新专栏了。

这段时间在项目中实践了fastbin和相关的开发思路，觉得有必要写一篇文章重新跟大家实践下来的一些经验，对之前分享内容做个补充。

首先需要梳理一下年初到现在我在开发流程上的几个观念改变：

1. 尽量不要使用DSL，DSL的问题是功能和特性隐含在语法中，需要熟记语法并提供完善的文档才能用起来，无形之中就增加了开发者的心智负担。其次是DSL从编码到输出结果通常不是线性的，无法增量开发也无法即时调试，一些开发工具可以用可视化界面替代掉DSL。

2. 功能模块应该尽量内聚，项目以功能模块的视角来组织，这样可以在开发的时候少一些目录跳转和搜寻文件的动作，可以让开发过程更流畅。

基于以上思路转变，我制作了fastbin这个工具的原型，并结合到了项目中。

实践下来发现有几个问题：

1. fastbin自身代码太复杂，当加完客户端代码生成所需的逻辑之后，发现整个工具很难再扩展和修改。

2. fastbin和link配合使用的时候很不顺畅，结合部分的代码弯弯绕绕的。

fastbin代码复杂的主要原因是基于AST的类型分析太过复杂，如果是用反射的方式获取类型信息代码会少很多，并且灵活性也会高很多。

fastbin和link结合不畅主要在于两者都定位成了通用的模块，结合起来的时候没办法获得最佳的体验。

所以我们重新写了一遍代码，做了一个面向服务接口的link，直接内置了分包和消息类型识别，fastbin则作为消息的序列化格式插件，并用反射进行类型分析。

但是反射不能获得类型上的注释信息，要生成fastbin的接口协议文档的时候需要这部分信息。所以生成fastbin的接口协议文档用的还是AST上的信息。

基于前面说的开发流程理念，我们对之前做的功能模块配置方式也做了调整，之前我们试过用PHP来做客户端和服务端共用配置的管理，后来还试了JSON，但这些都不够直接，主要的问题是配置文件中需要先声明一遍结构和数据，在服务端又需要再声明一遍对应的结构才能把数据加载进来。

我们延续fastbin的思路，做了一个配置工具，用go结构体定义配置的结构，并用全局变量的方式原地声明默认数据，然后再用类型信息和默认数据序列化出JSON配置文件，这样结构和数据就都在一个文档里了。

新的代码暂时不会提交github，等实际验证过没有大问题了再跟大家分享。