阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 juejin.cn/post/7073001183123603470 「沧海月明FE」欢迎转载，保留摘要，谢谢！

• 思考：做需求与做需求的差异
• 业务需求该怎么做
• 再说「技术深度」
• 获取做有深度事情的授权
• 技术深度不是唯一标准
• 最后

---

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

看到一个讨论帖，原文如下：

平时的工作如何体现一个人的技术深度？平时工作中很多时候需求细而碎的，如何在工作中积累技术深度？又如何体现一个人的技术深度？

思考：做需求与做需求的差异

再回答问题之前，我想先抛开「技术深度」这次词，讲讲做需求这件事，说说我对做需求的理解。每一个程序员都是从刚毕业做需求开始，为什么有的人逐渐成为大牛，主导大型技术项目或走向团队管理岗位，而有的人一直还在做需求。我觉得这里面的差异在于：每一个对做需求这件事的理解有所不同。

这里面的差异在于，你是抱着一种什么样的心态去完成这个需求，是把这个需求做到极致，还是只是当做任务完成这个需求，达到产品想要的功能就行。这两个表面上看似差不多其实相差极大，差异在于，你有没有站在更高的角度，希望这件事做到完美。

从需求角度有没有思考产品设计当中的缺陷，能不能反向为产品设计提供建议，从技术角度能不能做到高质量高兼容性无bug，以及下次再有类似的需求能不能快速高效率的迭代。

用一句话来描述就是，能不能跳出自己是一个程序员是一个被动执行人的角色，而是将自己当做产品当做技术负责人的心态去做这件事。

业务需求该怎么做

知易行难。如果一开始做不到，那就先着眼小事：关注细节，从需求开始的需求评审、编写技术方案文档、设计文档、到开发的代码注释、结构设计，保证高质量，完善无漏洞的代码逻辑，再到异常埋点、指标监控、线上可用性运维等等，认真对待一个需求的每一个环节。

当你自认为已经做好整个流程的每一件小事之后，接下来可以通过深入细节，思考整个流程是否存在问题。做需求过程中沟通协作的有没有问题，流程规范的有没有问题，机制环节哪方面问题，代码公共基础能力的是否有缺失，开发过程中你所遇到的问题是不是一个通用问题，能不能抽象出一个公共库解决大家的问题，能不能制定一个SOP的解决方案流程，亦或是提炼出一个最佳实践在组内外分享经验。

通过这些一件件小事来锻炼自己解决问题的能力，以及更深层级的发现问题的能力。再通过不断的发现问题，思考问题出现的原因，拿出解决方案，最终落地解决了自己或组内或协作方的问题，锻炼自己的综合能力逐步慢慢成长。

再说「技术深度」

说了这么多，你可能会说，这跟我问的技术深度有什么关系？我想说：抛开业务需求谈技术深度都是耍流氓。

举一个例子，数据可视化方面3D three.js，视频直播方面的编解码压缩，客户端安全方面的攻防渗透，每一个都是有技术深度的事情，但问题是即使你掌握了这些领域拥有了非常高的技术深度之后呢，不能应用于业务需求，不能解决产品急迫要解决的问题，不能完成你老板的OKR，达成部门的战略目标，还是英雄无用武之地（当然你也可以选择一个可以用得上的团队，那是就是另外一回事了）。

由于这些单点的有技术深度的事情，不能为你带来直观和显而易见的 「回报」（也就是颜如玉、黄金屋与金榜题名），也就间接的打击了积极性（当然自己对某门技术感兴趣而钻研的不再本次讨论之列）。

所以提升自己的技术深度，最好的方式还是在公司业务中，发现有深度的事，然后去在攻克这个问题的过程中，提升了自己的技术深度，即跟随公司业务的发展的同时自身也获得了成长，你用技术能力为公司解决了业务发展过程中的问题，自然也就从公司获得了该有的回报。这是一个ROI投入产出比最高的获得技术深度的方式。

获取做有深度事情的授权

当想明白获取技术深度的路径之后，接下来要解决的就是：如何让领导给你安排有技术深度的事情？

业务发展中有很多有技术深度有技术难度的事情，为什么领导要安排你来做这件事呢？你凭什么让领导觉得你 「有能力」 也 「有意愿」 来完成这件事？能力与意愿是作为领导在分配工作当中的最重要的两个决策项。

既然你能提问如何积累技术深度，我相信你一定是有强烈意愿的，那么剩下的就是如何让领导认为你有完成这个有技术深度的事情的能力？最简单来讲就是，你能不能在开发需求中做到深度思考、追求极致、精益求精、有责任心、有主人翁意识与主R意识，在每件小事中能做到 「自闭环」，之后才会逐步让你承担更大范围更高挑战更大深度的事情，形成正向循环。

这也是我前面为什么要先重点强调做好每一件小事的重要性。

技术深度不是唯一标准

作为一个程序员，在职业生涯的初期，确实是以技术深度也就是技术能力作为最大的衡量标准。

但随着职业生涯的发展，职级从L5到L8，站在从公司角度，对一个人的需求，也会从能完成一个业务需求，变成能带领一帮人完成一个更大的维度的需求，能不能为组织解决问题，为事业部达成战略目标，对人的要求的重心也会慢慢发生变化，这种变化可以参考公司的职级能力模型体系的雷达图。

所以一味的追求积累技术深度就跑偏了，但不是说技术深度不重要，技术能力是作为程序员的安身立命之本，但是在积累技术深度的同时，也需要学习锻炼技术深度以外的能力。具体到底是什么其他能力，这就够再展开好几篇文章的篇幅了，今天在这就不细说了。

最后

故不积跬步无以至千里，不积小流无以成江海。先从做好每一件小事开始，把每个业务需求做到120分，深度思考、发现问题、解决问题，逐步建立起靠谱、有责任心、技术牛的人设，逐步负责有技术难度的事情，跟随公司业务发展积累自己的业务领域经验与技术深度，从而获得双赢的回报。

这是我对如何积累技术深度这件事的理解，或许会有一些片面和偏激，毕竟不是谁都有一个能知人善任的好领导，不是谁都能遇到一个快速发展的业务，不是谁都能遇到有技术难度与技术挑战的场景，无论我怎么说，都会有幸存者偏差的存在。

努力与机遇并存，机遇可遇不可求，所以我们能做的事，就是学会正确做事的思路和方法，并为之坚持不懈的践行它。知易行难，学会方法容易，坚持践行难于上青天。自己该做的都做好了，机遇来了就可以抓住，即使抓不住，你也有了「选择的能力」，有了选择更好机遇、更好公司的能力。