不少框架都支持有这部分内容，但是框架不可避免会有约束和耦合部分，读完源码局部改只是满足当前需求，正常作息的人可能并不一定有时间吸收。
一旦自己真正从 0 开始写新框架时，可能依然不会使用这部分比较像开发做法的知识（结构化，设计模式，中间件等特性）。
先谈谈比较像开发做法好处，一旦代码风格包含开发的特性，更利于理解日常开发的代码，达到高效的解读目的，比如熟悉依赖注入和 IOC 可以在使用 spring 系列的时候更好理解设计，如果不明白，会事倍功半。
最近在学习新语言，尝试用 Go 在家里，重构过去一些东西，写了几天后，来说下自己的一些浅薄看法。
文章适读：
对于用什么语言来说没关系，都可以读。
单机使用框架可能会觉得没必要，但网红小吃都在日新月异的飞速发展（每周出去吃好几顿都已经掉队几百米的人），测试也需要进步啊。
1.要预设支持使用采用命令行开发
也就是所有语言对于 args[下标] 的设计 大体推荐结构
【构建运行信息】 【Node功能名称】 【参数1】 【参数2】 ...其他参数
构建运行信息根据不同语言和使用对应库的特性，包含运行编译改程序解释器关键字 + 最终文件使用格式
e.g ./mian.bin mian_start chat_server 20002 1000
//启动编译运行一个编译链接后的Main.bin文件启动下面的chat_server服务 端口20002 支持链接上限1000人。
支持切换不同版本的配置文件 这个非必需的，Node 功能名称内部也可以包含 test 版本
2.对上面的延伸，c/s 或者 b/s 都要有测试端的概念。
纯后端程序肯定需要，有前端的部分也可以有测试页面的路由，需要有命令查询模式，支持多端，也就是支持调度的模式。
这个可能和行业有关，我也在摸索，并不是都需要支持多端和分布式。
条件：需要支持一个测试端发向对应框架端的一条管道，这个管道支持一些字符串的查询命令。协议支持目前来看首推基础 Tcp 或者 Rpc.
下面是例子---# 号支持对其他链接客户端或者测试端查询，>号代表对框架端查询。
eg >connect //查询框架端当前连接客户端的addr信息
e.g #addr select conf.ini //查询其他端的配置信息
在框架端程序需要维护一个链接进来的对象地址映射表，为什么是映射表呢。
起一个守护的线程或者协程 connectChannel 用来维护关系，connectChannel 是 map 类型 {"地址 IP 端口":clientsocket 对象}
PS:地址 IP 端口在 Linux 上也可以用句柄号去记录。
>connect 是一个反馈字符串查询的事件，在框架那边所以需要一个事件管理器来统一管理，如果是查询类型 并且命令包含>的，就调度到查询本机结果的查询类型的处理分支（框架得到信息直接回写数据）。
如果有测试端断开了，也是通过一个事件去把 connectChannel 管道 map 对应的 key 删除，删除后不需要同步，因为查询会去检索 map 里面的 key.
框架需要定义统一的配置文件/接受文件位置和客户端/测试端也有统一配置/接收文件的位置
#addr select conf.ini 是一个查询反馈文件事件，本质和上面一样，事件管理器切换分发到命令包含 # 的地方，进行处理，把对应地方文件都读过来，然后一个字节不差的丢到接受文件的位置，然后反馈查询 ok，这个是图省事的做法。
进阶扩展
精细的话，# 获取配置用键值对的形式。同样>部分用 json 格式传输会比字符串合适。
今天先写到这里，下段部分 27 号之前完成。