一位程序员的进阶Java阿里学习路线

     1.架构师应不应该写代码

　　合格的程序员对于明确分配的任务会完成的很好，但是大部分情况下“架构”这个词意味着架构师并不会涉及太多细节，架构图和代码实现之间总还是有些距离，你无法保证所有人都会正确的理解你的设计，或者是程序员写代码时遇到障碍时会立刻想出足够优雅的解决方案。

　　在我看来，写代码的架构师更像是在做后勤保障的工作：在代码中第一时间发现可能存在的问题，向其他人提出警告，或是给予其他人改进的意见，必要的时候或是给其他人演示一下正确的姿势。

　　大部分情况下我作为架构师并不需要揽下“核心模块”开发这种工作，毕竟我能调配的时间太零散了，效率难以保证，很多人在专注的情况下比我做的好很多，我只需要保持大局观需要适度参与就可以了。

　　总的来说，架构师和程序员在某些方面上有点像产品经理和用户的关系，大部分程序员并不会主动告诉你他们想要什么、哪里需要优化，甚至自己也不知道这些。想要做出好的产品，捷径之一就是跟用户做同样的事情。

　　2.为什么别人的系统总是那么烂

　　很多程序员解决问题的能力很强，说要解决一个什么问题，下午就能写出几百行代码把功能实现了。但是做出来的东西有种少考虑了什么东西的感觉。大部分程序都能实现功能，但是如果把“时间”这个也作为一个考虑的维度的话，就会意识到一个合格的项目需要考虑更多的东西：更通用的使用方式、易于理解的文档、简单而易于扩展的设计，等等。

　　很多公司应该都会有一些遗留系统，它们庞大、笨重、难用、几乎无法维护，所有人都在抱怨这些系统，并且每天都在想方设法换掉那些遗留系统。但是一段时间过去之后，又会发现身边的新人又开始吐槽当时替代遗留系统的那个系统了。

　　“大多数系统当初都很好使，功能当时够用，扩展性看起来也可以，但是这些系统都是开发的人离职之后变坏的。”

　　3.成为架构师最困难的门槛是什么？

　　很多人自称架构师的人跟你讲一个架构时简直滔滔不绝，各种技术名词像是说相声一样从他嘴里说出来，三句话不离高并发大数据，但是稍微追问一下，就会发现很多基本概念的缺失，例如自称精通高并发的人说不清楚他所谓的高并发系统的瓶颈在哪里，自称精通架构设计的人说不明白他的系统怎么保证高可用，自称超大数据量的系统实际上只有不到100万条数据，等等。

　　架构师虽然听起来很高大上，但本质上仍然是工程师，不是科学家，也不是忽悠人的江湖骗子。学习再多，也需要实践落地。设计架构方案更多的是在做一些抽象和权衡：把复杂的需求抽象成简单的模型，从功能、性能、可用性、研发成本等等方面规划如何构建一个系统，这些内容需要更多的实践练习。

　　4.如何更高效的学习？

　　大多数人每天能留给自己学习的时间有限，这个阶段如何提升学习效率就成了要解决的重点。

　　说说自己提升学习效率的心得，其实非常简单：体系化的学习。

　　在重复了几次痛苦的学习-梳理过程后，再去看一些独立的文章或者资料往往会事半功倍，因为能在体系内找到相对应的知识，甚至有时候一本书里一页只需要看一句话，点破那层窗户纸，就可以掌握新的知识。

　　跟很多人一样，刚毕业时我觉得作为程序员，只要努力，加上少许天赋便可以获得一些成绩。

　　工作一段时间后，对自己和其他人的认识也越来越清晰，逐渐的发现程序员之间的差距或许比人和猴子之间的差距还大，接受这个事实这让我郁闷了很久。

　　再过一段时间，发现自己已经能够客观的评价自己的能力，也意识到了距离并不是那么重要，只要想办法跑的更快，就足够了。

      分布式架构体系

　　分布式怎么来的。传统的电信、银行业，当业务量大了之后，普通服务器CPU/IO/网络到了100%，请求太慢怎么办？最直接的做法，升级硬件，反正也不缺钱，IBM小型机，大型机，采购了堆硬件。

　　但是互联网不能这么干，互联网没有那么财大气粗，还有很多初创，能不能赚钱还不知道。所以就有了软件方面的解决方案：分布式系统，简单说，就是一台服务器不行，我用两台、10台、100台...这就要软件系统需要支持。

　　那么多台机器，我如何让他们协同工作，这就需要一个调度中心（或注册中心）；肯定涉及到机器间通信，那么需要一个高效的RPC框架；一个请求过来了，如何分发，需要一个请求分发系统（负载均衡）；然后还要考虑每个角色都不能成为性能瓶颈；还有要能方便的进行横向扩展，还有考虑单节点故障。

　　并发编程体系

　　为什么需要并发

　　并发其实是一种解耦合的策略，它帮助我们把做什么（目标）和什么时候做（时机）分开。这样做可以明显改进应用程序的吞吐量（获得更多的CPU调度时间）和结构（程序有多个部分在协同工作）。做过JavaWeb开发的人都知道，JavaWeb中的Servlet程序在Servlet容器的支持下采用单实例多线程的工作模式，Servlet容器为你处理了并发问题。

　　误解和正解

　　最常见的对并发编程的误解有以下这些：

　　-并发总能改进性能（并发在CPU有很多空闲时间时能明显改进程序的性能，但当线程数量较多的时候，线程间频繁的调度切换反而会让系统的性能下降）-编写并发程序无需修改原有的设计（目的与时机的解耦往往会对系统结构产生巨大的影响）-在使用Web或EJB容器时不用关注并发问题（只有了解了容器在做什么，才能更好的使用容器）

　　下面的这些说法才是对并发客观的认识：

　　-编写并发程序会在代码上增加额外的开销-正确的并发是非常复杂的，即使对于很简单的问题-并发中的缺陷因为不易重现也不容易被发现-并发往往需要对设计策略从根本上进行修改

　　性能优化

　　性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。性能问题永远是永恒的主题之一，而优化则更需要技巧。

　　工程化专题

　　工欲善其事必先利其器，工具对Java程序员的重要性不言而喻现在有很多库、实用工具和程序任Java开发人员选择。下图列出的工具都是程序员必不可少的工具

　　微服务架构

　　微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年；

　　越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。

　　微服务架构（MicroserviceArchitecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的

　　类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

　　项目实战专题

　　对于所学的知识将用一个大型的电商项目来实践使用你的知识

       以上就是动力节点java学院小编针对“一位程序员的进阶Java阿里学习路线”的内容进行的回答，希望对大家有所帮助，如果对于学习Java的学习计划，怎么学才有效率，或者学完如果找工作的问题，请在线咨询，有专业老师随时为你服务。