来新公司三个月了，提前一个月转正，总体上都进入了正轨，我的工作因为是在架构组工作，所以技术的沉淀也是工作的一部分。这几个月的学习工作，让我对自己的行业有了更深的理解，对 Android ，对团队，和对技术，都得到了一些以前从来没有过的理解。
业务还是架构
作为一个移动端开发工程师，如果是单纯的做 UI ，那么工作将会比较繁琐和枯燥，而且重复性工作也比较多，对于技术的提升也比较有限，作为移动端开发工程师的初期，确实是需要大量的业务代码作为练手。作为个人发展来看，如果你是喜欢产品，对产品本身很感兴趣，那么 UI 开发可能是你需要多多关注的。你可以多学习一些炫酷特效的制作，那么自定义 View 这类的知识就特别重要。当然一些设计元素也是你需要关注的，Andorid 和设计相关的一些技术方面就有不少，比如 Material Design 和 Lottie。
如果你对技术本身很感兴趣，那么，可能源码是你的伙伴。曾经我也是一直在写这些业务和 UI，但来了我们公司，我作为一个架构组开发成员，业务上的开发任务不是很多，对于我来说是一个新的挑战。可是我们是小公司，肯定不能像 BAT 那样，你做架构开发的，只需要考虑自己的那部分架构代码就行了，至于业务程序员怎么用，我们不用关心。简而言之就是造轮子。在我们公司，因为开发人员不多，而且这种架构组业务组分布式开发的开发模式还不够完善，大家都比较忙，都有自己需要做的活，所以即便作为架构组，开发好了一个「轮子」，Leader 也会要求你把轮子使用到业务中，这就会产生一个问题：往往架构开发人员不一定对某一块业务代码比较熟悉，那么去使用自己造的轮子的时候，首先得先熟悉一下别人写的业务代码。这是一个非常消耗时间和经历的过程，甚至在开发和理解对方代码的过程中也需要让对方来协助开发。
看懂业务代码不一定会对你的技术提升有多少帮助，但肯定是对你日后的工作是有帮助的，我自然是明白这种道理。但客观的说，这种模式的开发效率并不高，但在中小型互联网公司中，又是很难统筹的一件事，大家都有很多工作要做，业务开发人员也会有集中的开发任务，作为架构组成员，正好也可以通过这个机会熟悉一下项目的代码。
在一次版本总结会中，我针对这个问题也和 Leader 交流过。我认为架构组的服务对象就是业务组的程序员，我们造出来的轮子需要让大家方便的在业务中使用，能够更加清晰将业务逻辑和一些服务架构划分开来，帮助团队更加高效和有层次性的开发。所以架构组成员在做好轮子以后，一定要花精力去详细书写一段 API 使用文档，并在业务程序员开发使用的时候给予一定指导。如果项目情况特殊，要求架构组成员自己将轮子使用到业务中，那么原生业务开发成员一定要对接好，将架构组成员修改过的业务代码重新 review 一遍，这本身也是对轮子熟悉的过程，也是架构成员对业务熟悉的过程。
开发模式
这三个月，我最重要的一个开发任务就是将现有的项目进行分层化和模块化。
分层化就是将项目整体分层，从底向上逐步和业务靠近。比如，我们项目从上往下现在被分为 4 个模块：
- 设备服务层
- 基础服务层
- 功能模块层
- 业务逻辑层
4 个模块从最底层到最上层，是一个依次服务的关系。
比如，设备服务层里面是一些获取设备基础信息的一些工具类和方法，例如获取 CPU 型号，系统版本，屏幕宽高等。这一层的类和方法可以单独抽离出来上传到 Maven 库中供以后所有的项目使用，具有很强的同质化能力。下一层的基础服务层也有这样的特性。
基础服务层是一些常规的公共工具类和方法，例如获取时间、地点、网络状态一类的工具。
功能模块层实际上已经和业务有一定挂钩能力了，但为了和业务解耦，所以一些在项目中比较重要的或者使用比较频繁的功能模块就得单独抽离。往往一个互联网产品公司如果有多个移动端 App 项目，往往他们功能上都有一定的重合性，那么这部分重合功能的封装就可以作为一个独有的功能模块抽离出来，并同步进行开发和版本管理。举个例子，我们公司是一个互联网金融公司，公司会关注一些行情和指数，这些指数通过一个展示界面进行实时更新数据，这些报价数据需要和服务端维持一个TCP 长连接，那么这个 Tcp 长连接对于我们公司来说就是一个非常重要的功能模块，把它抽离出来单独管理不仅可以帮助项目进行解耦也可以让功能模块开发者更好的管理自己的模块。
业务逻辑层就是最上层的业务代码了，它使用下层的那些分层和模块来进行业务开发，如果分层化和模块化做的好，业务逻辑层开发将会少走很多坑。当然不是说业务逻辑层就不需要一些架构上的整理，这两年 Android 的 MVP 和 MVVM 就是业务层架构上面的优化。实际上业务逻辑层是一个项目中花时间最多的地方，如果想提高业务层的开发效率，除了一些团队统筹上的要求以外，代码的规范性和良好的设计性也是非常重要的。项目中有一些地方的数据结构在多线程情况下非常容易出问题，然后我就试图改变一下这些 Map 的数据结构，但发现项目中的所有变量声明和方法参数的调用都是用具体类，比如 HashMap，ArrayList。如果我改一个地方，所有地方的参数都得改动，总而言之就是代码没有遵守良好的设计模式，平时开发中一定要注意利用好里氏替换并注意写的一些调用方法要遵循开闭原则。
在给项目做分层化和模块化的过程中，团队要求使用 Maven 来管理这些 Library，可以具备一定的代码安全，并且可以缓解项目中有大量 library 在目录中的情况。之前通过 module 方式管理这些子模组有一个非常大的问题就是版本控制，Git 上管理依赖子模组有一定的难度，如果开发组的小伙伴对 Git 子模组理解不深，在协同开发的时候就会经常出现版本控制上的问题。
不过有利就有弊，用 Maven 开发的话如果需要和业务代码协同测试，那么你每次修改过之后都需要上传一个 snapshot 版本，然后再通过改变项目中 gradle 文件的 compile 代码来进行测试，我们知道，如果你修改了 gradle 文件，那么你就无法使用一系列增量编译来提高编译速度，然而在项目体量很大的时候，如果你每次改动都要通过全量编译来测试代码，那么开发效率只能用令人发指来形容，每天在编译上花的时间就要超过 1 小时，这是难以接受的效率牺牲。所以现在还在想办法，看看有没有更好的优化方案。
对自身技术沉淀的思考
最近，在技术圈，深度学习，人工智能，机器学习是目前最前沿和最火热的技术，毫无疑问是未来十年计算机科学的风向标，老实说，移动端已经走向了下坡路，我身为一个移动端开发工程师，如果说没有被这些客观因素影响到心态那是不可能的，我也做了思考，有了一些自己的想法。
最近阿里巴巴又办成了不少大事，似乎马云曾经所期待的那种社会正在慢慢的实现。阿里巴巴先是在几天内分别和天津、福州签订了协议，进行无现金城市的推进，然后又规划了无人售卖咖啡厅和无人售卖超市。看到阿里巴巴做的这些，我深深的感受到了震撼和激动，这是一个真正走在时代前沿的企业，它所做的一切已经脱离了一个资本企业传统的运营意图，而是往更高的立意和角度上靠拢，它在为人类发展，社会进步而努力。阿里已经和亚马逊、谷歌这类巨头公司一样，引领着人类社会的进步。
我心想这真棒啊，如果我写的程序，我研究的技术能够为这个社会，为人类的进步带来如此大的改变，甚至不要求有这种巨变，只要能稍微的贡献一点力量，然后通过身边生活的变化，感受到自己的贡献，这真是一种奇妙的感觉。这几天我好像着了魔，越来越期待能够有这样的机会和能力了。
但回到现实，做移动端好像很难具备这样的能力，现在做的事实际上是为公司服务，是为老板服务，或者是为客户服务，虽然也给这些人的生活带来了一定的改变，但这样的改变有限，立场也是没有那么的高大上。有那么一瞬间，我甚至有点失落。但我后来经过深思熟虑我才领悟到，没有人能一蹴而就的，即便是那些已经在做深度学习，人工智能那些人，他们也一定经历过慢长而枯燥的积淀过程。而我现在做的，并不是像我上面想象的那样狭窄。
我可以通过深入的学习 Android 的各种技术，从 UI 到架构再到 framework ，这本身就是一个庞大的知识体系，实际上我现在连沧海一粟都没看到，一个事情做精才能有所作为，所谓的移动端不火热，需求饱和，实际上只是针对初级工程师的，高级 Android 工程师的需求量依然很大，他们在公司的地位也非常高。总而言之，我应该珍惜现在的工作，并且继续不断的在这个领域上努力。
同时，在技术界，不断的追赶时代的潮流永远是对的。我现在已经在学 Kotlin 了，并且下周就会有 Kotlin 的开发任务，这是我们团队第一次尝试，Leader 也把这个光荣的任务交给了我，让我先行一步。我现在还在研究 Java 并发编程和 JVM，争取能够把项目上所有并发问题进行大包大揽式的处理。JVM 的学习也会让我对系统和虚拟机的理解更深一步，帮助我扩展在写代码时候的思维广度，写出更高效的代码。同时也为我以后研究 framework 打下坚实的虚拟机技术基础。
最让我感觉开心的是，我已经开始学习深度学习。我享受钻研数学和算法的过程，我真实的感受到，我正在进入一个技术学习上的良性循环，学习使我快乐，因为获取了快乐，所以我更希望学习。
听说程序员身上蕴含着很强大的力量，他能通过手中的键盘改变世界。不知道从什么时候开始，改变世界，真的成为了我的梦想。
