【突破瓶颈】——十年Android架构师教你如何正确看待焦虑和迷
程序员一旦焦虑或者迷茫以后，就会对成就感的获得大大降低。长久这样就会导致动力不足。但是现实产生焦虑的原因经过前面的分析，也是客观存在的。那我们应该如何面对呢？
在技术的更迭变化过程中，如果一味的跟新技术，那你是否想过，追随新技术的到底是为了什么？是为了跳槽或者转岗？还是为了提高薪资实现人生理想和自我价值？这两个理由都是正确的，需要注意的一点就是不要盲目追随新技术。一味地盲目追随只会导致最终沦为技术的奴隶。我们需要做技术的主人，更加从容的面对技术的变更。
如何选择？如果在不转岗的情况下，在没有目标的情况下，去学习一些本职工作中可能用不到的知识，可能就有点“盲目”。这些知识学习的过程中也许不够高效。不高效的学习又遇到了别人高速的成长，一比较，新的焦虑又会产生。这里我有切身的体会。
当你一直投身一个项目且开发工作很饱和时，有时候你会对这个项目感到厌倦。相反，如果同时开发多个项目这有助于保持开发热情，如果你厌倦了其中一个项目，可以转到其他项目。这样，你将永远在前进，能够持续开发应用程序。
然而，同时进行多个项目最大的好处是你的成长速度很快。你有多种观点，多种思路、多种方式来解决问题，最主要的是能够获得很多动力。
开源是一个社区，你可以结识优秀的人，也许可以吸引一些贡献者来参与你的项目，如果你够幸运，甚至有人会聘用你。事实上，开源是最大的开发者社区，如果你愿意，你可以学到很多东西。
优秀的开发人员用编程来思考和表达。如果你告诉我一个想法，我不会认为这是一个想法，而是将它开发成一个应用程序。一旦你做到用代码思考，用代码说话，那么你就是一名真正的开发者了。
学习永远没有错，错的是选择了低效耗时耗精力的前进方向
迷茫的来源有二个，一是看不到自己对公司的价值，二是看不到自己未来发展的路。
先说迷茫的来源一，看不到自身的价值。很多人每天在公司写业务，俗称“搬砖”，每天都搬，感觉一点长进都没有。回过头来看框架部门的人或者自己部门的研究员，每天都在研究或者做一些框架或者工具。当有大量的人使用的时候，就会很有成就感。并且认为业务没啥技术含量，业务里面的逻辑和流程在换了一家公司以后就没有任何优势了。这种想法其实是不对的，是错误的片面的。
再谈谈迷茫的来源二，看不到未来的路在何方。这个迷茫我觉得来自于对自身的定位不明确。一位老师和我说过，毕业后的头5年，你可以去选择各种开发，前端后端或者移动端，可以随便选。这是为了什么呢？就是为了找到自己感兴趣的和自己的长处并且打算一辈子一直做下去的方向。如果你还看不到自己未来发展的路，那么可以考虑把眼界放的更广一点，去找寻自己真正感兴趣的方向。所谓真正感兴趣的，是指如同熬夜打游戏一样毫不困倦，如果某个方向你能做到不是公司强迫你加班，自己写代码写到深夜或者通宵也毫不厌倦，那么这一定是你感兴趣的。方向一旦确定就不会迷茫，朝着目标狂奔吧。
业务和架构如何选择
程序员里面也许会存着这样的鄙视链，写架构的鄙视写业务的。这种鄙视是有失偏颇的。
首先，绝大多数的公司的收入来源是来自于公司的业务。除去一些极少数的公司。写业务的同学不必觉得业务没有存在价值，你们应该明白，你们写的业务是替公司赚钱的。
当然，能在公司里面写内部框架或者工具的同学，技术一定积累到一定深度了。框架和工具没有平白无故的产生，它们的诞生都是解决问题或者痛点的。要么解决开发中的痛点，要么为了提高开发效率。试问如果没有对开发有一定的了解和认识，如何去深刻的理解和感受这些痛点？不理解它们，也做不出能解决问题的框架或者有用或者好用的工具。
我认为能写框架或者工具的，一定在技术上有一定积累，并且能理解和看清开发中或者业务中的一些痛点。于是乎开发出了解决这些问题的东西。
至少目前国内的大多数公司都是无法缺少写业务的。小公司为了生存可以缺少写框架和工具的，但是不能缺少写业务的。大公司更加是需要写业务的。目前国内好像还不存在不写业务的公司。如果纯写框架或者工具给其他公司使用，以此赚钱，那么这些也就成为了这个公司的业务。
再谈谈对架构师或者更高级的职称的理解
架构师的工作是以解决业务问题，推动业务增长为基础，在此之上改善公司的架构，使之能对外提供更加优秀的性能，并具有对人、技术、业务的组织统筹能力。
在我们的 BU 里面专门有一个架构组，里面的人全是 P7 架构师以上级别。他们的工作内容是什么呢？就是提供能解决当前开发痛点方案的人。我与他们交流过，他们虽然对业务没有理解到每行代码逐字逐句的代码行，但是对公司整个业务流程，数据流转，有一个整体的认识。他们对业务的认识更加深刻，比我们只负责单一业务理解层次更广。他们在此基础上还能解决开发中的难点和痛点，对 BU 部门的业务发展还能提供自己的思考。架构师们还具有自主发现业务价值的能力。
也许大家会认为架构师不写代码，但是他们需要出解决方案。解决方案一定程度上比写代码还要难。解决方案的灵感来源于什么？来源于对公司业务的深刻理解和技术的深厚积累。缺少对业务的理解，提出的方案可能就是不完全适合这个公司的。缺少对技术的深厚积累，提出的方案性能可能就不是最好的。
技术分工的不同和统一
前端的数据来源来自后端，前端更加偏重 UI，交互，设计。后端更加偏重接口性能，数据的正确性。但是随着云基础设施的逐渐完善，后端的基础设施都挪到云上了，这部分的配置和管理都变得异常的轻松，这一切都交给云了。
现在前端框架和浏览器发展的突飞猛进，业务上一部分逻辑都直接在前端做掉了，即使现在前后端分离，前端在公司中承担了越来越多的角色了。有这样一个笑话：大前端工程师对后端工程师说，你们后端不就是一个写接口的嘛，吐吐字符串。后端工程师对大前端的工程师说，你们前端不就是搭搭页面嘛，前端就是一段漂亮的字符串。虽然他们说的都不准确，但是也从侧面抽象了他们工作的内容。
所以前端和后端分工不同，但是他们还是合作的关系，缺一不可。
高效的学习方法
为何高效？在实践中学习。利用公司真实的项目锻炼自己，学习特别高效。每天项目中遇到的问题，上下班在地铁上都会很有目的的在网上查询解决办法。学习目的非常明确。
总结
程序员如何在技术浪潮的更迭中保持较高的成长速度 ？我的答案就是在公司的项目里面去实践是成长最快的。首先业务的迭代排期会让你的学习不拖拉，在排期中必须要完成指定的任务，这对学习进度有了非常好的保证。其次，实际项目中的实践能让你对语言的熟练程度，语言的生态环境，开发过程，查找 bug 流程，监控各个方面都有实践经验。而且实际项目中还能让你遇到各式各样的坑，坑踩多了就成长了。但利用工作之余的零散时间去系统的学习巩固基础与自己所掌握的技术也是非常重要的一个关键，在学习中提升，在实践中成长
