在提到架构设计的时候，我必须先说清楚为什么要关注架构设计，这里我引用文章中一段话：

“因为假如你不关心架构，那么总有一天，需要在同一个庞大的类中调试若干负责的事情，你会发现在这样的条件下，根本不可能在这个类中快速的找到以及有效的修改任何bug。当然，把这样的一个类想象为一个整体是困难的，因此，有可能一些重要的细节总会在这个过程中被忽略。如果现在的你正是处于这样一个开发环境中，很有可能具体的情况就像下面的这样：

1、这个类是一个UIViewController的子类

2、数据是直接在UIViewController中存储

3、UIView类几乎不做任何时期

4、Model类几乎不做任何时期

5、Model仅仅是一个数据结构

 6、单元测试覆盖不了任何的用例。

”


iOS架构模式--MVC,MVP,MVVM以及VIPER架构


MVC架构师我接触最多的，我使用起来也就是跟文章中提到的：1、这个类是一个UIViewController的子类 2、数据是直接在UIViewController中存储 3、UIView类几乎不做任何时期 4、Model类几乎不做任何时期 5、Model仅仅是一个数据结构  6、单元测试覆盖不了任何的用例。虽然糟糕如此，但是我们还是乐此不疲的使用着，依然觉得这样做容易理解，适合自己的编程习惯，轻量级的项目这样做会减少开发时间，提升开发效率。如此说来，这个也就不能称之为一种架构了，而是怎么编程简单怎么来的一种结果。

MVP，MVVM以及VIPER架构我都没有在实际开发中使用过，对他们的概念也几乎为零，只知道这么个名字，看过一些介绍的文章，但是还是感觉很复杂难于接受，或许，只有在大型项目中才会对架构的要求达到这种级别吧。


了解这些对未来有用吗？

正面假设：

假设一：假设以后我还是开发类似公司的这种项目，那么除了似是而非的MVC架构之外，其他的架构几乎都不会想到去使用它们，不使用它们，那么我对它们的了解最多也就了解20%左右，这仅仅是停留在了解层面。

假设二：假设公司引进架构师，对iOS做了相应架构设计，幸运的是他选择了其他三者中的一种，让我有幸了解到这些复杂的架构，从而将这种架构投入到实践当中，那么我对其他三个架构的其中一个也就了解了50%左右，这样大概要花6个月的时间。

假设三：假设我跳槽到一个很牛的公司，公司有几个厉害的架构师，经过它们潜移默化的影响，我对架构有了深入的了解和认识，然后我开始接触架构师这个职业，踏入架构师的行列当中。

反面假设：

假设一：假设我不了解架构，那么我停留的层面也就是解决程序当中出现个各种各样的bug，一个身经百战的小牛，由于着眼点的不同（一种是考虑整个iOS行业的发展进步，一种是在当前发展现状中穿梭自如，但是并不能对该行业有个整体的把控，一旦行业下滑，很难把握机会跳出这个怪圈，或者是为这个行业的发展提供建设性的意见，始终站在用户的角度，无法突破创新），我是不想成为后者，因为后者有一种被人操纵生死大权的感觉。



总结：

虽然学习架构很艰难，到最后也不一定能够学会，但是，我学习的不仅是知识，而是一种思维方式，一种高层次的思维方式。对于这个行业如此，对于从事其他行业亦是如此，高层次的追求，会得到高层次的体验，这样做是没有什么坏处的。