设计模式&架构&组件&技术的简单理解与奇思妙想设计模式&架构&组件&技术的简

【设计模式&架构&组件&技术的简单理解与奇思妙想】当前，仅仅是一些概念性的理解，仅当娱乐。
一、设计模式
通常体现于表现层（UI)，主要解决的问题是数据、视图与控制器之间的相互关系。就是所谓的 MVC、MVVM 以及 MVP，等等
二、架构
通常体现在整体的项目，主要解决的问题是项目或者特殊功能整合与分离的依赖性，比如网络与本地数据访问的设计。讲究的是项目以及功能的独立性。
架构有两种金典的划分界限：三层架构与四层架构。

三层架构：表现层、业务层与数据(网络)层。
四层架构：表现层、业务层、基础/核心服务层、网络(数据)层。

知道下面这两张图出自哪本书么？有木有发现与上面说的四层架构有那么一点点的不一样。

分成架构.jpg
App 架构设计.jpg 关于分成，合理既是真理。难点不是如何分成，而是层与层之间的衔接。关于这个衔接，重心是接口的设计，接口设计不合理，再牛逼的代码都是多此一举。六大设计原则中的接口隔离原则，可能也有这一层意思。
三、设计模式与架构
往往在考虑架构的时候、必须考虑设计模式、反之可以忽略，是一种包含与被包含的关系。
来看一张经典的图：

六大设计原则.jpg
建议：六大设计原则、23种设计模式可以找个时间看看，但是对于移动端来说，在正规场合建议不要提什么原则，什么模式。举个例子：单一原则，我第一次听到的时候，简直懵逼，还以为是什么高深的东东。最后得出一个结论：把面向对象三大特性中的封装性理解透彻了，比说什么单一原则都强。你要问我为什么，我也不知道，就是感觉罢了。我个人认为六大设计原则、23种设计模式有一半的东西在移动端根本就说不通，尤其是23种设计模式中，以其说它，还不如好好理解面向对象的三大特性，以及常规的MVC、MVVM 以及 MVP。

以上的这个建议，我可能会随着时间的推移而发生改变。

四、组件与业务 => 技术
4.1 简单定义组件的存在形式有很多种：比如 pod、静态库等。组件务必要有的一个特点就是：通用。不通用的东西，姑且叫做封装。
业务通常叫需求。对于程序员来说，主要关注的是这两个问题：具体的业务（需求）是什么？该如何使用技术来实现？
技术与组件有关系么？与业务有关系么？不同的人看到应该会有不同的答案：有关系，如果没有关系，为什么同一个组件有的人能弄出来，有的人就是弄不出来。或者说有的人需要1小时，有的人需要一整天。也会有这样的回答，没有特定的关系，因为同一个组件/业务可以使用不同的技术实现，即使所有的人都是使用 OC。同样的技术，也需要考虑使用技术的过程中方案的优劣性。
关于技术，我在这里说了这么一大段，为什么？

有的时候发现，当我们实现一个功能后，就不去思考我们使用过的技术是否合理，或者说是否还有更好的方案。更有甚者，有的人听到别人给他做的东西一些建议的时候，就要想方设法的说：这是因为需求就是这样的，总感觉他做的就是最牛逼的。

4.2 变通以上说的都是一堆的废话，因为仅仅是自己一点点的理解。任何的架构与设计模式，都不是技术人员决定的。说大一点，有80%的原因是由公司的整体产品的发展趋势而决定。所谓的架构与设计模式总是为了增强代码的通用性以及健壮性，达到简单易用的目的。所以在不知道公司产品发展趋势的情况下去谈架构以及设计模式，那就是闲的蛋疼没事找事干。
对于一个团队来书，什么架构、什么设计模式、什么组件，如果没有很好的规划，那就是对神弹琴。毕竟主要还是要看代码怎么写！主要还是要看代码怎么写！主要还是要看代码怎么写！
五、一张图的哲学本来写到上面，就应该结束了。但是就想再加一张图，就在网上找了一张。

可爱的螺丝钉这不是随便弄的一张图，请注意标注出来的那个中间层。一个螺丝，如果不用红框框中的那个东西，可以么？答案是不可以，为什么？答案自己体会，我也不知道。
同样的道理，在做程序设计的时候，不管是设计模式、还是架构都要考虑一下层与层之间的衔接。美其名曰：中间层。
以下内容补充于 2018-08-05 早上不建议看，仅个人唠叨。
六、技术交流的一点奇思妙想技术交流核心：交流思想与技术。
对于一个程序员来说，技术交流的场景莫过于面试的时候，一直以来都是把面试看成是一场正式的技术交流。作为应聘者来说，他肯定会想尽一切办法来向面试官表达其所有的技术，当然也免不了有滥竽充数的情况。对于面试官来说，也会想一切的办法来挖掘应聘者的技术能力。我认为一个合格的面试官应该是这样的：挖掘的是应聘者知道的技术点，而不是一味的官僚主义，当然特殊的岗位除外。当然这种交流方式非常的正式，正因为这样，也带来了另外的一个问题：只会暴露其优势的地方，不会暴露其劣势的方面。
上面谈到面试似乎已经偏题了，毕竟面向面试编程也只是技术生涯的一小部分。要使自己，或者说自己的团队的技术更上一层楼。重心应该是接下来介绍的这三个方面：
6.1 自己与自己的交流
在很久很久以前，我是这么与我的团队说的：

如何去检测自己的技术是否有进步的方法就是：今天去看三个月前的代码，如果你认为你三个月前的代码写得很不错，那么说明在最近的这三个月你除了多敲几行代码，你根本就没有任何的进步。如果你认为你之前的代码写得太屌丝了，或者为此感到羞愧，恭喜你，你进步了！

到现在为止，我感觉以这样的方式去检验自己，是一个很不错的方法。

我们不能否定曾经的自己，但是可以优化未来的路。

6.2 自己与团队的交流
自己与团队为什么要技术交流？给我一个功能，我实现出来不就可以了么？从某种方面来说确实是这样。但是团队必须要有一个统一性的，技术的不统一会在后期的开发中遇到很多的问题，比如不易于维护，比如人员的流动。
自己与团队不交流，会导致什么样的问题，其实大家心里都很清楚。接下来简单的谈谈，为什么在很多的时候自己与团队就是交流不起来？当然，平时遇到难题的时候请教别人，这种不太算是技术交流，这种情况是被动的，我主要想谈的是主动的那种交流。
在一个团队中，自己如何与团队进行主动的交流，在很大的程度上，不是自己说了算的。主要是技术Leader ，他不发话谁敢乱动，除非你说的百分之百的正确合理，否则饭碗不保是必须的。更可怕的是：

技术Leader 做出来的东西都是对的，别人的建议都是因为对业务的不熟悉，这个就是这样，以后你就知道这是为什么了。

遇到这种情况，在牛逼的人都会无话可说，因为每个人都想填饱肚子不是么？
如何看待在团队交流中那些错误的观点？如果说在一个团队中，每个人说的都是正确合理的，那么交流还有屁用么？所谓错误的观点，不代表这个人的能力有问题，也有可能是思考方式不一样。
有错误观点的提出，才能知道团队技术提升的空间以及改进的方案。难道不交流这个错误的观点就不存在么？
6.3 团队与团队的交流
在上面的介绍中，虽然谈到了团队，但是从某种方面来说重心还是个人。对于个人来说，也有一套自己的技术栈，对于一个团队来说，也是一样。团队也有自己团队的技术栈，技术栈不更新，就如同一潭死水。那么问题来了：如何更新自己团队的技术栈呢？其实方式很多，比如加强学习。但是现在的主题是交流，所以现在的重心是自己的团队如何与外界进行技术的交流？
其实对于这方面，我们有过任何的实践，也还没有那样的机会。但是也深知这种交流的重要性。
所以还想谈谈上面提到跑偏的问题：面试。应聘者就代表其他的团队，面试官代表的就是自己的团队。那么就说明了面试官的重要性了，面试官代表的不是面试官自己，而是代表自己团队的整体。所以我个人认为脱离自己团队的面试官，都不是合格的面试官。其实在很多年前，我就已经意识到这个问题，所以我会将自己整理出来的面试题在当前团队中完全公布，包括实习生的面试题。后来还特意的做了一个实验：实习生入职经过一定时间的训练之后，让他们再次回答当初的面试题。当然了，由于那时候环境的限制，这方面做得还不是太彻底，但是我一直认为这种方式是很必要的。
当然，应该有小伙伴立即发出一个疑问：面试题泄漏了怎么办？这个问题实在是太金典了，在我的内心深处特别希望被泄漏！原因有二：1. 没有哪个傻逼面试官会原原本本的按照题库来询问的。2. 同样的问题，同样的标准答案，用不同的人来回答肯定是不一样的。（当然，那种以标准答案来作为评估的面试官除外）
首先大家一定要清楚一个现象：对于一个应聘者来说，知道了当前团队的题库之后，只是增加了他的突击面罢了，对泄题不泄题没有任何的影响。哪个应聘者在投简历之前不会疯狂的看题库呢？
那么当前团队的题库泄漏，会带来什么好处呢？简单的看个场景：