DataBinding使用起来非常简单，先在gradle中打开开关。然后就是及其简单的使用了。
在同时了解了一部分博客之后，也知道这是Google出于对开发者的关注，对代码的解耦，让项目的各个层级分明。接着又是那老几样：MVP, MVVM等。
我自己对这些东西都是持着欢迎的态度的，并且也知道某种架构对项目来说也是十分有益的。但是……从另一方面来看，远远没有到为了架构而使用架构的程度。
从Android诞生之初，项目默认的架构师MVC，负责UI编写的XML文件，负责数据展示的Activity文件，负责处理逻辑的Adapter部分，这些分层让我们无需去刻意地使用某个框架就可以梳理清楚头绪。并且，因为从一开始学习Android开发的时候就使用的这种模式，所以也没有什么学习成本，或者说根本就不需要学习。
估计是因为UI层级或者处理逻辑逐渐变得复杂，所以才开始加入了所谓的项目架构，才开始有了架构这么一说。一方面是为了项目分层明确，调试方便，分工合理。另一方面也是存在着卖弄之嫌。
而我自己一直在不怀好意的揣摩着，是不是因为这几年开发岗位太多了，前些年的开发岗都升到了项目经理或者架构师的岗位。屁股决定脑袋，到了那个岗位也不可能不做事或者是当个救火队员一般的熟练程序员啊，正好闲的蛋疼。所以为了折腾一下，咱改个架构来试试？或者，干脆针对项目“自主研发”一种架构模式吧。
并且，自己负责的项目之中用的架构还要分享出去，不多让几个人知道怎么能说明我们的架构很厉害呢？特别是要多让几个程序员知道，大家互相鼓吹之下，效果也就出来了。
在知乎也潜水了好几年，这种戏码简直是层出不穷。但凡有一点经济和实力基础的人都会互相鼓吹，以巩固自身的地位和打击弱小者。然后就把一些东西说的是神乎其神，让萌新小白向往。但其实，都是狗屁！
说实话，从工程的角度上来看，我真不认为面向对象在使用方面比面向过程高到那里去。如果以面向过程的方式来做，一行行代码执行下来，一块是一块，真的是要好写很多，逻辑梳理也简单。充其量也就是多写两个函数而已。而面向对象可就真的是丧病一样的东西，就比如一个实体类，每次得多写不少代码。虽然IDE都提供了小工具进行快速构建，但是，为什么就不能把这些东西都集成到编程语言当中呢？明明都是重复的，枯燥的东西，编程本就是为了解决这些问题，而回到语言本身层面上却不支持。
或许我上面举的那个例子十分不恰当，因为我毕竟对PL了解甚少。而OOP确实在多人合作中还是有点优势的。
- 让更多萌新能以传统的观念（对象）来对变成进行理解和深入。
- 让多人分工更加的无脑化，结构化，工程化。
- 没有3了。
我还记得在大一上C语言的时候根本就没有好好上，以至于内存，地址等东西完全不清楚。当时编程的目的是为了在控制台输出几个字符。
后来用Java直接对Android编程，然后逐渐发现力不从心。很多东西根本就搞不明白。然后因为实习无望而接着学习，又从C语言开始，这才慢慢理解了很多东西。而这个时候回到Java层面来编程，却发现并没有多大的帮助力，其原因也是十分简单，对于真正的工程项目，始终还是接触较少。还有一个最重要的一点。
大家都被一股风气带的开始不说人话了。
OOP是一种很好的编程思想，这个我不否认。良好的代码让人看了赏心悦目，并且不需要注释，仅是良好的命名习惯就能将代码直接翻译成为自然语言进行解读。可惜，写代码的程序员不这么想。甚至包括我自己都觉得，代码嘛，能跑起来不就行了。管它那么多呢。毕竟我写的代码也没几个人看。
我相信抱着跟我同一想法的同行不在少数，这其实没什么。大家都是新人，等积累到一定程度，多看看多写写，知道哪些地方会有麻烦，然后越来越熟练，越来越得心应手。接着在与人交流或者教导新人的时候就能一眼指出不妥当之处，然后顺便收点好处……
这本来就是一个工程师慢慢的成长之路。自己的技术越发的纯熟，还有工资可拿，何乐而不为？
但是，有些人的良心可就是大大的坏了！
本着一种分享的精神，他们喜欢把自己那烂成一坨的东西拿出来进行大肆吹捧，然后给萌新小白说，这就是标准。接着这些人会越使用越困惑，于是这样的举动就坑了一轮一轮的人。
有的更加可恶，在新人的吹捧之下成为了所谓的大V，权威，专家。然后开个培训班，或者来场付费直播，或者卖卖书等等等等。
在互联网时代，很多行业都出现了这样的人。甚至有时候觉得这并不是所谓的互联网时代，好像到了偶像时代一般。
说回架构和编写代码这一块吧。
我的观点是：自己怎么顺手怎么来，别去强行使用什么架构，什么方法论。实践才能出真知，要写错了，测试一下改掉便是。忧虑意识要有，但是不要过度设计。在什么平台用什么标准，这当然是好的。要是喜欢自己定一套标准也不错，但是千万不要把自己的标准拿去套在别人的头上。另外，还是支持那些分享代码的人，毕竟我也不看。
