在这一家公司的入职日期是8月8日。所以我很早就定下要在这一天写下点什么。
这是毕业后的第一年。这一年肯定是有进步的。
看了很多书，技术上的《从小工到专家》、《android源码设计模式》、《code complete》等等。
这三本书是我觉得很不错的，《从小工到专家》、《android源码设计模式》是进阶必读的书，能提升开发者的视野。
而《Code Complete》这本书则是讲的开发中的规范，让开发者确立自己的代码风格，真的是不可多得的好书。885页，太多了，我也没看完，于是挑了比较想看的几章看。《Code Complete》第二版出版于2006年，过去了这么多年，我今天看也感觉很受启发。
确实称得上是软件构建之实践指南。
其中的一些章节：
第三章 三思而后行：前期准备
做一个页面的时候，应该先把需要用到的切图和背景shape、layout布局都准备好，确保开始码代码的时候不再关心其它事情。
第八章 防御式编程
情况是后端返回的数据和约定的模型很多不一致，导致空指针，当时在一篇博文上看到这个词，比较符合项目的场景，于是才买了这本书。
第三十二章 自说明代码
注释方面的知识，教导如何编写有用的注释。
第三十三章 个人性格
由于近年来前端程序员的增多，许多人感到每天都在学新知识，不然就会被淘汰，也有一些公众号就这些问题进行解答。而当我看到这章的时候，才发现原来以前的开发者早就对这样的情况做过解答。
MVPVM
那时MVP正大行其道，基本上讨论架构的时候都是讲的MVP。不过我却先更深入的接触到了DataBinding，并一直使用到了现在，也让我认识到一个道理：
前端的主要作用还是展示 data，然后辅以一些流畅的效果。
数据才是核心。数据绑定感觉才是更适合android开发的模式，而其它的任何操作都是为了得到页面需要展示的data。由于android的数据绑定没有像前端那么完善，所以现在采用的是MVP结合MVVM的方式。有人把它叫做MVPVM，和AAC有点像，看到的时候吃了一惊，原来和谷歌大神想法差不多，当然肯定比不了。
RxJava
这一年也是大量使用Rxjava的一年，从以前只会结合Retrofit来请求数据，到现在几乎ViewModel里的数据处理都用到了Rxajva，并熟练掌握了大多数的操作符，结合databinding感觉任何事情都有事半功倍的感觉。对Rxjava的使用心得是:
就两点：1.线程切换 2.数据变换
可以把整个过程分为两个部分：工厂(Observable)和消费者(Subscriber)。
对于工厂来说，它的作用是把原材料经过层层加工，使它成为消费者想要的物品。而消费者就是使用这件物品来做自己想做的事情。
public class ExampleUnitTest {
@Test
public void addition_isCorrect() throws Exception {
String[] source = new String[]{
"1", "2", " ", " ", "5", "6"
};
Observable.from(source)
.filter(new Func1<String,Boolean>() {
@Override
public Boolean call(String s) {
return !s.isEmpty();
}
}).subscribe(new Subscriber<String>() {
@Override
public void onCompleted() {
}
@Override
public void onError(Throwable e) {
}
@Override
public void onNext(String s) {
System.out.print(s);
}
});
}
}
//Console:12 56
对于上面的程序来说，原材料就是source数组，filter是工厂加工的过程，subscribe代表工厂将物品交给了消费者，onNext代表消费者使用物品做其它事情。
设计模式
以前的自己对于这块比较薄弱，虽说看过不少设计模式的例子，但使用起来还是常用的那几种。而在学习了六大原则和《android源码设计模式》之后，才真正的刻意想把设计模式运用到实际项目中，而收获是巨大的。而我对于它的看法是：
就如同算法一样，设计模式也是一种算法，是解决项目结构问题的算法。
Java设计模式有23种，其实大家都需要用到这些模式，不过很多人选择了视而不见、舍近求远，做了很多无用功，偏偏还沾沾自喜。
架构
以前上github会star很多不错的自定义View，觉得效果不错。可以拿来用。后来更喜欢那些结构清晰明了的项目，也学会更多的去github上fork一些项目，看看其他开发者的实现方式，他们的架构设计然后学习并使用下来，在这方面真的获益良多，有了一定的架构能力。一个最大的体会是：
一个项目最闪光的点绝不在于它使用了多少新的技术，而在于它的结构是否清晰，能不能化繁为简。
就如初见clean架构时的感觉一样。
而我对于一个好的架构的理解是：
能让不同水平的开发人员写出风格相近的代码。
效率
怎么提高效率？如何提高团队开发的效率，是我最近一直在思考的事情。
以前听过一句话：
不要做没有效率的事情。
深以为然!
为此，我尝试从各个方面提高团队的效率。
- 从项目结构上。觉得写着太繁琐了，所以翻看了google的ToDo和其它优秀的项目代码，尽力去重构当前的设计。觉的每次都要建同样的几个相似的文件，于是学着去创建模板代码。尽可能的去统一写法，做好规范。
- 脚本文件。在一次做适配的过程之中，看到了一个项目EasyScreen，使用Shell脚本来自动生成了模式化的dimen文件，顿时感觉非常方便，因为以前无知的时候尝试过去手写，工作量非常大。而使用脚本既规范也非常轻松，大大减轻了压力，也因此学习了一段时间Shell，争取能够最大程度自动化。
- Mock。由于一些关系，后台服务不太稳定，或者前端团队开发的比较靠前，接口还没出来，但是数据模型已经约定。这时候一个好的mock服务就很适合了。尝试了几个前端的js之后，选择了Easy-Mock平台，很不错，搭配Charles效率提升了很多。
- Gradle。看了gradle的一些书籍和文章，对提升gradle编译效率也有了一定见解。
下一年
我要达到自己期望的水平
- Kotlin（就等AS3.0），AOP切面编程能熟练运用，编写出高质量的代码，尽量写多的单元测试。
- 争取向全栈发展
终极目标
独立开发者
