说说我们在维护一个庞大的系统过程中遇到的问题以及自己的一点想法。
先从design说起吧。
与design相关的概念根据其涉及的对象主要分为三类：
- SOLID， 低层次的，单个或者多个类间的，设计原则，
- 设计模式，中层次的，多个类间的，单个模块或者多个模块间的，设计模式，
- 架构设计，模块、系统层次的设计模式。
SOLID 是agile design的一些原则。
agile design不是软件开发过程中的某个阶段，而是对code持续改进的一种PROCESS。
SOLID 应该发生在coding的各个阶段，包括第一次实现，fix bug, 增加feature，以及其他的一些维护性动作。
TDD是coding的策略，是一个从无到有，从微观到宏观的过程；他完全不是先有了一些预期，或者high level design后的“照章”执行。
TDD而是根据需求写code，逐个User story, task去实现的一个过程。
这个过程包括功能的划分，design，类的识别等.
Baby Step是TDD的策略。
由于人脑的工作记忆容量有限，所以假设一次Baby Step需要考虑n项因素，那么n 不要超过 m +/- 2, 一般心理学书籍都把 m 设置为 7 -- 这是一个统计数字。
m +/- 2 中的 2 也是是一个统计数字，具体情况因人而异，请根据自己的记忆力情况做调整。
比如记忆力一般，7也许就是那个合适的值，如果记忆力超强，那么调整为 m = 9。
每次Baby Step都需要激活不同的知识点来作为refactor的前行的依据。
如果这些知识点很陌生，那么请设置m = 3。
每Baby Step都要考虑哪些因素呢？
- 比如对一个函数是否保持single responsibility的判断，
- 如果已经违背了single responsibility，那么如何拆分才能满足Open for extensibility and close for change?
- 对其它函数的影响是设么？
- 对test的影响是什么？等
这里只是举个栗子，实际操作时，每步所要考虑的内容都各不相同。
阳春白雪了一番，回到柴米油盐酱醋茶上来。
当前这个非常大的，非常老的，同时也是一个code质量亟待提高的项目。
在我们refactor的过程中经常遇到的一个问题就是被已有的概念束缚，并且觉得那才是正确方向。
比如我们有一个类叫HxReader, MxReader, 以至于后续的refactor就总是觉得应该有一个toolReader, 也应该有一个caliReader，等等。
它们就像是魔咒一样，让人们无法逃离旧有的限制而不自知，不能自拔。
形成这样状况的一个原因是我们现在主要是通过从HzReader中分离代码到其他小的reader中，而很少真正的re-implement.
而分离的过程基本上就是把更小的reader中用到的方法、变量拿过来就行。--虽然这也符合Baby Step的某些思想。
在这个过程中缺少正向开发过程，TDD，中应有的对变量、方法、职责、design的思考。
用上图来说话，可能就是迈出了一个concern number是50的大步子。
那么，何来Baby Step的好处与乐趣呢？
《人月神话》中曾说，软件开发就是开发一遍，扔掉，然后再开发一遍
以至于我一直在想，我们是否应该重新把其中一些重要的component重新写一遍。
在这次开发的过程中，充分的应用agile design中的一些思想，结合实际去充分的实践。
从而彻底远离魔咒，从小到达，从微观到宏观，逐步打造一个崭新的罗浮宫。