Skip to content

毕业六年,我对软件开发理解的变化

1416字约5分钟

2025-06-02

前言

六年前,当我通过校招拿到offer,即将进入企业“真刀实枪”地对自己过去几年所学的软件开发技能实践一番时,我也曾幻想过所谓“企业级项目”会是有多么先进和高级。

当时 SpringBoot 刚火不久,SpringCloud 还是非常新鲜而与时俱进的技术,在去公司报道的前一天晚上,我还在担心我没有掌握 SpringCloud 里面的所有概念而担心自己会不会无法胜任工作。然而,这种担心完全是多余的。因为事实完全与我想象的相反,这里不但没有最前沿的技术,还充斥着各种历史债务堆积成的“屎山代码”(有技术上的,也有业务上的)。我看到的,不是什么厉害的黑科技,而是连大学课堂都早已不学的古董玩意儿(是的,这里面竟然还有 JSP 和 Java 6)。

就在我准备提桶跑路的时候,我发现这里的很多项目,虽然技术落后,但却能活过五年甚至十年。我想这里面一定有过人之处,于是我选择了留下来探究一番,没曾想,这一留,就是六年。

六年过去,当然,当年那些老旧的技术框架,都已被我们逐步替换成了更新的技术,但距离业界前沿,也始终审慎地保持着几年的距离。

回顾这六年的工程实践历程,我发现自己对软件开发的理解跟大学刚毕业时有了很大变化。

稳定才是硬道理

企业项目的最终目的帮企业赚钱,并且是稳定持续地赚钱。

多年后,我终于意识到,当初令我震惊的这些维护了十年以上的古董项目真正过人之处不在于技术,而在于从当年随着经济腾飞而一路高歌猛进的业务增长模式当中。只要业务是持续赚钱的,那老板们唯一的希望就是不要在系统上出现差错。稳定才是硬道理。

刚毕业的年轻人经常陷入“唯技术至上”的误区中,常有如 “啊,我要用最前沿最牛逼的技术来重构这堆破烂” 这样比较中二的幻想。然而,重构除了带来风险和意外之外,并无太多收益。当然,我并不是反对重构,而是反对在项目尚且可维护的时候随便乱动。

除非是到了不得不动刀子的时候(比如旧技术无法满足业务、性能、安全等方面的要求时),否则不要轻举妄动。或者是,在增量迭代的过程中,采用抽丝剥茧的方式逐步将老古董替换为新技术,而不是一上来就把汽车引擎替换成飞机发动机。

要不要尝试前沿技术

我个人是鼓励学习和探索前沿技术的,始终保持对技术最纯粹的热爱是我们技术人基本的素养。

确实,前沿技术带来了效率的革新,性能的提升,好处颇多,但是它唯一的问题在于还没有被业界充分地验证,代价是潜在的不稳定因素。例如,应该还没有哪个公司敢在核心业务系统中使用 java 21 的虚拟线程吧,没有人知道使用了之后可能会出现什么问题,所以我不建议在关键业务系统中使用最前沿技术,但是鼓励可以在非关键系统中去尝试,作为技术储备,一旦时机成熟,就可以快速大规模推广,这不KPI就来了嘛。

当然,那些至今不敢在生产系统中使用如 Java 8 的 lambda表达式、函数式编程的“固步自封派”,是要坚决抵制的。

安全第一

许多开源项目的缺点是只管功能实现,而不顾软件的安全性,导致漏洞频出,坑坏了众多使用者。

软件开发,特别是企业软件开发,安全应该放在第一位。防御性编程不仅要防错误输入,边界条件,还要防恶意输入。

我曾经在我任职的部门中担任过一年的“安全责任人”,统筹所有系统的信息安全事项,当时见识过各式各样的软件漏洞,也了解过公司、监管部门甚至是国家级别的信息安全要求。可以说,现在绝大多数的软件开发从业者,对信息安全的意识十分薄弱,在中大型公司还有专门的信息安全团队在支撑着,然而对于一般的企业、个人项目、开源项目,更多时候只能依赖开发者的个人意识了。

所以作为软件开发从业者,平时多了解信息安全知识、熟悉各种常见漏洞和规避方法、研发流程中“左移”安全测试,都是一节又一节的必修课。

不要炫技

除非你正在开发一个对性能要求极高的软件,必须在编程中用各种“奇技淫巧”来提高一丝丝性能,否则我不建议写极致而难以读懂的代码。

业务理解 > 沉迷技术