2020-07-12 blog

Deep Go

历经波折，这个重写了无数遍的框架总算是有了一个正式的名字。

从最一开始立项做这个框架，到后面不断重写，也有一年多了。

第一版是hat1。那时候是刚开始做机器学习这一块。刚接触到keras，但是对keras并不够熟悉。而且当时我写python也没有自己的风格和规范，所以写得非常乱。

要动手做hat2，我也不记得是什么原因了。大概可能是因为新需求的提出，然后原来的框架因为太乱，索性干脆重构了吧。hat2的特点是已经有一定的代码方面的规范，但是也是有点乱来。当时提出了一个比较有意思的点，就是所有的数据集、模型，都是在一个文件夹里，然后用动态import的方式来调取，有“分包管理”的思路。另外，hat2也开始支持多gpu。

之后不出所料，也是因为太乱，所以重构又来了。hat3的特点是很突出的：1、有明确的代码规范，形成了文件；2、开始自己写训练逻辑，并且实现了获取训练中间数据；3、初步将模型、数据集与框架本体分离，只不过当时只是放到了app文件夹中。但是因为hat3编写的时候，没有接触到gpu服务器，所以当时没有做多gpu支持。

整个开发过程中，其实框架的部分也没有那么的重要。因为实验、测试比起框架的完善，优先级更高。当时提出了很多很有意思的Feature，但是很多都存在了TODO里面，没有真正实现。

下一代重构，不叫hat4。因为其实最一开始起名为hat，是为了用名字凑一个有“字典意思”的英文单词，然后就以Hust Artificial neural network Tools来命名了。但是到了4.0时代，我感觉这个名字不太对劲，所以当时以Neural Network Tools做名字，因此第四代的项目名为nnt。

nnt的特点也非常突出。首先，从这代开始，将自己本身定义为一个第三方包。也就是说，模型的训练等等，所有的实验等等，并不会放到框架内。这一点其实是受到了开发bwt时候的影响。

前面三代都会出现一个问题，通用的代码和特例代码的共存问题。一旦将实验的部分也放到框架内，势必会出现各种各样的兼容性的问题。于是，在最一开始还没跑数据的时候，框架是clean的。一旦开始出现某些数据不太兼容，必须手动进行处理的时候，就会引入各种修补。随着时间推移，就会变得很臃肿，混乱。

另外，nnt还有一个跟前面三代都不一样的点，那就是开始有“有层级”的设计。这是一个三层的框架。最底层是内核层，封装各种python、TensorFlow、Keras、Numpy等的方法，提供API，以及io等较为内核的部分。中层是框架层，定义和封装各种既不算内核，又不算应用，是基于内核，又为应用提供服务的东西。比方说Log模块，还有Config模块等，这些类或者功能本身并不是一个应用，并且他们也基于内核层。最顶层的自然就是应用层了，定义和封装的都是外部直接调用就能用的。比方说Trainer、Dataset等。

这么一层封装，其实也有一个巨大的好处。因为TensorFlow的智熄操作，使用LazyLoader的方式来加载函数，各种乱改包路径，导致VS Code无法正确得到tf的函数文档和函数输入等（即智能补全失效）。自己封装一遍，正好可以补上这些缺失的部分，在做实验的时候也非常方便。

但是呢，因为名字不好听（听着像 你脑瘫），所以决定改个更好的名字。想了很久，最终是决定使用Deep Go这个名字。

也就是说，Deep Go其实已经是4.1版本啦。

还特意做了一个还算ok的README。如果有机会的话，给Deep Go设计一个logo就更好了。

目前，Deep Go的底层其实已经写了大部分了，框架层和应用层也在慢慢补充。按照之前的开发阶段预估来说的话，也就是说alpha版本其实已经算是达到了，下一个阶段就应该是beta了。

但是我感觉可以先再补充一点东西，然后再去release也不迟。