计划写一个系列文章，总结自己在四年iOS生涯中对设计模式和架构的理解。主要包括自己的总结、Apple源码和优秀三方开源项目中设计模式和架构的学习。
这只是自己的总结，每人理解不一样。希望能抛砖引玉，让大家加深理解。
业务与重构
系列中的第一篇文章主要介绍自己在码业务时的一个指导思想，主要解决在快速开发过程中最常遇见的2个问题：
- 业务开发中如何避免过度设计？
- 何时需要重构？
为什么会有这样的问题？ 通常我们的版本是呈现出小步迭代、快速开发的开发规划，主要就是功能多，开发快。所以就会要求我们在码业务时：尽量快速的开发功能，同时又要追求高质量的代码。在一段时候后业务越堆越多再去添加新功能越来越麻烦，又需要我们重构代码。这些问题是非常矛盾的，我们如何去判断何时该进行代码抽象？何时又该去重构？
God, Grant me
the serenity to accept the thing I cannot change,
the courage to change the thing I can change,
and wisdom to separate the difference.
业务开发中如何避免过度设计？
DRY原则
DRY原则是Don't repeat yourself 的缩写，DRY原则想要表达的是：系统内的每一个知识点都应该是单一，明确，权威的标识。同样的功能不应该重复多份实现，应该提取成一个共用的功能。
YAGNI原则
YAGNI原则是You aren't gonna need it 的缩写，YAGNI原则主要含义是：不要添加多余功能除非那是必需的。
Rule Of Three原则
Rule Of Three原则是指当一个功能直到第三次出现时，才进行功能提取。为什么是三次？在数学领域如果要提取一个模型：
Complete the pattern:
1, 2, _, _, _, _
当这个模型只出现2次时，推导完整的模型是非常不清晰的，依靠出现2次的话可能有以下模型：
1. x2 模型
1, 2, 4, 8, 16, 32
2. +1 模型
1, 2, 3, 4, 5, 6
如果出现3次才进行模型提取：
Complete the pattern:
1, 2, 3, _, _, _
这个时候得到的模型将更加清晰，只会是+1模型。通过第三次重复才开始提取能更加确定这个模型，在代码中同样适用这个理论，这样能避免提取错误模式情况下的浪费时间。
计算机领域其实有很多地方有3这个数字，比如HTTP需要最少3次握手才能建立信任关系下的稳定连接。并不是说大于3次不行当然是越多越好，但是3次是最少的次数。
总结
软件开发中如果不依靠这些原则，假设有足够的经验和直觉下：
我们只看到一次出现的代码就进行抽象，这可能非常耗时因为特定场景的不同很多细节也有差异，这些差异会出现在抽象代码中，你的经验和直觉可以给出更好的设计，但还是有风险。所以现在只管去做先不要抽象。
第二次出现就抽象能让我们更好的了解哪些细节需要出现在抽象代码中，哪些不需要。但是抽象模型不够清晰，可能在第三次出现时需要大量修改逻辑，这样还是很费时。所以在第二次重复出现时不去抽象非常让人反感，但是还是可以非常快的copy过去进行修改。
第三次出现再抽象，基本魔板已经确定，所有细节哪些需要抽象哪些不需要的也能确定。哪怕第四次出现的偏差也能快速确定是否需要抽象，快速调整。
上面介绍的三个原则相互补充，尽可能完善的指导我们何时才需要对代码进行抽象。帮助我们快速开发，节约时间。
何时重构？
什么是重构？有两种解释：
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。
重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
何时重构？
- 添加功能时重构
我无法理解之前的代码。
代码的设计无法帮助我们轻松添加我嗦需要的特性。
- 修复Bug时重构
代码结构复杂不容易看出bug，这时重构能帮助我们理清逻辑。快速看出Bug。
- review代码时重构
review是很有价值的事，在review过程中可以阅读其他人的代码提出更多恰当的建议。同时重构能帮助我们更好的理解代码，提出更有意义的代码。但要记住一个团队中保留多个意见也是很有必要的。
以上重构时间排列是有先后顺序，同时重构前需要有足够的测试用例或单元测试支撑。重构遍布在每个版本开发过程中。
以上引用内容摘自《重构 改善既有代码的设计》，非常推荐。
总结
过度设计非常浪费时间，想半天可能再最后全盘推翻。绞尽脑汁，封装极好的模块可能就一个地方在使用。
重构是软件开发过程中不可缺少的一环，重构应该伴随在整个版本开发过程。
希望上面两点总结，能对大家有用。:)
参考
Abstraction: The Rule Of Three
