1、

在我当了程序员三年之后，我对开发这事儿已经非常熟练了，熟练主要表现在两个方面：

1. 提给我的业务需求，我已经能毫不费劲的形成技术思路。

2. 写代码的时候，我已经能准确而快速的使用开发语言的 API 了。

我认为三年的程序员，做到以上两点是基本条件。干了三年左右，大部分人都已经很适应程序员这个工作了，是团队中编码的主力军，开发工作应该做的很顺利了。

如果大家在这方面还没做到位，我的建议是多写一些代码。这些代码可以是一些小工具，也可以是一些刻意练习。

我自己对此是有些教训的。

我当时由于工作比较顺利，学习开始不那么努力了。虽然技术文章还在看，但系统的学习却停滞不前了。

我没有去系统性的拓展我的新技术学习，也没有规划好如何继续深入挖掘各种已掌握技术的细节。

直到一年后，公司有了一些变动，我被迫提前做了架构师，才发现自己知识的贫瘠。还好那时我醒悟的还不算晚。否则，我可能就一直沉湎于自己构造的舒适圈，很可能就影响到自己以后的发展。

因此，这里我想通过我的经历告诉大家，当你工作了几年后，一个最基本的要求就是，你得成为一个熟手，能搞定大部分常规的需求。

但是，这种工作上的顺利可能会让你懒惰，这点一定要警惕。干咱们这行，是需要持续学习的，因为行业变化太快了，各种新技术新理念新架构层出不穷。

打算在这个内卷的行业里继续走下去，只有不断的学习，深挖技术细节夯实基础，学新技术拓展眼界。

2、

干了三年，品鉴代码的好坏应该成为了自己的基本能力了。

我们至少应该拿到代码一看，就知道这代码写的好还是坏，维护容易还是困难。

这个能力是咱们的基础能力之一，其他基础能还例如，选第三方工具库的能力，如何重构代码的能力等等

如果你在代码方面还有些薄弱，我建议看看《代码整洁之道》这本书。

那如果你工作了三年，对代码好坏的嗅觉已经非常灵敏了，也千万不要自得，因为你此时需要克服一个问题，那就是嘚瑟。

这种嘚瑟体现在，你可能会开始评判别人的代码了。

回过头去看看，我当时就是这样。当看同事代码或者接手别人项目的时候，每当看到写的很难读，又或者组织很乱的代码的时候，我就开始去肆意的批评别人。

但我并不知道，自己也是把二把刀。我并不了解为什么人家代码写的难以维护，可能人家也是被迫的。

后来我接手了一个赶得很急、产品经理又不给力的项目，这时候，我才深刻体会到了那种赶工写代码的无奈。我才知道，自己也是写这类不可维护代码的同类人。

所以，后来我逐渐闭上了自己的嘴巴。当我再看到不好的代码，本能还是会反感，因为这增加了我的工作难度。但是，我已经不会再去批评作者了，而是会仔细思考，有没有更好的实现方式，我怎么能把代码改的更优雅。

3、

老实讲，工作三年后，咱们至少要深度掌握一些技术了。

比如，我擅长 SQL ，能写各种性能优异的SQL，对 MySQL 有一定程度的了解。

前面我说过，我此时学习态度是很松垮的，所以，除了我掌握的，我后续竟然不知道该学什么方向了。

后来，可能是因为站到了更高的一个位置上，我突然知道了学习目标，那就是：

我的知识体系应该是随着公司后台架构的发展而进行拓展的。

比如，公司的架构主要是使用 Redis 做了第三方缓存，数据库是 MySQL，服务之间的通讯方式则是消息队列 RabbitMQ。

那么如果我想让自己的知识体系建立在公司的项目架构上，我应该怎么定学习目标？

当时我是这么分析的，我对 MySQL 了解的还算深入，但是对 Redis 和 RabbitMQ 还没有什么了解，只限于会用而已。所以，我定的目标就是对后两个技术进行深入学习。这样学完之后，我的知识体系就成了这样：

这套知识体系我掌握了，才能从众多的同事们中脱颖而出，才有可能成为团队中的核心。

4、

做程序员的前三年，大家少不了各种 CV 代码。

不过在这三年中，我认为我们的 CV 应该有一些变化。

就说我吧，首先，我拷贝代码的来源发生了变化。从在网上随意找代码，变成了主要从 GitHub 上拷代码了，因为 GitHub 上的例子更多、更丰富。

其次，我拷代码的方式发生了变化。我会仔细研读要复制的代码，并配合官方文档，综合分析后，会对其做一些修改，变成真正适合我自己项目的代码。

5、

三年工作，我可以独立解决一些线上问题了。

后来反思，我做的还不够好。因为我解决问题的方式大部分就是就事论事，只注重解决问题的表象，而不会去深挖问题的根源。

比如，JVM 内存溢出了，我的做法是改配置参数或者加内存，而不是想着怎么优化代码。

类似这种事情多了之后，由于很多深层次的问题没有得到解决，导致后期维护项目的时候，bug 越改越多，问题越修复越大，极大的增加了维护成本，慢慢的就变成了一个大“屎山”。

6、

代码要写的尽量可读，尽量清晰，是我这个时候写代码的主要理念了。我不知道别人工作三年如何，但是我自己是吃够了这上面的亏。

以前写代码，由于编程水平很渣，而且也没听过“重构”，经常会写一些很难读的代码。比如，把很长的逻辑写到一个方法里，一个类几百上千行。结果在维护的时候就懵逼了，自己写的代码自己都看不懂，经常改错。

7、

三年里，我经过了很多项目 DeadLine 的考验。我此时已经明白了一个道理——按时完成任务比完美的完成任务要更重要。

单纯从技术角度看，如果我们要达到完美，是需要花费大量的时间的。优雅的代码，极致的性能，最优的资源利用，都是体现技术完美的因素。而这些因素，无一不是猛烈吞噬时间的猛兽。 - 优雅的代码需要更多的时间去重构代码 - 极致的性能需要长时间不同角度的压测 - 而最优的资源利用更是需要不断地修改代码去不停的尝试

现实上呢，我们开发的产品，市面上基本都有竞品，所以呢，需要我们早做完上线去抢有限的用户、有限的份额。因此，这就需要我们一定要快，在保证质量的前提下按时完活，应该成为咱们的第一优先保障。

8、

工作了三年，我也明白了技术是为业务服务的这个道理。我也明白，越了解业务，我做出来的项目就会越契合业务，而越契合业务，项目、代码的价值就越大。这是一个正向循环。

所以后来，我每次要开发一套系统的时候，都会去主动学习相关业务知识。

后来我能从技术无缝转管理，有很大一部分原因是，我能更顺利的理顺业务和技术之间的裂痕，也能更平滑的将业务需求转化为技术需求。

1.《架构师修炼之道》

要转成架构师思维，首先得知道架构师是如何思考问题的，当业务人员给出具体的需求之后，架构师们是如何根据需求去做对应的设计和分析的。

因此，我推荐先可以看看《架构师修炼之道》这本书。

这本书的英文版我其实也读过，自认为里面的所思所想，确实是我做架构时都考虑过的事情，甚至里面提及的一些思路，我自身都没考虑过。

这本书，我认为可以作为程序员转架构师的第一本书：

它起码会提醒程序员，从上到下思考系统架构，到底是怎样的一个思路。

了解了架构师是如何从上而下的思考和设计系统架构的，初步对架构师的思维有了些许印象后，就需要找个师傅能全面带你一把，能通过走一遍架构师的工作流程，去开始尝试架构师工作入门，去通过实践，一点点的让这些思维形成习惯。

2.《从零开始学架构》

而这个师傅我认为是《从零开始学架构》这本书。

这本书读起来非常快，读的也很过瘾，是我看到的最贴近中国架构师日常实践的书。

书里面对架构师从设计到经常用的模式，以及对应的理论都做了介绍。

尤其是架构设计中的一些重要的大坑，和架构师重要的取舍思想都做了清晰的介绍，非常适合帮助实践入门，对程序员的技能提升有肉眼可见的帮助。

要知道，架构师不仅仅是个工作，同时也代表着各种各样的更高阶的技术能力，而要提升能力之前，先拥有一套全局的架构师思维，知道架构师都做什么事情，从而能得到努力前进的方向，是极其重要的第一步。