前言
距离写上篇博客已经有一个月了，年后由于岗位调整转去写后台，开发框架、开发模式的不同让我适应了好一阵子，更难的是后端开发与客户端开发的思维习惯的转变。
客户端开发的侧重点
在我看来，客户端开发最重要的是：
- 业务流程的理解与建议
- 交互方式的理解与建议
- 数据的展示（快速、高效）
- 数据的获取（用户主动输入、UBT 采集）
- 保证应用的性能（内存、弱网、耗电）
实际工作中，产品经理拿到业务需求后会分析背后的真实需求，提出解决方案，然后与研发沟通是否能实现：
- 如果是偏交互方式的，一般是找客户端开发沟通；
- 如果是偏业务流程的，一般是找后端开发沟通。
相较而言，“业务流程”当然比“交互”更为重要。不管是移动应用，还是WEB 网站，在满足用户最基础的需求之后，才有资格谈体验。
水彩笔都学不出字儿了，谁管你颜色多漂亮。
因此，上面的前两点中我强调的是 理解与建议。
在拿到原型图、设计稿时，其实业务流程已经基本确定了，客户端要做的基本上是照着设计图实现效果。
后端开发的侧重点
在长期习惯了客户端开发后，转入后端开发没几天，就被我司架构师怼了一顿。
原因是我在写接口时，除了增删改查，不知道还能写什么，去问架构师C 哥，C 哥让我“自己想需要什么接口”。
( ・◇・) ？自己想？原型图都没有，我哪儿知道需要什么接口。
此话一出，C 哥眉头一皱，语重心长地对我说：“服务端开发，重点就在服务二字！你有增删改查多个数据的能力，如何将这些能力组合起来，尽可能多地为其他人提供服务，才能发挥价值。很多时候服务端启动开发时，原型图还没设计好呢，难道你就不写了？你应该从不同业务场景，思考对不同业务系统需要提供哪些数据，设计能处理更多要求的接口！”
“自己思考能提供什么服务”，这点上就和客户端开发大不相同。
根据我对服务端的了解，服务端开发时的主要流程有：
- 从不同业务场景，思考对不同业务系统需要提供哪些数据
- 设计数据库表结构
- 层级拆分，模块拆分
- 设计能处理更多要求的接口
- 实现接口
浮躁的心
虽然我在上面夸了半天后端，但实际上，在写这篇博客之前，我的心已经纠结、痛苦了好长段时间。
痛苦的是公司要我离开自己擅长的安卓开发，去做后端。
做后端就做吧，能好好学后端开发也不错。然而最近业务紧，天天写业务代码，一点儿意思都没有。
虽然我很认同业务抽象、建模能力的重要性，但这一定是以扎实的技术为基础。
借用知乎上一位前辈说的话：
现在架构师大部分都是业务架构，用现有的技术傀儡搭建。比如选型的时候参考xx网的技术架构或者认识人在里面给你说下他们系统的架构，然后自己用 zookeeper redis 等等各种存储和中间件搭建一套系统。
平台架构是设计 Netty Dubbo 这些中间件并能带领牛逼开发一起实现的神人，平台架构是非常非常少的，需要阅读大量开源代码和积累多年开源经验才有机会做到，写了几年业务代码天天 get set if else foreach 是绝对做不到的。
因此我很纠结，究竟是要继续走下去，还是回归安卓，把安卓做精通。
内心辩论、抉择了许多天后，突然有一天，我看到了我的中级软考《软件设计师》证书，想起了当时报名这个考试的初衷。
架构师之梦
早在开始学习编程时，我就有个愿望：成为一名架构师。
那时对架构师的定义很模糊，只知道普通程序员是搬砖的码农，而架构师就是绘制盖楼图纸的人，所有程序员都得听他的，好威风啊！(:3 」∠)
大二时学校有朋友告诉我“软考”这个考试，里面有个高级别的考试“系统分析师”，它的要求让我感觉很接近架构师：
根据系统分析师百度百科的介绍：
系统分析师是计算机行业的高级人才，是一个大型软件项目的核心领导者，他的主要职责是对软件项目进行整体规划、需求分析、设计软件的核心架构、指导和领导项目开发小组进行软件开发和软件实现，并对整个项目进行全面的管理工作。
系统分析师的工作职责决定了他必须是计算机行业各个领域的精通者，因此一个合格的系统分析师，能够精通各种计算机前沿理论、具体的软硬件开发技术、大型数据库的知识、项目的整体规划和框架设计、模块式设计和开发技术、数字化建设知识等等。
系统分析师具备在一个信息化项目从立项到正式上线整个过程中，在过程的各个不同阶段担任不同的核心角色的能力，其中最为重要的能力就是系统架构的整体设计能力和详细设计能力，这个能力直接关系到一个软件项目的成败。
碍于个人能力以及系统分析师考试的要求，当时的我选择了先报考中级。
一晃眼毕业快一年了，随着对 IT 行业的逐渐了解，我逐渐意识到：展示数据可以有 app、网页、微信公众号、小程序等多种平台技术，但处理数据，必须依赖一个强有力的后台。
终于明白为什么架构师一般都是做后台的了：后台决定了业务！
跳出局限
人们常说：
黑夜里行走，需要仰望星空才不至于跌倒。
从事编程其实也很相似，如果我没有想起自己当初的目标，只是想着当下的得失，恐怕会一直活的不开心。
Android 也好，后端也罢，其实并不矛盾，都是我通往目标可以走的路。
我会努力把一个学精，然后横向拓展的。
总结
最近内心积攒了太久，不知不觉扯了这么多。
写博客还是有很大益处的，让我能冷静思考反省，而不是因为工作上的变动就胡思乱想，看着各种各样的文章眼红、纠结。
借以此文警醒差点忘记目标的我！
其他
《系统分析师教程》图书目录（平时积累相关知识）：
- 第1章 绪论
- 第2章 经济管理与应用数学
- 第3章 操作系统基本原理
- 第4章 数据通信与计算机网络
- 第5章 数据库系统
- 第6章 系统配置与性能评价
- 第7章 企业信息化战略与实施
- 第8章 软件工程
- 第9章 系统规划
- 第10章 系统分析
- 第11章 软件需求工程
- 第12章 软件架构设计
- 第13章 系统设计
- 第14章 系统实现与测试
- 第15章 系统运行与维护
- 第16章 新技术应用
- 第17章 嵌入式系统分析与设计
- 第18章 系统安全性分析与设计
- 第19章 系统可靠性分析与设计
- 第20章 项目管理
一些知乎上关于“如何成为一名架构师”的回答：
- 其实和代码水平无关，看你占在什么高度看问题。不过不写代码，可能没人敢让你沾架构。
- 通过接触这些优秀项目的开发者，了解他们解决问题的方法会让人受益终身。
- 一个架构师，如果没有对技术的敏感度和前瞻性，一直抱着一套技术架构不变，估计很快会被淘汰。
- 现在的软件开发封装的层次已经非常高了，只要学会 Java 就能做一个编程工作了，随着你做的越来越深，越来越专，这些基础的问题就会浮现出来。更重要的是，计算机软硬件的基本思想在这几十年里其实变化不大，例如缓存，增加抽象层等，有了这么基本的思想的武装，去学习新的东西不但学的快，理解的会更透彻。
- 理解了技术的本质以后就能够触类旁通，就能够快速学习，这在技术更新很快的软件行业尤为重要。 只是学会使用是不行的，不但要知道how，还要知道why。 停下来，思考，才是进步的本质。设计模式一直强调的『发现变化并且封装变化』其实就是这个意思。
- 抽象能力的训练没有捷径，就是经验的积累，勤于思考和学习。例如：学习Android的程序员可以思考下Android是怎么对未知的，纷繁复杂的应用程序进行抽象的？为什么有Activity、Service、BroadcastReceiver、ContentProvider这四大组件？