干了十几年程序员，现在回头看，有几件事对我的成长影响非常大，甚至可以说塑造了我对这份职业的基本认知。
兴趣，是一切的前提。编程是可以干漫长时间的，前提是你得真喜欢。这不是指刚入行时的新鲜感，而是写了好几年之后，遇到一个有意思的技术问题，你还是会忍不住想深挖下去。有这种状态的人，不需要别人推着走，他自己就会定期回头看看：这一年我进步了多少？哪些地方做得不错，哪些地方还差得远？这种反思往往是自然而然的，因为你打算长期干下去，自然会关心自己干得好不好。
反过来看，如果对编程缺乏热情，很容易陷入一种状态：接到需求就做，做完交差，然后等待下一个。年复一年，技术没什么长进，工作也没什么成就感，更别提长远的 职业规划。
有了真正的兴趣之后，你对待代码的态度会彻底改变，你会开始有一种 敬畏心。这个词听起来有点大，但非常准确。它意味着你不会随手就写代码，不会拿到需求立刻敲键盘。你会先停下来想一想：这个功能该怎么设计？接口怎么定义才合理？用什么数据结构最合适？异常情况又该如何处理？你会用一种“慢”的心态去思考和决策，而不是赶着把功能堆出来。
我见过两类人写代码。一类人接到需求后，会花半天时间想清楚方案，然后用一两天写出来，代码结构清晰，边界情况考虑到位，后续维护成本极低。另一类人半小时就开始写，三小时就提交了，看似效率很高，但后面修改bug、处理各种边界问题所花的时间，加起来远超前者。有敬畏心的人，对得起自己写的每一行代码，也对得起要读这些代码的同事。 赶工交差的代码和认真设计过的代码，表面上功能都能跑，但在可维护性、可扩展性上的差距，天壤之别。
敬畏心还会驱使你去追问更深层的东西。你不会满足于“会用就行”，你会想知道“它为什么是这样”。这就引出了另一个关键认知：知其然，更要知其所以然。
知道一个框架怎么用，和知道它为什么这样设计、底层走的什么机制，完全是两码事。前者是技能，后者才是知识。技能会过时，比如 Spring Boot 今天还是 2.x，明天可能就变成了 3.x，API 变了你就得重新学。但如果你理解了它背后的自动装配原理、条件注入的设计思想，那么版本再怎么迭代，你都能很快上手，因为核心的设计理念没有变。只有经过深度理解和分析的东西，才能真正内化为你的知识。有了知识，你就能解决未知的问题，而不仅仅是使用熟悉的工具。
举个例子，线上服务响应变慢。一般人能想到的是加缓存、扩容、优化 SQL。这些手段没错，但如果你不理解“慢”的根因，这些操作可能都是无效的。如果你理解了线程模型，知道连接池的工作原理，看得懂 GC 日志，能分析慢查询的执行计划，你才能精准定位问题出在哪一层。这种能力不是靠搜索引擎和反复试错积攒出来的，是靠平时一点一点积累底层认知得来的。这种对系统工作原理的深度探索，正是我们在 开源实战 板块鼓励大家去做的事情。
要做到知其所以然，就必须沉下去看 细节。这里说的细节不是代码里变量命名之类的表面功夫，而是每一层技术栈里真正在发生什么。数据从客户端发出，经过网络到达服务端，在操作系统内核里经历了什么，被 Web 容器接收后如何分发到你的业务代码，业务代码调用数据库连接池时，连接池内部是如何管理连接的，SQL 到了 MySQL 之后经过了哪些阶段，结果又如何一路返回到应用层。这条链路上的每一环，你了解得越多，遇到问题时排查的范围就越大，定位的速度就越快。
有些人排查线上问题又快又准，不是因为运气好，是因为他脑子里有足够多的细节。看到一个现象，他能马上关联到可能的原因。没有这些积累的人，只能一层层地猜、一步步地试，效率差距非常明显。你没有理解细节，就无法真正理解全貌。 一个系统在你眼里是什么样的，完全取决于你对它每一层的理解深度。
细节了解够了之后，你会发现一件事：你 能把复杂的东西，用简单的话讲清楚了。很多人觉得自己表达能力差，讲技术方案讲不明白，写技术文档写不清楚。我的经验是，大多数时候这不是表达能力的问题，而是对那个东西理解得还不够透彻。当你真正把一个技术点的每个环节都搞明白了，脑子里有了清晰的模型，你自然能用通俗的语言讲出来，因为你知道哪些是关键，哪些可以省略，该从哪个角度切入最容易让人理解。讲不清楚，往往是因为自己脑子里也是模糊的。下次如果你发现自己给别人解释某个概念很费劲，不妨先检查一下：是不是自己还有些地方没想透？这个方法也是检验学习效果的好标准。
真正理解了技术，并且能讲清楚之后，你写出来的代码质量也会发生质变。你会开始对代码有 洁癖，对不合理的设计产生直觉上的不舒服。这种洁癖不是强迫症，而是一种工程素养。一段逻辑绕了三层才实现了一个本可以直接做到的事情，你看到会觉得不对劲；一个方法接收了 7 个参数，你会想是不是该重新组织一下数据结构；异常被默默吞掉没有处理，你知道这个地方迟早会在线上出问题。这种感觉不是天生的，是写了足够多的代码、踩过足够多的坑之后慢慢形成的判断力。
工程思维需要在真实的、有足够复杂度的项目里反复锤炼。 你得经历过一个系统从小到大的演进，做过重构的决策，处理过线上事故的定位和修复，才能慢慢建立起对工程实践的判断。如果当前的工作环境缺乏这种机会，那就主动去找。换一个团队，参与一个有挑战性的 开源项目，或者自己动手造一个有一定复杂度的轮子。环境对一个人的成长影响巨大，有时候你需要主动把自己放到一个更具挑战性的位置上去。
关于代码质量，还有一条铁律：发现问题就马上改。坏代码放在那里不处理，只会随着时间不断积累技术债务，到最后变成谁都不想碰、谁也不敢动的“祖传代码”。在最早发现问题的时候动手修复，代价是最小的。
小结
做了这么多年开发，我越来越觉得，技术能力的成长不是线性的。它更像是台阶式的：你在一个平台上积累了足够多的东西，某个时刻突然就上了一个台阶，看问题的角度和解决问题的思路和以前完全不一样了。
这些台阶之间的积累期，有时候挺长，也挺枯燥的。能不能熬过去，靠的就是对这件事有没有真正的兴趣，以及愿不愿意用一种认真、敬畏的态度去对待你每天写的代码。技巧和方法论可以学，但态度得自己选。
选择用什么态度写代码，也就选择了会成为什么样的程序员。
希望这些来自一线的感悟，能给你带来一些启发。如果你有更多关于技术底层逻辑或工程实践的问题，欢迎到 云栈社区 的技术讨论区交流，那里有更多志同道合的开发者一起探索技术的深度与广度。
发表于 2 小时前
|
查看: 2|
回复: 0
