为项目做一个完备的配置表工具-基础设计与技术选型

在正式开始之前,我们要先来就我们的需求,开始一波程序的技术选择与基础构思.

1. 首先, 工具选择用什么语言去写?

先看看我们大致的前提.以及我们的要求:
1. 要求能够快速开发, 社区足够强大, 语言特性足够丰富, 语言环境搭建简单
2. 希望能够跨平台使用, 毕竟工具设计的是客户端和服务器是公用的. 很多服务器人员会是Linux或者是Mac. 所以要满足跨平台的需求
3. 希望编译速度足够快,试错的成本较低.
4. IDE要稍微好用一点, 这样写起来会更舒服.
5. 最好是业界流行语言,这样写完工具之后,差不多语言也掌握的差不多了.

基于以上的这几点分析, 我选择了Python. 基本上面提到的点Python大部分都能够满足.

2. 如何满足各种语言的各式各样的代码生成?

其实配置表工具我写过好多次了. 不过没有这次考虑那么全面. 心比较大, 想做一个一劳永逸的工具出来, 能够支持大部分环境下的代码生成. 而且自己不用写太多的代码扩展. 并且能够兼顾序列化反序列化的效率问题等等.
1.最开始的时候, 我是采用直接写文件的方式来生成代码. 一旦使用的人员有任何的需求变动, 对于这样的方式来说, 带来的变动都是非常大的. 因为涉及到的改动会比较多. 而且这种方式不灵活, 也不够直观.
2.后来自己学乖了, 也进步了 采用了文件模板引擎来生成代码. (这里使用的是 Python的Mako) 这种方式简单直观, 你只需要了解下Mako的语法之后, 就能像写正常代码一样写 文件模板代码, 然后生成.(可能就是去了解Mako本身的语法会比较难) 算的上是很省心省力了. 但是每次要给新的语言做支持的时候, 我就要新作一份模板, 而且持续不断的维护他. 这个是这种方式面临的问题.
3.现在采用的方式是 使用Protobuf作为中间件, 将Excel转换为Protobuf的描述文件, 然后根据这个描述文件生成Protobuf支持的语言类型的代码. 那么就变成了我只需要对接Protobuf这一个类型, 而由Protobuf去对接其他语言. 我的工作量突然一下就变得很小了. 这是一个比较明显的进步. 而且Protobuf为Google实现, 代码质量是有保障的. 反序列化和序列化都是有优化的,也有数据压缩处理. 而且Protobuf作为目前业界极其受欢迎的网络格式数据, 占用率也很高, 代表大家不用太多成本就能够熟悉和应用起来. 这种方式是的缺点是 极其依赖Protobuf, 而且运行时依赖于 Protobuf本身的库. 如果项目就在用Protobuf的话,那么没有什么副作用,如果项目本身没有使用的话, 就需要为配置表模块导入Protobuf的库.
但是带来的好处足够多。 如果没有Protobuf库，那么：
1. 你需要为每种需要写解析器， 解析你导出的数据。 并且关心反序列化的具体实现和优化。
2. 你可能需要在其他语言里面关心分隔符（分隔符是目前遇到最坑爹的问题，没有之一）的事情。（导出二进制就可以不用）
3. 如果考虑支持自定义复杂类型， 那么你需要为每种需要生成一个该类型的脚本类，并且还有为每个类自动生成解析类。（累死了）

3. 如何做到方便扩展?

怎么才能做到方便扩展呢?
目前我自己看来比较行之有效的方式是：
1. 首先是一个合理的底层抽象系统。 什么该被封装在一起？ 什么该被定义为一个对象？
2. 一个简单而完整的架构图， 最少应该把系统的结构和层级分清楚。
3. 一个比较简单的交互图， 哪些模块会和哪些模块之间有交互。不用特别详细，初期设计的时候至少做到心里有底。明白哪些模块是会合其他模块交互就可以了
4. 最后再把自己觉得很有可能会变动或者扩展的地方，单独列出来，然后考虑这部分怎么去设计和处理。
5. 尝试在把模块区分的足够独立, 尽量在功能开发结束之后为每个模块新增测试用例. 如果你结构设计的不好, 那么在处理测试用例的时候, 会很痛苦, 这个时候你大概就会有意识的处理好模块与模块之间的耦合, 与一个依赖的处理

完成这几点分析， 我觉得一个简单的可扩展的结构是能够被呈现出来了。

4. 插件选用

1. IDE, PyCharm
2. 文件模板引擎, mako
3. 语言中间件, protobuf
4. Excel读取, openpyxl