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

当前,仅仅是一些概念性的理解,仅当娱乐。

一、设计模式

通常体现于表现层(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. 同样的问题,同样的标准答案,用不同的人来回答肯定是不一样的。(当然,那种以标准答案来作为评估的面试官除外)

首先大家一定要清楚一个现象:对于一个应聘者来说,知道了当前团队的题库之后,只是增加了他的 突击面 罢了,对泄题不泄题没有任何的影响。哪个应聘者在投简历之前不会疯狂的看题库呢?

那么当前团队的题库泄漏,会带来什么好处呢?简单的看个场景:

当小明遇到不会的问题的时候,小明应该会这样做。立即将题发到群里面并说:今天遇到一个 ****** 公司的面试题有点难,各位大神知道怎么解决么?

无形中,是不是打了一个广告。

那么问题又来了:如何将自己团队的题库,推广呢?发面试通知的时候。

七、你喜欢的技术 Leader 是什么样的

    1. 什么也不会的,要是他什么都知道,那还交流屁啊,直接听他的就可以了。所以牛逼的 技术 Leader 应该懂得 如何装做什么都不知道 也是一门技术活。
    1. 多听,少结论。有一种傻逼式 技术 Leader,听到别人说的与自己的不一样,话音刚落立即否决。
    1. 先肯定别人,再慢慢分析。别人说的话,随便听一听,自己做决定。
以上3点仅仅限于技术交流的过程中,否则全都乱套了。毕竟决策权还是必需由 技术 Leader 拍板 的。

你可能感兴趣的:(设计模式&架构&组件&技术的简单理解与奇思妙想)