这两天学习 API 网关项目的时候，不同的章节的任务不一样，有的章节注重功能的实现，有的章节注重在功能完善的基础上如何重构整体的架构设计，两者相比，我最多的感受就是后者的强度远大于前者。
功能性的代码实现往往几个类怼上去就可以做到，类中的功能性代码，哪怕有不了解的类，通过 GPT 复制源码，也很容易辅助我理解代码的功能性语义。
但是当涉及整体架构设计的更改上面，哪怕功能性的代码一点没变，在拆分重组后，将源码拉下来阅读，也会感觉很吃力。这种无力不是功能性上的阅读难受，而是想不通为什么要这样拆分重构。这种对架构整体的设计才是最难以理解的。我不知到它这样设计是为了什么而准备，课本上的各种设计好处往往是易于扩展，单一职责，等等一系列巴拉巴拉的。但是一旦进入真实的场景设计时，如何体现，体现在哪里。就比如网关系统的 RPC 泛化调用，在初步的功能实现后，如何设计架构拆分，以及拆分的粒度来保证后续既易于扩展，又不至于太过细致以使种类繁多。
最开始学习每部分功能代码的迭代重构时，虽然在包名，类名，方法名上已近开始有所体现架构的语义了，但是仅仅是这些，脑中对这块的理解仍然是混乱模糊的。后来发现一头扎进源码的阅读，其实成效并不快，但是在这个过程中却加深了对某些类的熟悉程度。
基本读完了某一个模块的源码后，脑中对这些东西仍然感觉是抓不住的，于是在整个功能模块的测试入口处打上了断点，不断地去 debug, 同时在这个过程中画出大致的流程图，画图的整个过程，总感觉效果远好于阅读源码的过程，那种模糊的感觉也越来越清楚。
当画完之后，脑中是清楚了很多，但是对于整体设计的把握仍然是不够明朗的。或许这就是看的不够多，写的很少，想的不够多，总是差不多的结果吧。