程序员做的就是三年后的状态分享出来的一些经验

程序员工作三年,要大致学习到什么程度才算合格?干了三年左右,大部分人都已经很适应程序员这个工作了,是团队中编码的主力军,开发工作应该做的很顺利了。我当时由于工作比较顺利,学习开始不那么努力了。直到一年后,公司有了一些变动,我被迫提前做了架构师,才发现自己知识的贫瘠。老实讲,工作三年后,咱们至少要深度掌握一些技术了。工作了三年,我也明白了技术是为业务服务的这个道理。

“当我喝醉的时候,我没有意识到旅行很困难。”

每次有人问我:

程序员工作三年应该学多少才能合格?

在这一点上,我很难给出一个绝对正确的答案。

我能做的就是如实分享我三年程序员的身份,供大家参考。

卖油的人现在已经很熟悉了

当了三年程序员后,我对开发已经非常熟练了,主要表现在两个方面:

对于我提到的业务需求,我已经能够毫无困难地形成技术构想。

在写代码的时候,我已经可以准确快速的使用开发语言的API了。

我认为这是三年程序员达到以上两点的基本条件。工作三年左右,大部分人已经非常习惯程序员的工作了。他们是团队中编码的主要力量。开发工作应该很顺利。

如果你在这方面做得不好,我的建议是多写代码。这些代码可以是小工具或刻意练习。

您可以在 的在线求职下查看编程集合及其基本改进模块。

说到这里,我再多说一句,如果大家真的精通的话,大家应该提高警惕。因为这种熟练的开发代码就像麻醉一样,会在不知不觉中逐渐麻痹大家的精神。

我自己也有这方面的经验。

因为当时我的工作比较顺利,我开始不那么努力学习了。虽然技术文章仍在阅读,但系统学习却停滞不前。

我没有系统地扩展我的新技术学习,也没有计划如何继续深入挖掘我已经掌握的各种技术的细节。

直到一年后,公司发生了一些变化,我被迫提前成为了一名架构师,我才意识到我的知识很差。幸运的是,我醒来还为时不晚。否则,我可能一直沉迷于自己的舒适区,这可能会影响我未来的发展。

因此,在这里我想通过我的经验告诉你,当你工作几年后,最基本的要求之一就是你必须成为一个能够处理大部分日常需求的技术人员。

但是,这种工作上的成功会让你变得懒惰,所以要小心。在我们这个行业,我们需要不断的学习,因为这个行业变化太快,各种新技术、新概念、新架构层出不穷。

我打算继续从事这个内卷的行业,只有不断学习,深挖技术细节夯实基础,学习新技术拓展视野。

知道音乐在意境,也是音乐里的人

经过三年的工作,品鉴代码的质量应该成为我的基本能力。

我们至少应该看一下代码,以了解代码的好坏、易维护还是难维护。

这个能力是我们的基本能力之一。其他基本能力包括,例如选择第三方工具库的能力、重构代码的能力等。

如果你在代码中还有一些弱点。我推荐阅读《干净的代码》这本书。

那如果你工作了三年,你的嗅觉对代码的质量非常敏感,不要沾沾自喜,因为这个时候你需要克服一个问题,那就是结巴。

尴尬的是现在你可能会开始评判别人的代码了。

回想起来,我就是这样。在看同事的代码或接手别人的项目时,每当我看到难以阅读或组织不善的代码时,我就开始肆无忌惮地批评别人。

但我不知道,我也是二刀。我不明白为什么别人的代码很难维护,也许他们是被迫的。

后来接手了一个项目很赶时间,产品经理效率低下。这时候,我深深体会到匆忙写代码的无奈。我才知道,我就是写这种不可维护代码的人。

于是,我渐渐闭上了嘴。当我再次看到糟糕的代码时,我的直觉仍然会很恶心,因为它增加了我的工作难度。不过,我不会再批评作者了,而是会仔细思考是否有更好的实现方式,如何更优雅地修改代码。

自从这样做后,我注意到我的编程技能也得到了提高。从很多糟糕的代码背后,我学到了一些优化技术,比如使用位移而不是普通的加减乘法器。

还可以从一些匆忙编写的不太清晰的代码背后看到一些妥协的工作技巧,例如,使用等来简化复杂的算法。

所以,工作三年后,品鉴代码的质量应该成为你的一项重要能力。

为了好的代码,我们尝试学习它的风格;对于不好的代码,与其狂妄地批评代码的作者,不如认真分析为什么是不好的代码以及如何优化。就是这样,因为您可能被迫自己编写类似的糟糕代码。

大约一千英里及更高级别

说实话,经过三年的工作,我们至少要对一些技术有深刻的把握。

比如我擅长SQL,能写出各种性能优异的SQL,对.

有一定的了解。

前面说了,这个时候我对学习的态度很松散,所以,除了已经掌握的东西,不知道以后该往哪个方向学习。

seo后没有工作经验怎么办

后来,也许是因为站在更高的位置,我突然知道了学习的目标,那就是:

我的知识体系应该随着公司的背景结构而发展壮大。

比如公司的架构主要使用第三方缓存,数据库是,服务之间的通信方式是消息队列。

那么如果我想在公司的项目结构上构建我的知识体系,我应该如何设定学习目标呢?

我当时就是这么分析的。我对 有很深的理解,但对 和 了解不多,只知道怎么用。所以,我的目标是更多地了解后两种技术。经过这次学习,我的知识体系变成了这样:

工作3年,我终于开窍了

我掌握了这个知识体系,让我在众多同事中脱颖而出,成为团队的核心。

所以,工作三年后,我们至少应该对一些技术有深刻的把握,并在此基础上,根据公司的技术结构,逐步完善自己的知识体系。

只有学习与工作相结合,才能在职场中得到积极的反馈,同时提升自己的实力。

花相似,人不同

当程序员的前三年,各种CV代码少不了。

工作3年,我终于开窍了

但是这三年,我觉得我们的简历应该会有一些变化。

请说我,首先,我复制代码的来源发生了变化。从网上随便找代码,变成了主要是抄代码,因为上面的例子越来越丰富。

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

最后,我复制代码的次数发生了变化。因为我会仔细阅读和更改复制的代码,所以我复制代码的次数在减少,而我独立编写的代码在增加。

所以,我在给大家推荐CV的时候,一是可以去专门的开源网站找代码示例,二是在CV前一定要分析清楚每条语句的目的是什么。只有这样,我们才能自己进步。

现在的简历不是以后的简历。

可以说秋天胜过春天

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

回想起来,我做的还不够好。因为我解决问题的大部分方式都是着眼于事实,只着眼于解决问题的表面,而不是深入问题的根源。

例如,JVM 内存溢出。我的做法是改变配置参数或者增加内存,而不是去想如何优化代码。

经历了很多这样的事情,因为很多深层次的问题还没有解决,到后期维护项目的时候,改的bug越来越多,问题修复了,问题就越大,大大增加了维护。成本慢慢变成了一座大“狗屎山”。

当每个人都解决一个问题时,不要在那个时候模仿我,只看问题的外观。尽最大努力深入挖掘问题,从根本上解决问题。这不仅对项目和公司有利,对个人成长也极为有利。踩的越多,填的越多,就会成为你宝贵的经验。

在笼子里久了,我会回归自然

代码要尽可能的可读、清晰,这是我此时写代码的主要思想。我不知道别人这三年是怎么干的,但我自己已经受够了这种损失。

由于我的编程能力很差,而且从来没有听说过“重构”,我曾经编写过难以阅读的代码。比如把一个长逻辑写成一个方法,一个类几十万行。结果,我在维护的时候一头雾水。自己写的代码看不懂,经常出错。

后来,我专注于代码质量和重构,错误减少了很多。后来,团队评论说我写的代码“有利于可读性和工程”。

建议大家也要注意代码的质量,代码要清晰易读,不要写一些难读的代码来炫耀自己的本事。

好雨知道季节

这三年来,我通过了很多项目的考验。至此我明白了一个道理——按时完成任务比完美完成任务更重要。

从纯技术的角度来看,如果我们想要做到完美,需要花费很多时间。优雅的代码、极致的性能、最优的资源利用,都是体现技术完美的因素。而这些因素,都是猛烈吞噬时间的野兽。

事实上,我们开发的产品基本上都有市场上的竞品,所以我们需要尽早完成上市,以抢占有限的用户和有限的份额。因此,这就要求我们在保证质量的前提下,快速、按时完成工作,这应该是我们的首要任务。

方和人易称人

工作三年,我也明白了技术服务于商业的道理。我也明白,越了解业务,我做的项目就越适合业务,越适合业务,项目和代码的价值就越大。这是一个正向循环。

所以以后每次想开发一个系统,都会主动学习相关的业务知识。

我之所以能够从技术无缝切换到管理,很大程度上是因为我能够更顺畅地拉开业务和技术之间的鸿沟,以及更顺畅地将业务需求转化为技术需求。

你不得不承认,在中国,真正以科技为驱动的公司和产品太少了,大部分的现状是“科技为企业服务”。虽然我不喜欢这种现状,但我不得不接受,所以还是想告诉大家:熟悉业务是我们突出自我的一个很好的切入点。

到这里基本就写完了。最后,我想谈谈工作三年的程序员的水平。真的是在千人面前。每个人都在不同的公司工作,开发不同的项目,担任不同的职位。当然,每个人都有不同的看法。

我上面说的话,除了想和大家分享,也想告诉以前的我。

免责声明:本文来自网络用户投稿,不代表本站观点和立场。如有侵权请发送邮件至tzanseo@163.com告知本站删除,本站不负任何责任及承诺。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

发表评论

登录后才能评论