程序员成长之路理解与分享
此文章来源于java陆总监的分享，荷逸进行了部分修改
到底该如何成长？新手入行怎么成长？3-5年如何成长？6-8年怎么向架构师发展？
这个问题是程序员需要考虑的的问题，不管是刚入行的，还是工作了一段时间的，或者是工作了比较长一段时间的同学，都有这样的疑惑。
我想和大家讨论几个问题。
是什么技术好？
你认为是什么技术好，八股文背的好？精通各种中间件？还是会做架构？会设计模型？能解决疑难问题？
我来说一下我的理解，我认为的技术好是能够以负责的态度去工作，做任何一个需求都有详细的思考，想清楚前后逻辑，能让你很放心的把一件事情交给他去做。
工作中遇到过两位这样的同学。他们俩有非常相似的优点，性格都偏内向，不善言辞，做事很快，很负责的。从不推诿问题，让我很放心的把事情交给他们去负责，基本上我不用操任何的心。但是他们俩也着相似的缺点。不太会背八股文，对于各种中间件不了解底层，会用。也没有做过架构工作。他们俩都是非常出色的执行者，软件工程师。但是虽然他们有着这样的缺点，我依然很乐意把他们归到技术好的一类人里面去。
所以我们回到那个问题本身，大家问我怎么成长，特别是刚入行的同学、3-5年的同学，大家需要先能成为这样的人，从责任心，到工作态度，到编码能力，这是第一步。先成为那个别人觉得你可靠的人，成为一个能安心把事情交给你负责的人。我们这个社会太卷了，太注重所谓的技术了，以致于大家都忘了技术本身是工具，忽视了对人的关注度。
需要具备什么能力？
如果要达到上面2个同学的要求，你想想看，你需要具备什么能力？
1.长时间扎实的编码功底
做到这一点不是光写代码就OK了，需要写完之后不断review，不断学习别人的代码风格，需要写代码的时候动脑子，可能还需要学些一些设计模式。
2.沉下心写代码，主动发现自己代码中的问题
阿里巴巴规约插件装了吗？sonarLint插件装了吗？自己写完代码之后，用插件扫描一下，能发现大部分的问题。
代码中涉及到一些重复的部分，能不能抽象一些方法？
一般按照我的代码风格，但凡设计到2个地方的使用的我一定会抽象出一个方法出来。
让代码优雅一点，字符串判空用什么方法，list判空有没有做用什么方法，从数据库查询出来的列表都要做判空处理，这一点意识到了嘛？
异常处理到底怎么做？什么地方要处理异常，什么地方要抛出异常，这个问题有没有想通？
注释呢？注释写清楚了没有，不光提醒后来人，也提醒自己代码的逻辑。
其实你会发现真的写好代码不是一件容易的事情，所以刚入门的同学，好好提升自己的代码质量
---------------------------------以上是送给初级同学的话----------------------------------------------
3-5年的如何成长
刚入行，刚开始不要想着要提升这，要提升那，写好代码，少BUG才是王道。
下面我们聊一下3-5年的如何成长，3-5年的应该达到什么水准。这时候的你代码能力应该更加成熟，衡量的标准就是一个需求分配给你，你知道问什么，知道怎么做，也不需要别人给你太多的指导，自己能独立完成模块开发，从数据库设计，定义接口，开发，联调都应该是你一个人完成。并且能够熟练运用各种中间件，搭建脚手架工程，接入各种中间件的API。
这个阶段看什么书？
-
think in java（java编程思想）
-
efftive java（高性能的JAVA）
-
设计模式
-
周志明的JAVA虚拟机
这四本书能看下来都是一件很不容易的事情。特别是 think in java efftive java 看起来特别枯燥，但是这两本书能让你对JAVA有一个更加深刻的认知。
总的来说这个阶段的目标就是一个成熟的程序员，知道怎么写代码，知道怎么解决自己的问题。
-----------------------------以上的送给3-5年的同学-----------------------------------------------
6-8年的如何成长
干了多少年可以当架构师？
答：7-8年左右
为什么？因为架构师不是学出来了。是靠一个个的项目经验堆出来的。这是我之前对架构师的描述。
所谓的架构师，其实是虚职， 哪有那么多项目要你架来架去的，谁没事天天重构，架构师只是在某一个时间段从事的一个工作内容，更多的是某一个技术经理去兼职干的事，技术经理架构完还得回去写代码。
架构需要哪些基本能力？
技术的广度
在你前面工作6-7年的工作里面，你零零散散的接触过很多的项目，他们都用过什么样的中间件？为什么用这个中间件，除此之外你们还考虑过哪些中间件。他们的区别是什么，这些你都要去了解。除了最流行的spring框架，jfinal用过吗，他和spring的区别是什么，mybatis和hibernate区别在哪里。为什么hibernate不常用了？什么场景用ES，什么场景用mongodb，ES的集群部署方式是什么，mongodb的集群部署方式是什么。mongodb 能不能做搜索的存储？ES为什么快，除了这些还有什么hbase是干嘛用的。hdfs是又是什么场景？大数据量的处理方案是什么？redis能支持多少并发，一级缓存和二级缓存有什么区别,等等等等。。。你以为这是深度问题嘛，这是最简单的广度问题。有时候我们做技术选型就需要这些东西，这些知识的储备哪里来，就是你前几年的项目经验堆积而来。如果你在之前的工作中，就用用就完了，现在开始思考这些问题。
技术的深度
什么是深度，我的理解绝对不是什么中间件的底层原理，哪些是广度问题。我们谈一下什么是深度问题，我说几个基本议题。
- 基于ES的外卖搜索实践（美团技术公众号）
- 高性能终端实时日志系统建设最佳实践（美团技术公众号）
- 基于AI算法的数据库异常监测系统设计与实现（美团技术公众号）
- ROCKETMQ多级存储设计与实现（阿里开发者头条号）
- 链路追踪实现逻辑（阿里开发者头条号）
- 交易履约订单中心实践（京东技术公众号）
还有很多许许多多的优秀的技术博客，这个阶段不要把你的目光聚焦在什么八股文的博客上面了。说的就是很多专门讲八股文的文章，视频，那些应该在3-5年这个阶段掌握。
目光要逐渐聚焦在解决方案，最佳实践上面，这些东西是跟着业务在变化的，是实实在在结合业务的真实架构，这些技术文章可能写的很浅，但是足够能让你涨见识了！要学的是他们的思路，你说你光知道ES可以很好的支持搜索，没用。人家为了实现最佳搜索逻辑怎么建模型的，怎么做匹配的，到底能够支持多少数据量级，遇到的挑战和问题是什么，怎么解决的。这些不都是以后出去面试吹牛B的资本嘛！！
业务的问题
好的架构一定是结合业务来做的。技术永远都是辅助业务。什么是懂业务，你要明白技术不是万能的，一定会有技术解决不了，或者成本很高的问题。作为架构师的你要一眼能看出这个问题的成本多少，有没有什么更好的方法。根据真实的业务场景去在尽量小的成本内去设计一套架构。
比如明明是一个简单的业务，到底要不要拆分微服务，拆分微服务带来的问题怎么解决，到底要多少资源多少服务器。什么样的数量级存在MYSQL里没问题，什么样的数量级需要分库分表了。有些技术方案因为使用的人少能不能偷懒做。还有当你初接触一个需求的时候是否马上在头脑中就有了一同比较好的业务模型去匹配他，以前你的经验能不能复用。这都是业务经验。
模型设计能力与画图能力
领域模型是什么，逻辑模型是什么，物理模型又是什么？流程图会不会画，时序图会不会画，应用架构图会不会画，物理部署图会不会画，这些图 process on 上面几乎都有，就看你愿不愿意动手去尝试。
总结
所以综上，6-8年的程序员你一定要想办法实现跳跃，可能是技术跳跃，可能是管理跳跃。这些跳跃可能需要等待机会，但是一定是需要你做好准备。将军不打无准备的仗，如果你这些都没准备好，如何指望别人把机会交给你呢？