有时候一个地方暂时看不清怎么写比较好, 往大了说是框架, 层次, 往小了说, 不知道起啥名字, 一个总是让你内心凸起一个小疙瘩的 框架, 类, 函数, 命名 都会让你每次路过时 被 咯一下.
有时候会想着, 我忍了
慢慢的,你会发现, 因为这个小疙瘩, 又不得不引入另外一个疙瘩. 慢慢的 坑坑洼洼的路面, 你的速度跑不起来, 你会难受到讨厌自己
突然,你在又想引入一个疙瘩的时候, 感觉到不适感到了极点, 没有在不改其他模块的基础上得到一个说服你自己的方案了.
一般遇到这种情况, 你会清空大脑, 不去想现在, 只想美好, 只想在这里的美好
你会先把这里写的美好, 然后着手开始把上层设计,接口和参数,下层调用和参数逐一改到符合这种美好.
你会突然发现, 这种美好开始蔓延, 并且在这种蔓延的趋势上, 你会发现更多的Parter, 更多的巧合,
比如: 你改到一个函数的参数, 你认为这个参数应该叫这个名, 你改了, 然后你接着改函数内部使用这个参数的地方, 你会发现, 这个函数所在的代码行, 它作为左值或者右值时, 它的另一半就拥有你想改成的那个名字的意义,或者就是一致的
你会心一笑, 会明白, 你改的东西都是值得的和有意义的, 代码读起来更像一篇通顺的文章, 有条理的文章. 绝大部分疙瘩都不见了. 仅存的疙瘩也是那种不会传染的内部临时变量之类的. 无关痛痒
在一次新增需求时, 短时间看起来逻辑不很复杂, 而且增加后可以保持和已有逻辑(更简单)相处比较和谐时, 增加了一些代码, 突然发现, 这些代码依赖了一个数据文件, 看起来这个类300-500行, 属于健康的状态, 之前一直没有用过数据文件.
所以首次引入时, 产生了一个疑问: 这是不是意味着 新增的代码不够恰当, 为啥那么多已有逻辑不依赖, 新增的这些代码会打破现状? 因为需求比较简单, 而且当前版本已经进入后期, 预期这块内容在下个版本才会变复杂, 目前这块已有逻辑不超过100行, 比较清晰.
出于不提前设计的角度考虑, 暂且采取这种简单的设计, 直接在已有逻辑上扩展.数据文件也暂且不纠结. (其实心里是清楚的, 这块内容今后要变复杂, 提取是必要的, 不提前设计,先记个TODO)
在1个月后, 需求果然变的复杂, 但是比预期要早一些, 在这个版本末期就因为必须要的效果而需要变化
(果然需求是喂不饱的, 你提供的机制越好, 需求会越多越复杂, 最终形成产品的强大优势, 参考AWS, 这一点, 程序员做的越多, 越好, 事情也越多, 当然我是喜欢这个节奏的, 拥抱变化, 不断迭代, 远比一个个堆砌功能要有意义得多).
因为之前的设计比较简单, 一目了然, 所以没有给重构带来负担, 逻辑和数据结构的分离设计也是友好的, 替换其中的数据结构也不会导致逻辑流程出现问题. 所以愉快的进行了重构
重构到收尾阶段, 清理一些不需要的引用时, 发现这个数据文件的引用果然被干掉了, 因为需求复杂话, 这块100行的代码有部分被挪到了新的类里去封装. 数据文件的引用也被挪到了相应的地方.
所以可以看到, "事出反常必有妖", 反常的代码也必定是不合理的, 读不通顺的命名必然是不合理的, 违反常识的必然是坑. 这些都是抓到BUG, 发起重构的线索.
遇见 更美好的 代码.