当你要去写代码

如果代码新增了场景，可以这样做，除非你想让你的代码量异常的庞大。
1.仔细阅读原来的代码，分析逻辑
 如果原来的代码是优秀的代码，代码描述了一条通畅的happy path，那需要分析原来的代码，分析新增的场景，防止在happy path上过多的不明去向的小路产生；如果原来的代码是一滩浆糊，那更需要分析原来的代码，不然你的代码会从浆糊变硬，然后一碰就悲剧了。
2.站在全局的角度审视你的代码
 一段好的代码是有很好的层次的，每个层次也都有清晰的模块边沿，如果把需要新增的场景放在合适的层次上的合适的模块中，那么代码的修改量将会很少，而代码的脉络却不会发生变化，不会产生某一个模块自己重新把业务流流走一遍，这样，代码量减少了，代码复杂度也降低了。不过这个需要点时间把代码理清触。
3.你想清楚了吗？
 当你准备按动键盘写代码，那你一定已经把将要做的事情放在肚子里了，也就是说，澄清了，已经可以把happy path随意挥洒在白板上了。这个时候，写代码就只是写代码了，而不是写几行，突然发现有个地方又出现了疑点，然后整个人都扑到疑点上，疑点澄清了却发现原来写的代码没办法用了。不过感觉这个需要很好的代码功底和很全面的业务了解。

 现在把这几点倒过来看。最开始已经想的很清楚了，于是很容易的构建出happy path，基础功能实现了。新增功能的时候把happy path拿出来，到正确的地方添加合适的逻辑，新功能又实现了。然后仔细的阅读原来代码的每一行，分析新增代码与旧代码哪些地方是相似的，哪些地方已经是当初多于的设计等等，把代码整理一下，代码又变得美观了，这也就是个敏捷中小步重构的过程。

 这时候或许该说说关于最近代码重构中，代码量是如何减少的。就说对辅助资源的加载吧，原来的代码里对不同的制式的不同的资源分别写了一套代码进行处理，其实也可以理解，因为每个资源内容不一样，肯定没办法直接复用原来的代码，于是原来的代码中到处都是这样的一个流程：
1.取文件的一行
2.取出这行中某个分隔前面的字段
3.取出这行中某个分隔后面的字段用来重复2
假设读取这段需要30行代码，3种制式x3个文件x50行代码=450行代码，而实际上最多50行就能解决问题。这是在代码基本实现上的问题。
 层次这个在原来的代码与新代码的区别，或许用深度搜索与广度搜索的来形容比较形象。原来的代码里面没有做抽象，一个具体的实现一条路走到黑，流程结束。重构后使用了一个合适的抽象，预处理层把不一样的东西处理成相同的形状，然后核心算法层把相同的输入转换成相同的输出，不同的层次做不同的事情，代码的维护也变得简单。
 最顶端的设计难度就高了很多。首先是各种设计模式的精通，这不是为了套用模式，而是从宏观的角度对模块间的关系做设计，设计的好，实现出来的代码就好；设计的不好，实现出来的代码就杂乱。然后是对语言的实现的熟悉，语言只是工具，是一种实现的方法，但是不同的语言特性对设计也该有影响，不然写出复杂的代码总是不容易走到happy path上的。
 其实还有一些技巧上的事儿，或者说，你熟悉某种算法，而这种算法处理这种业务就刚好高效；你熟悉某种业务细节，很容易就把脉络理清。但是这是锦上添花的事儿。