[科技知识] 我是一名刚入行的程序员，各位前辈有什么忠告吗？

天天财汇购物网址万年历小说 | 三峰软件小游戏视频

TxT小说阅读器
↓小说语音阅读,小说下载↓

一键清除系统垃圾
↓轻轻一点,清除系统垃圾↓

图片批量下载器
↓批量下载图片,美女图库↓

图片自动播放器
↓图片自动播放,产品展示↓

首页淘股吧股票涨跌实时统计涨停板选股股票入门股票书籍股票问答分时图选股跌停板选股 K线图选股成交量选股 [平安银行]

股市论谈均线选股趋势线选股筹码理论波浪理论缠论 MACD指标 KDJ指标 BOLL指标 RSI指标炒股基础知识炒股故事

商业财经科技知识汽车百科工程技术自然科学家居生活设计艺术财经视频游戏--

天天财汇 -> 科技知识 -> 我是一名刚入行的程序员，各位前辈有什么忠告吗？ -> 正文阅读

[科技知识]我是一名刚入行的程序员，各位前辈有什么忠告吗？

[收藏本文] 【下载本文】

一边学习一边迷茫，各位行业前辈在2024年能给出几点忠告吗

我的忠告：时代变化太快了，不要把前辈的忠告太当回事。

首先，要思考的是，我们现在学的这些知识，是不是海量人都可以掌握的技术。
如果是的话，我们就要思考的内容是，这个技术路线是否有非常多的升级的分支。
第二点的话，就是，我们是否可以掌握全局，千万不能漏掉细节。
很显然，只有自己知道的越多，不论是业务，还是编程语言的语法和套路。

1、技术学的再高也不能保证你以后不失业或被淘汰，用技术帮到别人才可以。
2、不要做任何需求不明确的项目或任务，纯属浪费时间。
3、要深入了解自己项目的业务逻辑，才不会沦为工具人。
4、一定要写测试代码。
5、不要在需要折腾一番才能搞的技术上浪费时间，因为你在消耗自己。
6、别玩小众的东西，用的多的才是好的。
7、技术书籍或文档要看原文或官方的，如果是英语就好好学英语。
8、写代码追求清晰简单，任何人都能看懂，因为时间一久你就是任何人。
9、技术讨论时不跟任何人争论，多听少说。
10、以上忠告都是临时拼凑的。感觉不对请忽略，感觉对了请点赞。

说真的，但就你知道「学习」这件事，就已经打败很多程序员了！
至于「迷茫」，我很理解这种感觉。
迷茫更多的是来源刚步入社会对未来的敬畏，以及知道学习，但是不知道学什么，或者说不知道学了有什么用。
我就明确告诉你，迷茫只是暂时的，根本不用担心。
交给你个小方法，下次你再迷茫的时候，你就深呼吸几口气，随便打开本什么书开始看，有用，不信你就试试。
至于建议，想说的太多了，毕竟也工作好几年了，那就一条条来吧。
1、学会高质量的请教
新人通常入职以后都比较害羞，有了问题也自己硬解，不喜欢去问老员工，一方面是不熟，另一方觉得问了会显得自己很 low。
这个是明显的“我觉得”，在职场上我不要我觉得，带着问题去请教和探讨，其实花不了多少时间呢，尤其是那种需要靠着经验和积累去解决的问题，老员工们还是很乐意回答的，毕竟谁没个虚荣心，也会显得他们有一丢丢厉害。
但是也要注意，不是什么问题都要去问，随便搜索就能查到的问题，你还是不要去打扰别人了，毕竟别人的工作时间也很宝贵。
2、不要只盯着自己那部分
一个多人协作的项目，不要只盯着自己负责的部分。要学会去研究整个项目，保证对项目有个清晰的了解，尤其是对于其中涉及到的技术部分，要多去学习和思考。
这样做的好处，首先是可以从整个全局的角度来看待自己负责部分的功能模块，在考虑自己这部分功能设计的时候，能够提早识别风险，以及可能存在的难点，整体上会更加周全，完成度会更好。
其次在处理问题，或者联调的时候，由于熟悉相关的业务和代码，能够更快的判断问题可能的原因，及时解决。
这都是你能力的展现。
3、不要抵触 Code Review
如果你的公司有 CR，那恭喜你，你是幸福的。
但现实是，新人在刚入行的时候 CR 却不会有幸福的感觉，总是觉得这是在“找茬”，很抵触。
这就是没经过社会“毒打”的新人的通病，盲目的对自己的技术能力很有自信，不觉得自己有什么问题。但实际情况是，新兵蛋子在制造 bug 乃至是安全事故的比例却是很高的，因为你们并不觉得自己有问题，但正应了那句话“自己不知道自己不知道”。
其实就算是工作很多年的程序员，也不敢保证自己的代码百分之百正确，开发这件事，很容易陷入“当局者迷”的状态，因为在开发者自己的认知范围内，总感觉已经考虑的很全面，实际上可能会存在漏洞，这就需要 CR 的“旁观者清”。
Code Review 是代码审视的过程，这其实也是别人在帮助你的机会，在审视的过程中，你作为一个新人理解了公司的代码规范，学习了更精进的编码方式。
你要知道，CR 这件事在大多数公司都不和绩效挂钩，相当于别人拿出了自己的时间来帮助你，没收你钱就不错了。
还有最重要的一点，CR 以后的代码如果上线不小心出了问题，那也不是你自己的责任，而是集体的事，至少你是被保护了起来，不至于被...祭天。
4、多读好书
对于新人来说，一定要读一些好书，培养自己各方面的能力。
比如我拿编程素养来说，这就相当于程序员的价值观。一个人的价值观有问题，那这个人肯定有问题，同样编程素养有问题，你学再多东西也白搭。
所以你多看些《代码大全》、《重构：改善既有代码的设计》、《代码整洁之道》这类书，不断提升自己的能力。
有什么比较好的培养编程素养和代码风格的书籍？11 赞同 · 0 评论回答

5、需求无限，要适当放下
程序员的职场，淘汰一个人最快的方式，就是让他忙起来，工作就是全部，忙到没时间休息，没时间学习，没时间创造。
初入职场的程序员都很实诚，不懂的“合理规划”这件事，给到的需求加班加点的做完，结果又有了更多的需求。
等你明白过来活不是这么个干法的时候，已经晚了，已经习惯你的高效，等你稍微降速，就被觉得是在摸鱼。
在程序员的职场上，不是说你快速做完，剩下的时间就是自己的，工作是做不完的，初入职场第一课就是要安排好工作内容的权重。
6、学会休息，技术是学不完的
入行这几年，为了保持竞争力，尽快做出成绩，疯狂卷技术，参与重要的工作，结果职位有了，钱有了，身体拉警报了。
颈椎僵了，背麻了，腰酸了，建议新人从入行第一天就要重视这个问题。
这些问题得了就是一辈子的事儿，你应该不想在工作紧急的时候，因为这些身体上的问题没法注意力集中吧。
所有要有一个好心态，技术是学不完的，身体却是自己的。
这也是我现在非常后悔的事情，要有意识的不要久坐，四五十分钟一个小时起来活动一下，我知道你工作起来会忘记，可以定闹钟，或者买个运动手表，有久坐提醒。
再买些“护颈”、“腰靠”这类借助外力辅助保护好自己。
7、身体才是革命的本钱
程序员的亚健康是件很麻烦的事，时间久了会影响你的精力，从而影响到工作的质量。
所以，要学会锻炼。
工作忙的时候我就抽时间慢跑、跳绳，不忙的时候就去健身房做做无氧，针对自己不舒服的地方有意识的加强肌肉力量，一段时间以后你就能明显感觉到身体的变化。
锻炼的汗水和兴奋感，还会缓解大脑中对于工作等这些产生的焦虑感，一举两得。
所以，一定要锻炼，每周至少两三次，根据自己的工作情况而定，忙有忙的动法，不忙有不忙的选择。
8、学会热心的帮助同事
你有问别人问题的时候，也就有别人向你寻求帮助的时候。
你可能觉得自己是个新人，啥也不会，问我干啥。
不要上来就想着这些原因推辞，而是要先看看，这都是展现你能力的机会，就算没解决，这也是增进同事间感情，获得别人好感的一个方式。
9、工作不要私下沟通
这是很多初入职场的程序员容易犯的错误，给什么活你就干什么，干完了就是干完了，就自己知道，领导不知道你在干啥，还以为你闲着没事。
一般一个项目或者工作的时候都会有工作群，工作上和同事的沟通不要私下沟通，要在群里沟通，做完了一件什么事或者完成了重要的工作要及时在群里或者和领导当面汇报，不要觉得麻烦谁，也不要觉得不好意思，这样才是真正干工作的方式。
10、不要害怕看英文
80% 以上的程序员都不习惯看英文文档，你要是看了，你就是 20% 那一撮“厉害”的人。
说“不习惯”都是委婉了，其实就是“害怕”看。
虽然汉译过来的经典书也能满足大家的需求，但是职场上和你之前在学校学习时又不一样了，你要关注前沿最新的消息，学习最新的技术，等新技术的书翻译过来再去学黄花菜都凉了。
平时没事的时候多逛逛 GitHub，如果有机会参与到开源项目的建设，甚至是给优秀的开源项目贡献自己的代码，那感觉真的很棒！
有问题也可以多去 Stack Overflow，几乎所有你能碰到的 bug 上面都能搜到对应的解决办法。就算搜不到也可以免费提交问题，很难想象，如果没有了 Stack Overflow 我还能不能干得了程序员...
我知道很多人害怕看英文文档，是觉得自己的英语不好，别担心，谷歌翻译有道翻译这些都是你最好的工具，前期可能看的慢点，后面习惯了速度就会上来。
11、做好规划
对于绝大多数程序员来说，程序员不可能是你唯一的职业。有时候就算你想，但是现实也不允许。
好好规划自己的路，有目的的要走，是更努力的削尖了脑袋往上挤，还是要转向“管理”，或者是“与人打交道”的方向，这些都是要随着你职业生涯的不断进行，根据自己的实际情况，不断思考的事情。
就算你现在是在大厂，做了很大的项目，拿着丰渥的工资，你也要分清哪些是平台给你的，哪些真的是你的能力，时刻对自己的能力保持清醒的认知，这是很重要的。
不要觉得事情没到自己头上，就可以蒙着两只眼睛说看不见，人无远虑，必有近忧。
明明是工作经验越久越吃香，为什么程序员却不是？24 赞同 · 10 评论回答

如果觉得上面的建议还不错，那你不要吝啬你的夸奖呀。
我是
@Rocky0429
，前数据分析师，现事业部背锅负责人。知乎编程类圆桌嘉宾，科技互联网、教育高赞答主，擅长科技互联网、教育、职场、求职面试等问题，不断拓展边界，希望能给到读者更好的回答，帮助少走弯路。

天赋异禀的毕竟是少数人。对于我们大多数普通人来说，想要实现“逆袭”都不是一蹴而就的，需要不断提升、不断积淀，最终达到厚积薄发的效果。在此跟大家分享一个普通程序员提升自己的过程。
一、分阶段，根据不同需求按需提升
对于多数程序员来说，40岁之前赚到别人60岁的钱是普遍目标，不过职业的进阶也印证着人生的进阶，所以何时开始思考未来的职业规划，都不算早。
我们基于华为云各个产品线技术专家多年工作经验和心得体会，再经过层层筛选整理，推出了这份程序员进阶必读书单。
无论你是1年小白、5年资深还是10年技术专家，或者更高阶的CTO，都可以在书单中找到适合自己目前阶段的书，清晰化未来要走的方向，让你的路越走越宽，财富累积/技能累积/经验累积也会愈发顺利。
程序员的第一阶段：初级程序员（0-3年）
初级程序员工作经验在3年以下，处于打基础、定方向的阶段，这时候建议主要精力用于夯实基础，规范编程上，将会终身受益。
了解自己所在的领域，对吃饭的工具有清晰的认知代码是一个程序员的灵魂，每个优秀的程序员都应该认真对待亲手写出的代码从实际问题出发，让自己的编程语言和思维更上一层楼多学点算法和数据结构，提高编程水平初级程序员必备的软技能，学习做好职业规划、自我营销程序员的第二阶段：中高级程序员（3-5年）“代码有很多种坏味道，重复是最坏的一种”，先让你的代码更优雅总有不合理的软件项目存在，如何避免犯一些经典错误技术能力之外，提高工作效率很重要程序员职业生涯到了一定阶段，系统地思考职业发展培养专业的软件开发素养，具备良好的编程实践程序员的第三阶段：全栈工程师/软件设计师（5-10年）全栈工程师必备技能之协调客户、管理好项目全栈工程师培养可用性思维软件设计模式领域的里程碑著作转变一下程序员的思维，认识交互设计的重要性面对漫长的职业生涯，静下心来追求“良质”程序员的第四阶段：架构师、CTO（10年以上）为解决架构设计模式中的“疑难杂症”打开思路跟着国外技术大佬学团队管理带领团队完成敏捷转型从技术人员转型为领导者，系统提高技术领导力架构师也好，CTO也罢，管理团队有时候比技术能力更重要

二、不同阶段必读书单程序员的第一阶段：初级程序员（0-3年）
初级程序员工作经验在3年以下，处于打基础、定方向的阶段，这时候建议主要精力用于夯实基础，规范编程上，将会终身受益。
一、了解自己所在的领域，对吃饭的工具有清晰的认知
《编码：隐匿在计算机软硬件背后的语言》豆瓣评分：9.2分

这本书常年排在程序员必读书单TOP5内，作者用丰富的想象将看似繁杂的计算机工作原理阐述得通俗易懂。
二、代码是一个程序员的灵魂，每个优秀的程序员都应该认真对待亲手写出的代码
《代码整洁之道》豆瓣评分：8.6分

阅读这本书有两种原因：第一，你是个程序员；第二，你想成为更好的程序员。
作者Bob大叔给出了一系列整洁代码操作实践，并用实际项目的正、反案例，说明只要遵循这些规则，就能编写出干净的代码，从而有效提升代码质量。
而干净的代码，既容易理解、质量可靠，而且让项目更容易启动和延续，也为后期维护、升级奠定了良好基础。
三：从实际问题出发，让自己的编程语言和思维更上一层楼
《编程珠玑》豆瓣评分：9.1

作者Jon Bentley可以说是计算机科学大家培养专业户，Java之父James Gosling就是他的学生。
他选取了典型的复杂编程和算法问题，生动描绘大师们在探索解决方案中发生的轶事、走过的弯路和不断精益求精的历程，总结了许多独特而精妙的设计原则、思考和解决问题的方法以及实用程序设计技巧。比如和Bob Martin讨论密西西比河一天流出多少水，用这样一个小问题引出粗略估算的技巧。
四、多学点算法和数据结构，提高编程水平
《数据结构和算法分析（套书）》豆瓣均分：8.7分

国内外很多大学都拿它当作教材，这套书非常系统、全面、严谨，适合对数据结构和算法有些基本了解，并且掌握了至少一门编程语言的程序员。而且，作者用了C\C++\Java三种语言分别写了三个版本。
被众多程序员选为最好的算法入门书，看完了这本书再看其它算法书，会很有底气。
五、初级程序员必备的软技能，学习做好职业规划、自我营销
《软技能—代码之外的生存指南》豆瓣评分：8.0分

概括了软件行业从业人员所需的“软技能”，从揭秘面试的流程到精耕细作出一份杀手级简历，从创建大受欢迎的博客到打造个人IP，从提高自己工作效率到与如何与“拖延症”做斗争，甚至包括如何投资不动产，如何关注自己的健康，堪称程序员的生活百科全书。
程序员的第二阶段：中高级程序员（3-5年）
从部门新人变为老人后，需要对自己的职业规划有明确方向，如果选择专攻技术，必然要多学习，进一步提高业务能力和技术能力，积累优质的项目经验。
一、“代码有很多种坏味道，重复是最坏的一种”，先让你的代码更优雅
《重构:改善既有代码的设计》豆瓣评分：9.0分

重构，就是在不改变外部行为的前提下，有条不紊地改善代码。本书凝聚了软件开发社区专家多年实践经验，解释重构的原理和最佳实践方式，并指出何时何地应该开始挖掘你代码以求改善。
整本书第三章“代码坏味”，写的很有用。什么是代码的坏味道，如何消除这些坏味道，这是一本关于代码美学的一本书，培养码农那高贵的code taste的不二选择。
二、总有不合理的软件项目存在，如何避免犯一些经典错误
《快速软件开发》豆瓣评分：8.4分

软件开发处处都是陷阱，作者告诉你前人都踩了哪些坑。本书总结了以微软为代表的美国软件业的项目实践经验，并列出了可以提高项目开发速度的方法和技巧。
比如，过紧或不合理的进度计划可能是软件开发唯一最具破坏力的杀手，所以开发人员要提高谈判能力，合理规划项目进度。
三、技术能力之外，提高工作效率很重要
《高效程序员的45个习惯》豆瓣评分：8.2分

总结高效程序员在开发过程中的45个个人习惯、思想观念和方法，有助于开发人员在开发进程、编码工作、开发者态度、项目和团队管理，以及持续学习等方面积极修炼。
养成这些好的习惯，可以极大地提升自己的编程实力，更快速、更可靠地交付更高质量的软件，从而成为真正的高效程序员。
四、程序员职业生涯到了一定阶段，系统地思考职业发展
《软技能2：软件开发者职业生涯指南》豆瓣评分：9.0分

了解软件开发从业者需要具备的各种“软技能”，包括如何选择工作岗位、如何选择技术方向、如何拓展技术技能、如何与团队和领导融洽相处等等。
五、培养专业的软件开发素养，具备良好的编程实践
《程序员修炼之道：通向务实的最高境界（第2版）》豆瓣评分：9.2分

理解身为一名程序员到底意味着什么，本书通过许多富有娱乐性的奇闻轶事、有思想性的例子以及有趣的类比，全面阐释了软件开发的最佳实践和重大陷阱。
书中有一章的标题是“我的源码被猫吃了”，其实说的是当你发现问题时，重要的是解决它，而不是把错误推给“猫”。
华为云资深架构师董老师在“云享读书会”领读过这本书，拆解书中精华知识，学练结合，拒绝纸上谈兵。
程序员的第三阶段：全栈工程师/软件设计师（5-10年）
这个时期的程序员，或多或少要开始思考职业拐点：是继续做一名底层码农，还是往前走两步，成为一个优秀的全栈工程师或者软件设计师。
无论是前后端技术一把手的全栈工程师，还是有程序设计能力的软件设计师，都得精通多门编程语言，有系统性的技术能力。前几年打好技术基础后，此时更要注重技术之外的软件开发细节，让自己的工作更胜一筹。
一、全栈工程师必备技能之协调客户、管理好项目
《人月神话》豆瓣评分：8.4分
软件领域的圣经，内容源于作者在IBM公司System/360家族和OS/360中的项目管理经验。书名中的“人月”指的是一个人在一个月内完成的工作，“神话”指通过人手来缩短项目实践是神话。
虽然书里很多概念、例子、技术都属于上古时期的遗迹了，但是书里介绍的软件开发的困难、管理的思路，仍然可以在今天的软件开发中找到对应的场景。
二、全栈工程师培养可用性思维
《点石成金 : 访客至上的Web和移动可用性设计秘笈》豆瓣评分：8.2分
一本关于Web设计原则而不是Web设计技术的书，作者用幽默的语言揭示Web设计中重要但却容易被忽视的问题，只需几个小时，便能对照书中讲授的设计原则找到网站设计的症结所在，常看常新。
三、软件设计模式领域的里程碑著作
《设计模式》豆瓣评分：9.1分
设计模式不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性以及安全性的解决方案，一般的大型项目开发或者框架设计，都会用设计模式来组织代码。
本书从面向对象的设计中精选出23个设计模式，面向对象开发必读，虽然随着动态语言的发展，很多模式都已经融入到语言当中，但是作为一个好的开发者，这本书讲的不是模式本身，而是模式的轨迹。
四、转变一下程序员的思维，认识交互设计的重要性
《交互设计之路》豆瓣评分：7.9分
虽然书中不乏“黑”程序员的桥段，但却是程序员很好的交互设计启蒙书。作者通过列举真实案例，讨论由于产品设计中存在“认知摩擦”引起的“难用”问题，讲述如何创建更好的、高客户忠诚度的软件产品和基于软件的高科技产品。
五、面对漫长的职业生涯，静下心来追求“良质”
《禅与摩托车维修艺术》豆瓣评分：8.3分

一本非典型的适合程序员阅读的哲学书，霍金、乔布斯都曾推荐过。书中讲述作者和儿子骑摩托车旅游路途所悟到的“禅”，其中最关键的就是“良质”。
举个例子，写程序跟维修摩托车一样，有时候会枯燥、机械且乏味，但如果用“良质”的境界用心去对待这件事，找到内心的平衡，最好能达到“物我两忘”的境界，最终的结果就是另一番局面了。
程序员的第四阶段：架构师、CTO（10年以上）
恭喜你，已经进阶到程序员的金字塔顶端了！入行有10多年经验的你，有过项目开发经历，精通多门编程语言且熟悉数据库，对行业、技术、产品都有了深层次的认识，带好团队成为更关键的业务能力。
一、为解决架构设计模式中的“疑难杂症”打开思路
《企业应用架构模式》豆瓣评分：8.3分

将40多种常见的解决方案转化成模式，每个模式都给出使用方法和实现信息，并配以详细的Java代码或C#代码示例。
虽然书中有些内容放在现在有点过时，但如网友所言，在今天的开发思想环境下，也许再也不会出来这样一本重量级的企业架构模式的书，甚至其中的很多模式会被觉得太重，太Java/.NET，但这才是真正的大型软件项目应有的架构模式，值得每一个程序员细细品味。
二、跟着国外技术大佬学团队管理
《极客与团队》豆瓣评分：8.3分

程序员办公室政治指南，谷歌技术大佬以自身的经历为基础，阐明了团队合作的重要性，提出了加强合作的具体方法，并辅以实例进行了深入分析。全文主要从三个角度介绍了团队合作的方法：如何处理团队中有关人的方面；如何在良好或不佳的公司中工作；如何与用户合作创造更出众的产品。
三、带领团队完成敏捷转型
《敏捷转型：打造VUCA时代的高效能组织》豆瓣评分：9.2分

为了帮助更多期待转型或者处于转型过程中的企业走出误区、突破阻碍，本书重点阐述了敏捷转型的步骤、方法和策略，用大量真实的案例，生动还原敏捷转型容易走入的误区，以及企业在转型过程中常见的疑惑。
四、从技术人员转型为领导者，系统提高技术领导力
《成为技术领导者》豆瓣评分：8.3分

很多技术人员固有思维会阻碍真正的交流，甚至忽略真正的问题，这本书能够清晰的指出这些事情。
作为一名成功领导者所必须掌握的领导方法与技巧——创新、激励和组织（MOI模型）。本书提出了一些方法，供技术人员分析自己在这三个方面的领导技巧，并提供了开发这些技巧所需的实践步骤。
五、架构师也好，CTO也罢，管理团队有时候比技术能力更重要
《人件》豆瓣评分：8.2分

从管理人力资源、创建健康的办公环境、雇用并留用正确的人、高效团队形成、改造企业文化和快乐工作等多个角度，阐释了如何思考和管理软件开发的最大问题——人（而不是技术），以得到高效的项目和团队。
本书的一个基本出发点就是，管理者不应该把员工看作冷冰冰的机器或可随时替换的零件，而应尊重他们的生物、社会属性，当成有血有肉的“人件”来管理。
结语：
以上列举的20本书，虽然不能做到面面俱到，但可以从“术”的层面，为想要摆脱焦虑、走上技术进阶之路的程序员指点迷津，钻研出职业进阶的“道”。
欢迎大家收藏本书单，阅读计划安排起来！

这篇文章根据我多年的工作经验，给新人总结了25条建议，希望对你会有所帮助。
1.写好注释
很多小伙伴不愿意给代码写注释，主要有以下两个原因：
开发时间太短了，没时间写注释。《重构》那本书说代码即注释。
我在开发的前面几年也不喜欢写注释，觉得这是一件很酷的事情。
但后来发现，有些两年之前的代码，业务逻辑都忘了，有些代码自己都看不懂。特别是有部分非常复杂的逻辑和算法，需要重新花很多时间才能看明白，可以说自己把自己坑了。
没有注释的代码，不便于维护。
因此强烈建议大家给代码写注释。
但注释也不是越多越好，注释多了增加了代码的复杂度，增加了维护成本，给自己增加工作量。
我们要写好注释，但不能太啰嗦，要给关键或者核心的代码增加注释。我们可以写某个方法是做什么的，主要步骤是什么，给算法写个demo示例等。
这样以后过了很长时间，再去看这段代码的时候，也会比较容易上手。
最近无意间获得一份BAT大厂大佬写的刷题笔记，一下子打通了我的任督二脉，越来越觉得算法没有想象中那么难了。
[BAT大佬写的刷题笔记，让我offer拿到手软](这位BAT大佬写的Leetcode刷题笔记，让我offer拿到手软)
2.多写单元测试
我看过身边很多大佬写代码有个好习惯，比如新写了某个Util工具类，他们会同时在test目录下，给该工具类编写一些单元测试代码。
很多小伙伴觉得写单元测试是浪费时间，没有这个必要。
假如你想重构某个工具类，但由于这个工具类有很多逻辑，要把这些逻辑重新测试一遍，要花费不少时间。
于是，你产生了放弃重构的想法。
但如果你之前给该工具类编写了完整的单元测试，重构完成之后，重新执行一下之前的单元测试，就知道重构的结果是否满足预期，这样能够减少很多的测试时间。
多写单元测试对开发来说，是一个非常好的习惯，有助于提升代码质量。
即使因为当初开发时间比较紧，没时间写单元测试，也建议在后面空闲的时间内，把单元测试补上。
3.主动重构自己的烂代码
好的代码不是一下子就能写成的，需要不断地重构，修复发现的bug。
不知道你有没有这种体会，看自己1年之前写的代码，简直不忍直视。
这说明你对业务或者技术的理解，比之前更深入了，认知水平有一定的提升。
如果有机会，建议你主动重构一下自己的烂代码。把重复的代码，抽取成公共方法。有些参数名称，或者方法名称当时没有取好的，可以及时修改一下。对于逻辑不清晰的代码，重新梳理一下业务逻辑。看看代码中能不能引入一些设计模式，让代码变得更优雅等等。
通过代码重构的过程，以自我为驱动，能够不断提升我们编写代码的水平。
4.代码review很重要
有些公司在系统上线之前，会组织一次代码评审，一起review一下这个迭代要上线的一些代码。
通过相互的代码review，可以发现一些代码的漏洞，不好的写法，发现自己写代码的坏毛病，让自己能够快速提升。
当然如果你们公司没有建立代码的相互review机制，也没关系。
可以后面可以多自己review自己的代码。
5.多用explain查看执行计划
我们在写完查询SQL语句之后，有个好习惯是用explain关键字查看一下该SQL语句有没有走索引。
对于数据量比较大的表，走了索引和没有走索引，SQL语句的执行时间可能会相差上百倍。
我之前亲身经历过这种差距。
因此建议大家多用explain查看SQL语句的执行计划。
关于explain关键字的用法，如果你想进一步了解，可以看看我的另外一篇文章《explain | 索引优化的这把绝世好剑，你真的会用吗？》，里面有详细的介绍。
6.上线前整理checklist
在系统上线之前，一定要整理上线的清单，即我们说的：checklist。
系统上线有可能是一件很复杂的事情，涉及的东西可能会比较多。
假如服务A依赖服务B，服务B又依赖服务C。这样的话，服务发版的顺序是：CBA，如果顺序不对，可能会出现问题。
有时候新功能上线时，需要提前执行sql脚本初始化数据，否则新功能有问题。
要先配置定时任务。
上线之前，要在apollo中增加一些配置。
上线完成之后，需要增加相应的菜单，给指定用户或者角色分配权限。
等等。
系统上线，整个过程中，可能会涉及多方面的事情，我们需要将这些事情记录到checklist当中，避免踩坑。
俗话说：在家靠父母、出门靠朋友，为了感谢各位粉丝朋友对，苏三的关注和支持，我特地为粉丝提供了一些工作的内推群的机会，这些公司分布在北京、上海、广州、深圳、杭州、重庆、武汉、南京、郑州、西安、苏州、东莞等城市，内推人是我本人或者工作中/生活中/网络中认识的朋友们，来自各个大厂，非常的靠谱，直接真内推渠道能帮您增加面试的机会和通过的机率。

坑不多，没有需求的，就不要进了。
进群方式，加微信：su_san_java，备注：内推
7.写好接口文档
接口文档对接口提供者，和接口调用者来说，都非常重要。
如果你没有接口文档，别人咋知道你接口的地址是什么，接口参数是什么，请求方式时什么，接口多个参数分别代码什么含义，返回值有哪些字段等等。
他们不知道，必定会多次问你，无形当中，增加了很多沟通的成本。
如果你的接口文档写的不好，写得别人看不懂，接口文档有很多错误，比如：输入参数的枚举值，跟实际情况不一样。
这样不光把自己坑了，也会把别人坑惨。
因此，写接口文档一定要写好，尽量不要马马虎虎应付差事。
如果对写接口文档比较感兴趣，可以看看我的另一篇文章《瞧瞧别人家的API接口，那叫一个优雅》，里面有详细的介绍。
8.接口要提前评估请求量
我们在设计接口的时候，要跟业务方或者产品经理确认一下请求量。
假如你的接口只能承受100qps，但实际上产生了1000qps。
这样你的接口，很有可能会承受不住这么大的压力，而直接挂掉。
我们需要对接口做压力测试，预估接口的请求量，需要部署多少个服务器节点。
压力测试的话，可以用jmeter、loadRunner等工具。
此外，还需要对接口做限流，防止别人恶意调用你的接口，导致服务器压力过大。
限流的话，可以基于用户id、ip地址、接口地址等多个维度同时做限制。
可以在nginx层，或者网关层做限流。
9.接口要做幂等性设计
我们在设计接口时，一定要考虑并发调用的情况。
比如：用户在前端页面，非常快的点击了两次保存按钮，这样就会在极短的时间内调用你两次接口。
如果不做幂等性设计，在数据库中可能会产生两条重复的数据。
还有一种情况时，业务方调用你这边的接口，该接口发生了超时，它有自动重试机制，也可能会让你这边产生重复的数据。
因此，在做接口设计时，要做幂等设计。
当然幂等设计的方案有很多，感兴趣的小伙伴可以看看我的另一篇文章《高并发下如何保证接口的幂等性？》。
如果接口并发量不太大，推荐大家使用在表中加唯一索引的方案，更加简单。
10.接口参数有调整一定要慎重
有时候我们提供的接口，需要调整参数。
比如：新增加了一个参数，或者参数类型从int改成String，或者参数名称有status改成auditStatus，参数由单个id改成批量的idList等等。
建议涉及到接口参数修改一定要慎重。
修改接口参数之前，一定要先评估调用端和影响范围，不要自己偷偷修改。如果出问题了，调用方后面肯定要骂娘。
我们在做接口参数调整时，要做一些兼容性的考虑。
其实删除参数和修改参数名称是一个问题，都会导致那个参数接收不到数据。
因此，尽量避免删除参数和修改参数名。
对于修改参数名称的情况，我们可以增加一个新参数，来接收数据，老的数据还是保留，代码中做兼容处理。
11.调用第三方接口要加失败重试
我们在调用第三方接口时，由于存在远程调用，可能会出现接口超时的问题。
如果接口超时了，你不知道是执行成功，还是执行失败了。
这时你可以增加自动重试机制。
接口超时会抛一个connection_timeout或者read_timeout的异常，你可以捕获这个异常，用一个while循环自动重试3次。
这样就能尽可能减少调用第三方接口失败的情况。
当然调用第三方接口还有很多其他的坑，感兴趣的小伙伴可以看看我的另一篇文章《我调用第三方接口遇到的13大坑》，里面有详细的介绍。
12.处理线上数据前，要先备份数据
有时候，线上数据出现了问题，我们需要修复数据，但涉及的数据有点多。
这时建议在处理线上数据前，一定要先备份数据。
备份数据非常简单，可以执行以下sql：

create table order_2022121819 like `order`;
insert into order_2022121819 select * from `order`;

数据备份之后，万一后面哪天数据处理错了，我们可以直接从备份表中还原数据，防止悲剧的产生。
13.不要轻易删除线上字段
不要轻易删除线上字段，至少我们公司是这样规定的。
如果你删除了某个线上字段，但是该字段引用的代码没有删除干净，可能会导致代码出现异常。
假设开发人员已经把程序改成不使用删除字段了，接下来如何部署呢？
如果先把程序部署好了，还没来得及删除数据库相关表字段。
当有insert请求时，由于数据库中该字段是必填的，会报必填字段不能为空的异常。
如果先把数据库中相关表字段删了，程序还没来得及发。这时所有涉及该删除字段的增删改查，都会报字段不存在的异常。
所以，线上环境字段不要轻易删除。
如果你想成为架构师，这篇文章可以帮助你
如果你想获得项目实战经验，这这篇文章可以帮助你
14.要合理设置字段类型和长度
我们在设计表的时候，要给相关字段设置合理的字段类型和长度。
如果字段类型和长度不够，有些数据可能会保存失败。
如果字段类型和长度太大了，又会浪费存储空间。
我们在工作中，要根据实际情况而定。
以下原则可以参考一下：
尽可能选择占用存储空间小的字段类型，在满足正常业务需求的情况下，从小到大，往上选。如果字符串长度固定，或者差别不大，可以选择char类型。如果字符串长度差别较大，可以选择varchar类型。是否字段，可以选择bit类型。枚举字段，可以选择tinyint类型。主键字段，可以选择bigint类型。金额字段，可以选择decimal类型。时间字段，可以选择timestamp或datetime类型。15.避免一次性查询太多数据
我们在设计接口，或者调用别人接口的时候，都要避免一次性查询太多数据。
一次性查询太多的数据，可能会导致查询耗时很长，更加严重的情况会导致系统出现OOM的问题。
我们之前调用第三方，查询一天的指标数据，该接口经常出现超时问题。
在做excel导出时，如果一次性查询出所有的数据，导出到excel文件中，可能会导致系统出现OOM问题。
因此我们的接口要做分页设计。
如果是调用第三方的接口批量查询接口，尽量分批调用，不要一次性根据id集合查询所有数据。
如果调用第三方批量查询接口，对性能有一定的要求，我们可以分批之后，用多线程调用接口，最后汇总返回数据。
俗话说：在家靠父母、出门靠朋友，为了感谢各位粉丝朋友对，苏三的关注和支持，我特地为粉丝提供了一些工作的内推群的机会，这些公司分布在北京、上海、广州、深圳、杭州、重庆、武汉、南京、郑州、西安、苏州、东莞等城市，内推人是我本人或者工作中/生活中/网络中认识的朋友们，来自各个大厂，非常的靠谱，直接真内推渠道能帮您增加面试的机会和通过的机率。

坑不多，没有需求的，就不要进了。
进群方式，加微信：su_san_java，备注：内推
16.多线程不一定比单线程快
很多小伙伴有一个误解，认为使用了多线程一定比使用单线程快。
其实要看使用场景。
如果你的业务逻辑是一个耗时的操作，比如：远程调用接口，或者磁盘IO操作，这种使用多线程比单线程要快一些。
但如果你的业务逻辑非常简单，在一个循环中打印数据，这时候，使用单线程可能会更快一些。
因为使用多线程，会引入额外的消耗，比如：创建新线程的耗时，抢占CPU资源时线程上下文需要不断切换，这个切换过程是有一定的时间损耗的。
因此，多线程不一定比单线程快。我们要根据实际业务场景，决定是使用单线程，还是使用多线程。
17.注意事务问题
很多时候，我们的代码为了保证数据库多张表保存数据的完整性和一致性，需要使用@Transactional注解的声明式事务，或者使用TransactionTemplate的编程式事务。
加入事务之后，如果A,B,C三张表同时保存数据，要么一起成功，要么一起失败。
不会出现数据保存一半的情况，比如：表A保存成功了，但表B和C保存失败了。
这种情况数据会直接回滚，A,B,C三张表的数据都会同时保存失败。
如果使用@Transactional注解的声明式事务，可能会出现事务失效的问题，感兴趣的小伙伴可以看看我的另一篇文章《聊聊spring事务失效的12种场景，太坑了》。
建议优先使用TransactionTemplate的编程式事务的方式创建事务。
此外，引入事务还会带来大事务问题，可能会导致接口超时，或者出现数据库死锁的问题。
因此，我们需要优化代码，尽量避免大事务的问题，因为它有许多危害。关于大事务问题，感兴趣的小伙伴，可以看看我的另一篇文章《让人头痛的大事务问题到底要如何解决？》，里面有详情介绍。
18.小数容易丢失精度
不知道你在使用小数时，有没有踩过坑，一些运算导致小数丢失了精度。
如果你在项目中使用了float或者double类型的数据，用他们参与计算，极可能会出现精度丢失问题。
使用Double时可能会有这种场景：

double amount1 = 0.02;
double amount2 = 0.03;
System.out.println(amount2 - amount1);

正常情况下预计amount2 - amount1应该等于0.01
但是执行结果，却为：

0.009999999999999998

实际结果小于预计结果。
Double类型的两个参数相减会转换成二进制，因为Double有效位数为16位这就会出现存储小数位数不够的情况，这种情况下就会出现误差。
因此，在做小数运算时，更推荐大家使用BigDecimal，避免精度的丢失。
但如果在使用BigDecimal时，使用不当，也会丢失精度。

BigDecimal amount1 = new BigDecimal(0.02);
BigDecimal amount2 = new BigDecimal(0.03);
System.out.println(amount2.subtract(amount1));

这个例子中定义了两个BigDecimal类型参数，使用构造函数初始化数据，然后打印两个参数相减后的值。
结果：

0.0099999999999999984734433411404097569175064563751220703125

使用BigDecimal的构造函数创建BigDecimal，也会导致精度丢失。
如果如何避免精度丢失呢？

BigDecimal amount1 = BigDecimal.valueOf(0.02);
BigDecimal amount2 = BigDecimal.valueOf(0.03);
System.out.println(amount2.subtract(amount1));

使用BigDecimal.valueOf方法初始化BigDecimal类型参数，能保证精度不丢失。
如果你想成为架构师，这篇文章可以帮助你
如果你想获得项目实战经验，这篇文章可以帮助你
19.优先使用批量操作
有些小伙伴可能写过这样的代码，在一个for循环中，一个个调用远程接口，或者执行数据库的update操作。
其实，这样是比较消耗性能的。
我们尽可能将在一个循环中多次的单个操作，改成一次的批量操作，这样会将代码的性能提升不少。
例如：

for(User user : userList) {
   userMapper.update(user);
}

改成：

userMapper.updateForBatch(userList);

20.synchronized其实用的不多
我们在面试中当中，经常会被面试官问到synchronized加锁的考题。
说实话，synchronized的锁升级过程，还是有点复杂的。
但在实际工作中，使用synchronized加锁的机会不多。
synchronized更适合于单机环境，可以保证一个服务器节点上，多个线程访问公共资源时，只有一个线程能够拿到那把锁，其他的线程都需要等待。
但实际上我们的系统，大部分是处于分布式环境当中的。
为了保证服务的稳定性，我们一般会把系统部署到两个以上的服务器节点上。
后面哪一天有个服务器节点挂了，系统也能在另外一个服务器节点上正常运行。
当然也能会出现，一个服务器节点扛不住用户请求压力，也挂掉的情况。
这种情况，应该提前部署3个服务节点。
此外，即使只有一个服务器节点，但如果你有api和job两个服务，都会修改某张表的数据。
这时使用synchronized加锁也会有问题。
因此，在工作中更多的是使用分布式锁。
目前比较主流的分布式锁有：
数据库悲观锁。基于时间戳或者版本号的乐观锁。使用redis的分布式锁。使用zookeeper的分布式锁。
其实这些方案都有一些使用场景。
目前使用更多的是redis分布式锁。
当然使用redis分布式锁也很容易踩坑，感兴趣的小伙伴可以看看我的另一篇文章《聊聊redis分布式锁的8大坑》，里面有详细介绍。
21.异步思想很重要
不知道你有没有做过接口的性能优化，其中有一个非常重要的优化手段是：异步。
如果我们的某个保存数据的API接口中的业务逻辑非常复杂，经常出现超时问题。
现在让你优化该怎么优化呢？
先从索引，sql语句优化。
这些优化之后，效果不太明显。
这时该怎么办呢？
这就可以使用异步思想来优化了。
如果该接口的实时性要求不高，我们可以用一张表保存用户数据，然后使用job或者mq，这种异步的方式，读取该表的数据，做业务逻辑处理。
如果该接口对实效性要求有点高，我们可以梳理一下接口的业务逻辑，看看哪些是核心逻辑，哪些是非核心逻辑。
对于核心逻辑，可以在接口中同步执行。
对于非核心逻辑，可以使用job或者mq这种异步的方式处理。
22.Git提交代码要有好习惯
有些小伙伴，不太习惯在Git上提交代码。
非常勤劳的使用idea，写了一天的代码，最后下班前，准备提交代码的时候，电脑突然死机了。
会让你欲哭无泪。
用Git提交代码有个好习惯是：多次提交。
避免一次性提交太多代码的情况。
这样可以减少代码丢失的风险。
更重要的是，如果多个人协同开发，别人能够尽早获取你最新的代码，可以尽可能减少代码的冲突。
假如你开发一天的代码准备去提交的时候，发现你的部分代码，别人也改过了，产生了大量的冲突。
解决冲突这个过程是很痛苦的。
如果你能够多次提交代码，可能会及时获取别人最新的代码，减少代码冲突的发生。因为每次push代码之前，Git会先检查一下，代码有没有更新，如果有更新，需要你先pull一下最新的代码。
此外，使用Git提交代码的时候，一定要写好注释，提交的代码实现了什么功能，或者修复了什么bug。
如果有条件的话，每次提交时在注释中可以带上jira任务的id，这样后面方便统计工作量。
23.善用开源的工具类
我们一定要多熟悉一下开源的工具类，真的可以帮我们提升开发效率，避免在工作中重复造轮子。
目前业界使用比较多的工具包有：apache的common，google的guava和国内几个大佬些hutool。
比如将一个大集合的数据，按每500条数据，分成多个小集合。
这个需求如果要你自己实现，需要巴拉巴拉写一堆代码。
但如果使用google的guava包，可以非常轻松的使用：

List<Integer> list = Lists.newArrayList(1, 2, 3, 4, 5);
List<List<Integer>> partitionList = Lists.partition(list, 2);
System.out.println(partitionList);

如果你对更多的第三方工具类比较感兴趣，可以看看我的另一篇文章《吐血推荐17个提升开发效率的“轮子”》。
24.培养写技术博客的好习惯
我们在学习新知识点的时候，学完了之后，非常容易忘记。
往往学到后面，把前面的忘记了。
回头温习前面的，又把后面的忘记了。
因此，建议大家培养做笔记的习惯。
我们可以通过写技术博客的方式，来记笔记，不仅可以给学到的知识点加深印象，还能锻炼自己的表达能力。
此外，工作中遇到的一些问题，以及解决方案，都可以沉淀到技术博客中。
一方面是为了避免下次犯相同的错误。
另一方面也可以帮助别人少走弯路。
而且，在面试中如果你的简历中写了技术博客地址，是有一定的加分的。
因此建议大家培养些技术博客的习惯。
25.多阅读优秀源码
建议大家利用空闲时间，多阅读JDK、Spring、Mybatis的源码。
通过阅读源码，可以真正的了解某个技术的底层原理是什么，这些开源项目有哪些好的设计思想，有哪些巧妙的编码技巧，使用了哪些优秀的设计模式，可能会出现什么问题等等。
当然阅读源码是一个很枯燥的过程。
有时候我们会发现，有些源码代码量很多，继承关系很复杂，使用了很多设计模式，一眼根本看不明白。
对于这类不太容易读懂的源码，我们不要一口吃一个胖子。
要先找一个切入点，不断深入，由点及面的阅读。
我们可以通过debug的方式阅读源码。
在阅读的过程中，可以通过idea工具，自动生成类的继承关系，辅助我们更好的理解代码逻辑。
我们可以一边读源码，一边画流程图，可以更好的加深印象。
当然还有很多建议，由于篇幅有限，后面有机会再跟大家分享。
最近无意间获得一份阿里大佬写的刷题笔记，一下子打通了我的任督二脉，进大厂原来没那么难。

链接：https://pan.baidu.com/s/1UECE5yuaoTTRpJfi5LU5TQ 密码：bhbe
不会有人刷到这里还想白嫖吧？点赞对我真的非常重要！在线求赞。加个关注我会非常感激！
@苏三说技术

1、好的程序员一定是懂业务的。不管你是否要专心做技术大佬，一定尽可能搞清楚自己服务的业务，包括产品、运营、营销、用户体验等等。很多程序员会忽视业务，觉得把自己分内的技术活做好就行，其实这很容易让自己形成一种“技术等于一切”的假象，其实技术是服务业务的，业务才能创造价值。
2、很多事都是孰能生巧，没有足够多练习不要提天赋。编程应该是最能体验prctice make perfect的技能之一，在前期积累的阶段，往往要大量的去刷题、比赛、模仿，才能显得游刃有余。资深码农就像是老师傅，哪个不是键盘敲到发白。
3、愚者困惑，智者提问。如果你是程序员，会发现有大量的技术网站和博客，比如stackoverflow、csdn、博客园、github、掘金等等，似乎程序员比其他行业更需要交流和分享。
编程教给我最好的学习方法就是提问和搜索，遇到bug我可以百度、谷歌，肯定有现成的答案等着你，因为你遇到的难题前人基本都遇到过，并且绝大多数都给出了答案。
所以，遇到不懂的，首先网上搜索，然后找厉害的人求助、讨论，新手程序员一定要有这样的机制，不然很难成长。
4、最简单的往往是最有效的。很多人喜欢把简单的事复杂化，比如说一个线性回归能解决的事，非要用神经网络，浪费大量机器资源，跑出来的效果也不好。其实在编程领域，往往简单胜于复杂。
5、英语水平决定一个程序员的上限。当你开始学习一门编程技术，你会发现但凡优质的文档、博客、网站、开源项目，大多都是英文，更不要说论文、专利、比赛之类。
现在很多的中文技术资料都是翻译过来的，相当于二手知识，准确性存在很大问题。而且通过翻译学习技术，你很难追踪技术领域最新的变化，自然天花板就低了。
6、善于使用ChatGPT等AI技术。我知道还有很多人对AI大模型抱有不屑一顾的态度，觉得噱头大于实际，但ChatGPT等AI应用已经在编程、内容、自动化、科研等领域快速渗透，一天一个模样，变化非常之快。
作为程序员应该善于使用AI提升自己的效率和视野，我相信这会是今后最大的变革。举一反三，程序员应该拥抱任何新的技术，让自己更加开阔。
7、向成功者学习，向成功的项目学习。做开发，有个特别好的途径是研究高手写的程序。如果自己无法写出好的产品，那就模仿别人的优秀产品，久而久之，蓬生麻中，不扶自直。
8、要有良好的习惯，才能事半功倍。编程是一项系统工程，就和写小说、建大厦一样，所以需要有模式、规矩、条理，才能不至于变成“屎山”。建议大家在写一个程序之前，可以用脑图软件理一下思路，也可以用伪代码提炼核心逻辑。
9、有闭环思维。闭环思维很重要，决定你是否能把一件事情做好，成为一个靠谱的人。所谓闭环思维，简单点讲，就是无论做什么事，都能有始有终，能形成一个完整的闭环。
闭环思维有五个核心：凡事有计划，约定必落实，问题早知会，及时报进程，事后须反馈。
有个科学管理闭环思维的方法，就是PDCA原则。
-P (计划 PLAN) :从问题的定义到行动计划
·D (实施 DO) :实施行动计划
·C (检查 CHECK) :评估结果
·A (处理 ACT) :标准化和进一步推广
程序员大佬能够独当一面，闭环思维起了很大作用。

最近看了耗子叔刚刚出版的《左耳听风：传奇程序员练级攻略》，非常有料，强烈建议小伙伴们阅读，看看耗子叔给刚入行程序员的一点建议。

广告
左耳听风：传奇程序员练级攻略(博文视点出品)
京东
￥59.00
去购买?
技术更新的速度越来越快，紧跟技术前进的步伐这件事的难度就越来越大。此时，或许可以选择另辟蹊径，关注不怎么变化的部分，比如基础知识。原因是虽然很多基础知识多年来都没有太大变化，但是它们同样重要，甚至变得更加重要。可见，在变化中找到不变的东西很重要。
那什么是不变的东西呢？计算机基础知识、操作系统的原理、编程范式、算法结构和数据结构，等等。无论编程语言如何变化，这些基础知识都是不变的。
学习这些基础知识可能会很枯燥，但对于想要深入学习计算机技术的人来说，它们是必须要掌握的。当你打好基础后，学习上层的知识就会变得比较容易。
如果只浅显地学习一门技术，那么当技术发生变化时，你就会感到无所适从。而具备扎实的基础，你的学习能力就会提高，从而在新技术出现时才有可能以不变应万变。
比如，很多人跟不上云原生的变革，我可以从基础原理的角度来做出解读。云计算解决的是中间件、服务器、存储层面的运维，且云计算上的开源软件只提供源代码，不能解决应用的高可用性问题。云原生则可以解决应用的高可用性问题。云计算提供的是中间件的服务，而不是应用的架构。云原生则通过微服务架构和容器化技术解决了整个应用架构的稳定性问题。在云原生环境下，只要软件架构设计得好，基础架构相对而言就没那么重要。云原生作为新的力量，将颠覆云计算领域的格局。所以，尽管云计算总是宣称自己的基础架构高可用，可以保证用户的应用高可用，但事实上，只有软件架构高可用，基础架构才能高可用。
另外，想跟上技术迭代的速度，技术的交流也很重要。以曾一度在国内走热的可观测性为例。在国内走热前，由于对分布式系统很重要，可观测性在国外已经火了很长时间，我2016年创业，做的第一个产品就是关于可观测性的。国内之所以后知后觉，可能是受信息茧房所困。所以，多读英文文档、多参加英文社区的讨论，对跟上技术的发展速度也有立竿见影的效果。

现在入行相当于赶上了末班车，赶紧卷技术，早点把薪资涨上去，不卷很可能淘汰掉。

1、技术至上是程序员的一厢情愿罢了。
2、学会抱大腿比埋头苦干更重要。
3、身体是自己的，工作是公司的，活永远干不完，别太玩命。
4、衡量领导是否真的重视你的唯一标准就是：给你升职加薪，除此之外都是画饼。
5、当领导给你打感情牌的时候，就是再给你画饼。
6、程序员升职加薪的唯一秘诀：跳槽！
7、技术是为业务服务的，一名优秀的程序员，一定要懂业务的深度与广度。
8、在35岁之前，赶紧赚钱，尽可能多赚钱，哪家公司给的工资高就去哪家。到口袋里的钱才是最实在的，其他都是虚的。
9、早点找个女朋友吧。
10、拥抱AI，拥抱未来。
都看到这了，不点个赞说不过去了吧。

看了其他答案，我这个已经35岁的老一线开发，觉得在思考这个问题之前，要搞清楚自己想要什么，这个问题很重要。
我自己是没卷赢同龄人和晚辈，干了十几年，收入也不高，但我还是继续在干，因为我就喜欢这行。
很多人在说卷，说的是卷大公司，卷高薪岗位，我觉得这些都不是要不要做程序员的主要矛盾。2010年-2020年是移动互联网的爆发期，资本涌入让大家能比别人多喝口汤，大家扎推来做这个事，学相关专业，没问题，但要先问问自己是否是真的喜欢干这行。
比这行挣钱多，更轻松的行业也不是没有，当然我不是劝退，而是鼓励真的喜欢编程的人，好好做，哪怕不做这行，编程也是很好的技能，可以和很多行业结合。
但是不喜欢的人，硬来，只为搞钱。我觉得是没啥意义的，还是做自己喜欢的事，优先。

相较于技术成长，多读读人文类书籍提高自己的情商是必不可少的。
技术的快速成长会在前期帮助你拿到比较高的薪水，但你能不能在这一行活下去，能活多久说实话，不只是光靠技术就能决定的。甚至，后期技术影响占比可能会越来越小。（当然，只是让你重视情商的提高，千万不要曲解，误以为技术不重要）
毕竟公司不会在乎你技术有多高，在乎的是你的技术能给他解决什么问题，带来什么效益。

1态度要好，多说"谢谢"，保持谦虚，不懂装懂最致命，放下自己所谓的自尊心，被别人说了，乐呵呵的笑笑就好，别急眼。
2派活给你的时候积极响应，不要推三阻四，能给你的都是老人评估过觉得你这个能力范围能接的，你做就完事了，不懂随时问就好。
3.活做完了，立马告诉派活的人，不要等派活的人主动来问你做完了没，你将超越50%的人。
4.手上没活了，主动跟带你的人或领导去要点活。你将超越90%的人。
5.能力不足的时候，唯有靠谱才是必杀技。什么是靠谱？"件件有着落，事事有回应"。
如果遇到我没提到的点，大家可以换位思考下。如果你是老程序员，你愿意带怎么样的人？
我看中三个点，一个是懂感恩，一个是靠谱，再一个是努力。
举个反例，我曾经带过一个top5大学的高材生，人很聪明，给活也干。但为人躺平，办事不靠谱。
正因为不靠谱，我根本不敢将复杂一点的活给他干，因为干砸了我还得给他擦屁股。
正因为早早躺平，所以就算他很聪明，学啥都快，但只要我不教，他也从来不会主动去学，工作一年多也没啥成长。
最最重要的是，在多次帮他擦完屁股后，我甚至没听到过一句感谢，就好像一切都是理所应当的一样。
那么问题来了，这样的人，你愿意再花时间精力在他身上吗？
好了，建议就给到这了。祝入行愉快！

马上转行，这个行业已经被妖魔化了

去国企央企还行，互联网不建议去了
现在变得越来越卷，首先晋升难，原先p6差不多点击就送，现在p5升p6都卡通过率，社招职级卡得也严格
降本增效，除了极少数大厂和独角兽，其他薪资很抠，涨幅与付出的成本不成比例

[收藏本文] 【下载本文】

科技知识最新文章

《消失的问界里》为什么网传华为选择大面积

特斯拉万人大裁员涉及中国市场，销售部门是

媒体报道「特斯拉一天内失去 2 个高管和 10

去年是「大模型元年」，今年会是「AI应用落

2024 年人工智能方向的就业前景怎么样？

上一篇文章查看所有文章

加:2024-03-12 12:02:54 更:2024-03-12 12:07:11

股票涨跌实时统计涨停板选股分时图选股跌停板选股 K线图选股成交量选股均线选股趋势线选股筹码理论波浪理论缠论 MACD指标 KDJ指标 BOLL指标 RSI指标炒股基础知识炒股故事

网站联系: qq:121756557 email:121756557@qq.com 天天财汇