看到一些讲架构的文章，和我早期的一些想法一样，有些时候过于的学术派，一定要区分个模块、套上什么模式之类的，所以这里聊聊我的看法。
在我入坑早期的时候，非常的看重设计模式这类的学术型论述，非常的崇拜那些一出来就把层级、架构讲的条条是道的人。曾经有位多年经验的人告诉我，不要太纠结于设计模式这种虚的东西。当时的我还不怎么认同，直到最近，自己从零开始，参与并作为主要开发人员完成了一个项目从无到有的过程，在此期间也遇到并解决了很多问题，由此感受到了之前别人所说的话的意义。
很多东西，比如层级、框架都不是一开始就能够完全的设计好的。在一开始的时候，我也不知道我们的应用会变成什么样子，或者说目前的结构和一开始构思的已经几乎完全不一样了。在不断的需求迭代过程中，我们才慢慢知道，真正需要的是一个什么样的框架。比如是一个快速迭代，功能有比较统一的可以尽量模块化来进行复用，而一个功能稳定的内容则需要设计的简单可靠。所以问你一个功能应该怎么设计是不能判断一个人的能力有多高的，虽然可以刷掉一部分差的。
现在大家说的mvc，mvvm这些模式也是别人总结出来的，我们难道一定需要按部就班的去按照这个模式去写吗。当然不是，人是活的，谁能知道以后会不会由你来创造一个新的模式呢。很多时候去争论某些内容是属于v还是属于m其实也是没有太大的意义的。当不同人从不同的角度去看问题的时候，自然就可能会有不同的理解，所以好用的才是好的。当然这里也不是鼓励不考虑这些框架，而是现实情况下，这些框架都有一部分的缺陷，为了简单可靠的弥补这些缺陷，可能就会有些争论的部分。
那么学术派的理论难道是没用的吗？当然不是，理论是高度概括的实践经验，当你了解了所有的设计模式，需要的不是想套用公式那样套用，而是真正的去理解这样做的是为了解决什么样的问题。就像张无忌学习太极，记住了所有招式，然后又忘记了所有招式。根据实际情况利用模式里面解决问题的方法才是学习理论的目的。不过好像目前iOS端能够使用到的设计模式比较单一，很多人也就停留在单例，工厂这些。
最后再来说说架构师。服务端，如果使用的是一个稳定的开源框架，比如spring，几乎不需要什么二次开发的，几乎所有功能组件都有现成的，仅仅需要按照文档来搭建好就可以了，一般的项目来说这些就足够了，那么什么样的程度才算的上是架构师这个职称呢？同样前端，目前的技术更新比较快速，但目前这些技术框架，比较有名的都来源于国外，国内都在忙这学习。那来说说客户端，客户端的模式基本比较单一，都是按照官方的规范来做，如果自己搞一套，那么简直作死，同时客户端的组件比较分散，既可以用a的组件也可以使用b的组件，但总体来说这些组件都是一些小功能小模块，还不足以按上一个架构的名号，同时国内大部分以业务开发为主的行情来看，如何才能达到架构师这个职称呢？所以在国内很多互联网行业所谓架构师的应该仅仅是技术选型的人员。
综合来说，架构师绝非一蹴而就，需要非常多的项目经验和理论知识，涉及多个编程领域，才能设计的出一个比较好用的东西。
