‘壹’ 如何从初级程序员过渡到中高级程序员
在程序员圈，一直流传着这样一个传说，用发量来判断程序员的级别，这明显是种调侃。那么，中级程序员，相对于初级程序员，有哪些不一样的特质呢？
总得来说，比较于初级而言，中级程序员在执行层面属于攻坚力量，他们不仅能独立完成高档难度的开发使命，并且在用户体验（质量提高）和功能优化（优化效率）都能作更全面的考量。
以下，是小编总结的关于中级程序员七大特点，各位可以对号入座。
（一）善于沟通
程序员内向的居多，喜欢交流的很少，但中级程序员往往能够克服自己的内新的恐惧心理，多和同事交流。
甚至有管理者认为，程序员应该80%的时间，花在同事的交流上。不仅是部门内的同事，也还包括跨部门沟通，敲代码的需要经常与产品经理、运营的同事沟通需求。
日本不少跨国公司，甚至有让程序员去体验几个月销售员的传统。公司要求，程序员在敲代码的同时，也要能够理解一线用户的需求。
交流对于初级程序员了解技术的发展，也相当有好处：读读博客、学学新语言和框架、讨论讨论话题、看看同行在做什么。自扫门前雪，很难成为一个优秀的程序员。闭门造车型的程序员终将被时代的潮流所淘汰。
（二）对编程有激情
有些程序员干这一行只是为了挣钱，如果有更好的职业，他们会毫不犹豫的辞掉程序员的工作。
能够顺利晋升为中级程序员的人，往往热爱编程，喜欢钻研代码中的问题，他们感到能指挥电脑来帮助人们和自己解决现实生活中的问题是一种神奇的能力。当遇到问题无法解决时，他们会茶不思、饭不想，无法入睡。
每个人都有心理上的舒适区，但是中级程序员，会不断地突破自己心理上的舒适区。
他们很乐于经常去研究没有接触过的代码，也正因为这样，成长速度快的中级程序员会越来越熟悉不同的代码结构和设计模式。
（三）精通代码调试
几乎所有的程序员写代码都不是一遍就能写好的。精通代码调试 ( debug )很多人在写代码的过程中，经常会有的一个问题就是：为什么我写出来的代码不能运行？为什么运行的结果不是我想要的？
中级程序员非常快的就明白自己代码的问题可能是什么。代码调试是一个很重要的能力，但是偏偏学校里不教，面试的时候考官也不经常提及。那么怎么去调试代码呢？
代码调试是有一套方法论的。最简单的就是在代码里输出日志来判断，复杂一点则需要去接触一些高级的工具，或者直接带有 Debug 功能的编辑器。
（四）主人翁精神
部分初级程序员刚入行，可能还没有进入状态，往往认为自己是打工者，以打工者的身份和心态工作。
中级程序员却会把自己当成企业的主人，他们知道企业的利益和自己休戚相关。
成熟的程序员明白一点，作为一名优秀的企业员工，自己是生产者而非消费者。他们心中一直想得是自己能够为公司，为顾客创造什么价值，而不仅仅只想着待遇。
（五）工具型思维
中级程序员知道如何能更高效的完成任务，如何更能有效的解决问题。其原因是工具型思维，如同荀子所言，“君子生非异也，善假于物也。”
Facebook 前技术总监 Bobby Johnson 说，高效率的程序员都把时间花在制作工具上。很多人也认为工具是很重要的，但是他们并没有花时间去制作、整合自己的工具。但是，Jonson 团队最出色的员工耗费了他们 1/3 的时间在工具制作上，这些工具可以用来发布代码，监控系统，以及能让他们花更少的时间去做更多事情。
中级程序员遇到问题时，不钻牛角尖，善于利用外部工具解决自己的问题，特别是能熟练应用搜索引擎。
（六）刻意练习迭代速度
魔鬼在细节上，如果一个程序员想要提高自己的工作效率，就需要他能够不断地在细节方面，进行微创新，提高效率。
举一个例子，假设一个初级程序员，每次要花 12 秒钟去搜索某个函数是在哪里定义的。如果，他每天做这个动作 60 次，就要花 12 分钟去搜索函数定义。
中级程序员会选择用一个好一点的编辑器，每次找到函数定义只要 2 秒钟，那么他每天将节约 10 分钟，每年节约 40 个小时。如果能够找到 3 个这样的场景去优化一下，那么对于中级程序员来说，每年可以节约一个月的时间。
（七）系统学习
学习是要有方法的，尤其是在职场中，程序员的自我学习要符合两点要求：一是有结果；二是高效。因此，系统性学习，非常重要。
高级程序员系统学习指南如下：
第一步，源码分析。看看大牛是如何写代码的，提升技术审美，提升核心竞争力。
第二步，工程化。工欲善其事必先利其器，不管是小白，还是资深开发，都需要先选择好的工具，提升开发效率和团队协作效率，让自己有更多的时间来思考。
第三步，分布式。从深度到广度的完善自己的知识体系，准备迎接高并发大数据的挑战
第四步，微服务。绕微服务的通用模式，学习spring Cloud的常见用法及原理，让微服务的开发更加方便 快捷，让微服务应用更加稳定 可用。
第五步，性能优化。从JVM底层原理到内存优化 再到各个中间件的性能调优，做最科学和最严谨的性能调优。
第六步，并发编程。深入了解底层原理，不只是做一个开发者。
第七步，积极参加大牛的分享。
（八）总结
可以理解，对于初入职场的程序员来说，他们在内心也知道学习的重要性，但因为没有时间，被老板的需求给填满，没有精力去提升自我。
然而，根据人类的学习曲线来说，任何一门新的技艺，都是一条对数曲线。其分为两个阶段：缓慢期和高速发展期，即初期很慢，后期进展迅速。
如果，能够让程序员在刚进入职场的时候，便摆脱初级程序员的桎梏，直接拥有中级程序员的实力，是不是就能跨越学习曲线的缓慢期呢。
知名IT教育机构传智播客已开通了中级程序员课程，发布了全新的项目，想学习的小伙伴抓紧
‘贰’ 软件架构入门-分层架构、事件驱动、微服务架构和云原生架构
软件架构（software architecture）就是软件的基本结构。
合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》（PDF）， 介绍了五种最常见的软件架构，是非常好的入门读物。
软件架构就是软件的基本结构。架构的本质是管理复杂性。 如果你觉得架构不重要，可能是你做的事情不够复杂，或者是你没有管理好复杂性。架构模式虽多，经过抽象沉淀之后，也就那么几种：
1. 分层架构（比较传统的单体架构）
2. 事件驱动架构 （一般适用于应用局部场景，用来实现异步解耦）
3. 微核架构（又称插件架构，开发难度较高，一般用来做工具软件开发，如Eclipse，不太适合分布式业务场景）
4. 微服务架构（当前比较流行的服务化架构，解决单体架构面临的问题，适合敏捷开发，快速迭代）
5. 云架构（现在的说法是云原生架构-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架构）
在原文的基础上，我按照自己的想法，进行了小幅调整。
分层架构（ layered architecture ）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。
这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。
虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。
有的软件在逻辑层（business）和持久层（persistence）之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。
用户的请求将依次通过这四层的处理，不能跳过其中任何一层。
优点
缺点
事件（event）是状态发生变化时，软件发出的通知。
事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。
事件驱动架构（event-driven architecture）核心组件：
对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。
优点
缺点
事件驱动架构在通信产品中应用得也非常广泛，典型的如状态机处理。 事件驱动架构不适于做顶层架构，但适合做局部实现，几乎遍布在通信软件的各个角落。
微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。
优点
缺点
微核架构的设计和开发难度较高，这就注定它在企业产品中用得不多，虽然它的优点还不少。
微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。
微服务架构分成三种实现模式。
现在开源的微服务框架比较多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。
优点
缺点
云架构（cloud architecture，现在的说法是云原生-Cloud Native）主要解决扩展性和并发的问题，是最容易扩展的架构。
它的高扩展性，主要原因是可以基于云上计算资源弹性伸缩。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元（Docker容器）；访问量减少，就关闭处理单元（Docker容器）。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都独立分库。
这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。
虚拟中间件又包含四个组件：
随着Docker、Kubernetes等容器化技术的快速发展，上述关于云架构描述有点陈旧了。当前最新的云原生架构，以Docker+Kubernetes为核心，尤其是容器编排Kubernetes 已经成为事实上的行业标准。
云原生架构图的主要特征：
主要目标：
1. 让开发人员聚焦业务逻辑的实现，其他交给容器云平台来完成；
2. 支持业务系统的快速迭代，支撑业务的快速变化和发展；
3. 构建以共享服务体系为核心的业务中台；
下面是我针对某新零售企业设计的云原生架构图，以云和微服务架构为基础构建云原生应用，这里云可以是公有云、私有云、混合云等等。
以上是从不同的视角，对架构进行了分类。实际应用中，各种架构并不是孤立的，可以根据业务环境和业务诉求，对各种架构进行综合和嫁接。每种架构都有其优点和缺点。优点不必多说，缺点则几乎都是通过工具工程（比如自动化发布工具、自动化测试等等）能力的方法来规避，工具工程对软件架构非常重要。