20年职业生涯回顾——关于技术成长
2023-12-20 周三 13:00
2025-12-17 15:56
职场 ： 总结 精华
关于技术成长
前言
注意到留了这么一个扣子2年都没补上，已经是2025年冬天了。近几年的精力都集中于搞业务去了，对于做技术这件事情愈发生疏了，估计现在写一下，技术水平是下降得没法看了，不过因为做过业务，所以对于技术的价值与地位，倒是看得更清楚了。
教育
写程序这件事情，是能够自学的，很多软件行业的早期大佬都是自学成才，甚至各种开发语言都是由个人独立创作出来的，这些例子足以说明这个行当的很多基础性工作并没有非常复杂，支撑其运转的基本原理是非常简单，简单到以单人的能力就可以完全掌握的。
基于这个逻辑，似乎学校教学的价值也就没那么大了。
当然这并不是现实情况，现实是能够自学成才，还能大杀四方的技术大佬太过罕见，完全不足以满足社会需求，而且现实产业需要的更多是中低档人才，用来填线。所以学校教育不可或缺，通过学校、机构等教育培训体系，可以批量培养计算机相关专业的劳动力，供应给市场。
当然，学校教育的时间和深度是有限的，几年的课程，也只能是把各种基础性知识讲一遍，能吸收多少，还要看个人的努力与悟性。学校教育提供的，其实就是一套基础的知识框架，知识体系，所谓师傅领进门，修行在个人。未来想往什么方向发展，要么去读研读博，要么自己在喜欢的方向上发力钻研。
计算机科学本身是一门应用学科，偏工程向的，并不是多么高深理论，在已有知识框架的基础上自行深入，可以说是合格从业人员的必修能力。
自学与钻研
计算机软件专业跟其他行当有个比较明显的差别，就是这个行业里面的技术知识都是完全公开的，几乎没有什么知识是独有的隐藏性知识，前辈的代码、各种开源项目摆在那里，想看随时可以看，而且这里面没有什么手感之类只可意会不可言传的成分，相同的代码写出来，就是严格地具有相同的功能与效果，完全不涉及所谓现实世界的物理摩擦力问题。这一点和纯理论性的数学倒是十分相似。
新人初始入门都是从简单项目开始，各种抄demo调包，就能拼凑出一个可运行的项目，现在常见场景的开发流程已经十分成熟，标准的低端码农坑。当然，现实中有不少人实际是卡在这种坑位上的，不上不下，够糊口，也仅只是够糊口。
如果在这种位置上胡乱混着，那也就真的是只能停留在这种低端岗位混半辈子，过了35，加班加不动了，自然也就被淘汰了，可能连糊口都要变得困难了。
要想成长，就得自己去钻研技术，提升自己可以处理的技术问题的深度、广度。
别说都是撸代码的行当，不同细分行业、不同岗位，所涉及的技术范围差异是很大的，但不同技术方向上的自我提升倒是有些共同的逻辑。
一般刚开始的小白读代码都只能是傻读，吭哧吭哧，一天读不了几十行，因为很可能读着读着就发觉自己之前想错了，又要返回去重新看。
比较好的读代码的方式是run起来，然后带着运行数据跟着走，跟着看代码的处理流程与对应的业务逻辑，直到最终的输出结果，很快就能看懂不太复杂的处理流程是怎么做的了。
不过这招对于复杂的算法性质流程不好使，算法里面各种 tricky 的把戏太多了，往往不是简单这么跟着看能轻易理解的。
进阶的方式是在读一块业务之前，先把业务需求搞明白，想想如果自己要做的话会怎么做，在脑子里面把整个实现流程想一遍，可以丢弃一些不重要的细节不管，把关键点都想到想明白，然后带着自己的预想去读代码，直接验证前人的做法和自己的构想是否一致，差异点在哪里，差异的原因是什么，大家是互相有不同的侧重，还是有人想到的是更好的方案。
深入学习各类框架、中间件的实现原理，老老实实阅读相关技术文档，不要只是拿着个使用示例demo就用一辈子，去看看人家设计时都提供了哪些不同的使用方法，不同的实现功能逻辑，为什么要有这些不同的用法，都是适用于什么不同的场景，对于自己的工作，最佳应用模式应该是什么。
更进一步的，一类方向是尝试去理解那些优秀的框架、中间件是如何实现的，通过这一过程，将自己对技术的理解与运用能力提升到可以开发出同等功能、同等性能水平的公共组件的水平上。
另一类方向是将积累的项目经验组合运用起来，抽象不同项目之间的共性，以提升未来工作的工作效率，消解工作中潜在的风险点。
此外，还有往管理方向转型，往业务、销售方向转型的，就不属于纯技术范畴，不在这里讨论了。
人写的代码，难免会有疏漏错误，尤其多线程异步处理的场景上，排查起来更麻烦。优秀的工程师要有死磕的精神，对于一个发生的问题，持续追杀到底，找到核心原因，并加以解决，而不是掩盖问题，找个办法粉饰过去。
代码编写的过程中，出现的错误几乎全部都是开发者自己犯错导致的，所以这个行当也有个比较讨厌的局面，就是出了问题，一定是自己挖的坑，没法甩锅的，含着泪也得自己填。
说是几乎，是因为我在第一份工作中的这个团队，真的踩到过不太可能出现的别人的bug。
技术的价值
计算机学科的核心意义是自动化，高效的自动化。所谓自动化，就是把原本要由人做的事情交给机器去做。要想把人的工作交给机器，就需要想明白要做什么，转化成严格无歧义的抽象逻辑，再以计算机能够理解的方式表达出来，交给计算机硬件去执行。
- 一类技术深度方向是提高硬件性能利用效率，这属于是有技术深度的方向。
- 一类方向是提高开发效率的，例如各种开发语言，各种开发框架，各种中间件或基础性组件。
- 最常见的是业务开发，其中最low的就是CRUD，当然，现在这种体力活越来越多地被AI编程解决掉了，这也属于是提升了工作效率，对应的低端开发岗位也就越来越少了。目前看，印度的IT开发外包行业受此冲击很大。
高效率地完成业务开发工作，以最高的效率，最低的成本实现短期和长期业务需求，这也是一种技术价值，而且是目前最常见的技术价值体现点。当然，拼低成本的方式通常不需要技术，这一点懂的都懂，不细讲了。
由于计算机是一门解决自动化执行这一需求的专业学科，所以意味着那些底层的，所有从业人员都要用到的功能，只要实现出来，就可以长久地使用下去，只要外部硬件环境、业务需求不变，高质量的代码实现就等价于对这一业务场景的最优化方案，大家拿去用就好了，不用再造一遍轮子了。这也就使得底层组件经过一群大佬们的一顿构建，就已经是非常优秀且完备，没啥后续工作可做了，行业中的岗位主要还是集中于各种业务功能开发类工作。相对有技术含量的工作，大体也就是大厂核心业务规模迅速扩张时期做核心系统框架的那些工作，需要解决复杂业务与海量用户的业务压力、性能、稳定性等多方面要求。
至于更广大范围的低端一些的工作岗位，要么是大厂的试验型业务，做出来试个水，大概率会做炮灰。要么是企业IT开发这种技术要求不高，价值性也不高，但是胜在相对稳定一些的工作内容。这类工作有一个明显的共性，就是其中的工程量是非常容易评估的，一个多复杂的功能，对应于多长的周期，多高的成本，是在确定任务计划时就能够准确评估出来的。当然，这种评估是建立在对于具体业务需求的充分理解之上的，不然就变成嘴上说要胯骨轴子，心里想的是前门楼子的问题了。
功能性开发的工程规模可评估，源自于现实业务需求的复杂度是可以被定量分析并描述的。这些现实业务逻辑是不可被修改的，软件功能必须完成现实业务的要求，其软件复杂度也是不可能被削减的。技术在其中的作用主要是保证项目未来的功能、数据量可扩展性、可维护性，压力情况下的运行稳定性之类。如果项目类型都很接近，在基础框架、组件都比较成熟的情况下，通常是没啥技术难度的。所以大部分的从业者使用技术的方式都是在现实业务的复杂性和成本约束的效率要求之间搞平衡。
换个简单点的说法，就是用最低的开发成本把业务实现出来。
3042 字