“当时每酣醉，不觉行路难”。
每每有人问我:
程序员工作三年，要大致学习到什么程度才算合格？
这时候，我感觉很难给出一个绝对正确的回答。
我能做的就是，如实的把我做程序员三年后的状态分享出来，供大家参考。
卖油翁今已手熟尔
在我当了程序员三年之后，我对开发这事儿已经非常熟练了，熟练主要表现在两个方面：
- 提给我的业务需求，我已经能毫不费劲的形成技术思路。
- 写代码的时候，我已经能准确而快速的使用开发语言的 API 了。
我认为三年的程序员，做到以上两点是基本条件。干了三年左右，大部分人都已经很适应程序员这个工作了，是团队中编码的主力军，开发工作应该做的很顺利了。
如果大家在这方面还没做到位，我的建议是多写一些代码。这些代码可以是一些小工具，也可以是一些刻意练习。
牛客网上求职必备下的编程集合和它的基础提升模块大家可以看看。
说到这里，我多说一下，如果大家真的很熟练了，大家也要警醒一些。因为这种熟练的开发代码就像麻药一样，会渐渐地麻痹了大家的精神却不自知。
我自己对此是有些教训的。
我当时由于工作比较顺利，学习开始不那么努力了。虽然技术文章还在看，但系统的学习却停滞不前了。
我没有去系统性的拓展我的新技术学习，也没有规划好如何继续深入挖掘各种已掌握技术的细节。
直到一年后，公司有了一些变动，我被迫提前做了架构师，才发现自己知识的贫瘠。还好那时我醒悟的还不算晚。否则，我可能就一直沉湎于自己构造的舒适圈，很可能就影响到自己以后的发展。
因此，这里我想通过我的经历告诉大家，当你工作了几年后，一个最基本的要求就是，你得成为一个熟手，能搞定大部分常规的需求。
但是，这种工作上的顺利可能会让你懒惰，这点一定要警惕。干咱们这行，是需要持续学习的，因为行业变化太快了，各种新技术新理念新架构层出不穷。
打算在这个内卷的行业里继续走下去，只有不断的学习，深挖技术细节夯实基础，学新技术拓展眼界。
已知曲中意，亦是曲中人
干了三年，品鉴代码的好坏应该成为了自己的基本能力了。
我们至少应该拿到代码一看，就知道这代码写的好还是坏，维护容易还是困难。
这个能力是咱们的基础能力之一，其他基础能还例如，选第三方工具库的能力，如何重构代码的能力等等
如果你在代码方面还有些薄弱，我建议看看《代码整洁之道》这本书。
那如果你工作了三年，对代码好坏的嗅觉已经非常灵敏了，也千万不要自得，因为你此时需要克服一个问题，那就是嘚瑟。
这种嘚瑟体现在，你可能会开始评判别人的代码了。
回过头去看看，我当时就是这样。当看同事代码或者接手别人项目的时候，每当看到写的很难读，又或者组织很乱的代码的时候，我就开始去肆意的批评别人。
但我并不知道，自己也是把二把刀。我并不了解为什么人家代码写的难以维护，可能人家也是被迫的。
后来我接手了一个赶得很急、产品经理又不给力的项目，这时候，我才深刻体会到了那种赶工写代码的无奈。我才知道，自己也是写这类不可维护代码的同类人。
所以，后来我逐渐闭上了自己的嘴巴。当我再看到不好的代码，本能还是会反感，因为这增加了我的工作难度。但是，我已经不会再去批评作者了，而是会仔细思考，有没有更好的实现方式，我怎么能把代码改的更优雅。
自从这么做以后，我发现自己的编程能力竟然也跟着进步了。从很多烂代码后面，我学会了一些优化技巧，比如，使用位移去替代正常的加减乘数。
也从一些为了赶时间而写的不那么清晰的代码后面，看到了一些妥协的工作窍门，比如，使用 coninue label 和 break label 等去简化复杂的算法。
所以，工作了三年，品鉴代码好坏应该成为你的一种重要能力。
对于好代码，我们努力学习其风格；而对于坏代码，与其去狂妄的批评代码的作者，还不如我们仔细分析为什么它是坏代码，以及如何优化它。仅此而已，因为你自己也可能被迫会写出类似的坏代码。
穷千里目，更上层楼
老实讲，工作三年后，咱们至少要深度掌握一些技术了。
比如，我擅长 SQL ，能写各种性能优异的SQL，对 MySQL 有一定程度的了解。
前面我说过，我此时学习态度是很松垮的，所以，除了我掌握的，我后续竟然不知道该学什么方向了。
后来，可能是因为站到了更高的一个位置上，我突然知道了学习目标，那就是：
我的知识体系应该是随着公司后台架构的发展而进行拓展的。
比如，公司的架构主要是使用 Redis 做了第三方缓存，数据库是 MySQL，服务之间的通讯方式则是消息队列 RabbitMQ。
那么如果我想让自己的知识体系建立在公司的项目架构上，我应该怎么定学习目标？
当时我是这么分析的，我对 MySQL 了解的还算深入，但是对 Redis 和 RabbitMQ 还没有什么了解，只限于会用而已。所以，我定的目标就是对后两个技术进行深入学习。这样学完之后，我的知识体系就成了这样：
这套知识体系我掌握了，才能从众多的同事们中脱颖而出，才有可能成为团队中的核心。
所以，工作三年之后，咱们应该至少要深入掌握一些技术，并以此为基础，根据公司的技术架构去逐渐完善自己的知识体系。
做到了学习和工作相结合，才能在实力提升的同时也能得到职场上的正反馈。
花相似，人不同
做程序员的前三年，大家少不了各种 CV 代码。
不过在这三年中，我认为我们的 CV 应该有一些变化。
就说我吧，首先，我拷贝代码的来源发生了变化。从在网上随意找代码，变成了主要从 GitHub 上拷代码了，因为 GitHub 上的例子更多、更丰富。
其次，我拷代码的方式发生了变化。我会仔细研读要复制的代码，并配合官方文档，综合分析后，会对其做一些修改，变成真正适合我自己项目的代码。
最后，我拷代码的次数发生了变化。因为拷的代码我会仔细读、会改，所以我拷代码的次数在不断减少，自己独立写的代码越来越多。
所以，我推荐大家 CV 的时候，一是可以去专门的开源网站上找代码示例，二是 CV 前一定要分析下，明白每条语句的目的是什么，只有这样，咱们自己才能跟着进步。
现在 CV 是为了以后不 CV。
可言秋日胜春朝
三年工作，我可以独立解决一些线上问题了。
后来反思，我做的还不够好。因为我解决问题的方式大部分就是就事论事，只注重解决问题的表象，而不会去深挖问题的根源。
比如，JVM 内存溢出了，我的做法是改配置参数或者加内存，而不是想着怎么优化代码。
类似这种事情多了之后，由于很多深层次的问题没有得到解决，导致后期维护项目的时候，bug 越改越多，问题越修复越大，极大的增加了维护成本，慢慢的就变成了一个大“屎山”。
大家解决问题的时候，千万别学当时的我，只看问题表象。尽力对问题深挖，去根本性的解决问题。这样除了对项目和公司有好处，对个人成长也极为有利。坑踩的多，填的多，都会变成你的宝贵经验。
久在樊笼里，复得返自然
代码要写的尽量可读，尽量清晰，是我这个时候写代码的主要理念了。我不知道别人工作三年如何，但是我自己是吃够了这上面的亏。
以前写代码，由于编程水平很渣，而且也没听过“重构”，经常会写一些很难读的代码。比如，把很长的逻辑写到一个方法里，一个类几百上千行。结果在维护的时候就懵逼了，自己写的代码自己都看不懂，经常改错。
后来，我注重了代码质量，注重了重构，bug 也随之减少了很多。后来，团队 Leader 评价我写的代码“可读性和工程性都很好”。
建议大家也重视代码质量，代码要清晰可读，不要为了炫技而特意写一些难读的代码。
好雨知时节
三年里，我经过了很多项目 DeadLine 的考验。我此时已经明白了一个道理——按时完成任务比完美的完成任务要更重要。
单纯从技术角度看，如果我们要达到完美，是需要花费大量的时间的。优雅的代码，极致的性能，最优的资源利用，都是体现技术完美的因素。而这些因素，无一不是猛烈吞噬时间的猛兽。
- 优雅的代码需要更多的时间去重构代码
- 极致的性能需要长时间不同角度的压测
- 而最优的资源利用更是需要不断地修改代码去不停的尝试
现实上呢，我们开发的产品，市面上基本都有竞品，所以呢，需要我们早做完上线去抢有限的用户、有限的份额。因此，这就需要我们一定要快，在保证质量的前提下按时完活，应该成为咱们的第一优先保障。
方与人便人称便
工作了三年，我也明白了技术是为业务服务的这个道理。我也明白，越了解业务，我做出来的项目就会越契合业务，而越契合业务，项目、代码的价值就越大。这是一个正向循环。
所以后来，我每次要开发一套系统的时候，都会去主动学习相关业务知识。
后来我能从技术无缝转管理，有很大一部分原因是，我能更顺利的理顺业务和技术之间的裂痕，也能更平滑的将业务需求转化为技术需求。
你不得不承认，在国内真正技术驱动的公司和产品太少了，大部分现状是“技术服务于业务”。虽然这个现状我不喜欢，但是不得不接受，所以我还是想告诉大家：熟悉业务，是我们能突出自己的一个很好的切入点。
写到这里基本就写完了，最后我想说一下，工作三年的程序员大概要到什么程度，真的是千人前面的。每个人所在的公司不同，开发的项目不同，所在的职位不同，自然大家的感悟不同。
我上面说的那些话，除了想分享给大家，有些话也是想说给从前那个我听的。
你好，我是四猿外。
一家上市公司的技术总监，管理的技术团队一百余人。
我从一名非计算机专业的毕业生，转行到程序员，一路打拼，一路成长。
我会把自己的成长故事写成文章，把枯燥的技术文章写成故事。
不知不觉，我原创了不少文章，最近把其中的一些精华文章做了个汇总整理，优中选优，整了一份文档——《爬坡》。
《爬坡》里包括了 15 篇技术文章（包括学习编程技巧、架构师、MQ、分布式）和 13 篇非技术文章（主要是程序员职场），一共十万多字。
这个文档的获取方式戳这里