最近做的一些事情

Go by 达达 at 2015-05-12

自从年初的时候发了关于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,等实际验证过没有大问题了再跟大家分享。