设计和架构：业务开发指导原则

计划写一个系列文章，总结本身在四年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过去进行修改。

第三次出现再抽象，基本魔板已经肯定，全部细节哪些须要抽象哪些不须要的也能肯定。哪怕第四次出现的误差也能快速肯定是否须要抽象，快速调整。

上面介绍的三个原则相互补充，尽量完善的指导咱们什么时候才须要对代码进行抽象。帮助咱们快速开发，节约时间。

什么时候重构？

什么是重构？有两种解释：

重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提升其可理解性，下降其修改为本。

重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。

什么时候重构？

1. 添加功能时重构

我没法理解以前的代码。

代码的设计没法帮助咱们轻松添加我嗦须要的特性。

2. 修复Bug时重构

代码结构复杂不容易看出bug，这时重构能帮助咱们理清逻辑。快速看出Bug。

3. review代码时重构

review是颇有价值的事，在review过程当中能够阅读其余人的代码提出更多恰当的建议。同时重构能帮助咱们更好的理解代码，提出更有意义的代码。但要记住一个团队中保留多个意见也是颇有必要的。

以上重构时间排列是有前后顺序，同时重构前须要有足够的测试用例或单元测试支撑。重构遍及在每一个版本开发过程当中。

以上引用内容摘自《重构 改善既有代码的设计》，很是推荐。

总结

过分设计很是浪费时间，想半天可能再最后全盘推翻。绞尽脑汁，封装极好的模块可能就一个地方在使用。

重构是软件开发过程当中不可缺乏的一环，重构应该伴随在整个版本开发过程。

但愿上面两点总结，能对你们有用。:)

参考

《程序员修炼之道》

Abstraction: The Rule Of Three

《重构 改善既有代码的设计》