为什么我不喜欢工作在维护型大型工程上?

sddtc 于 2023-05-28 发布

陈旧的, 停止演进的系统就像一个长满细菌的怪兽一样. 今年才把《白色巨塔 》看完,顿时觉得医疗剧里面的医生和那种为大型旧系统维护的工程师之间或多或少有些共通之处.

太多的第三方需求

理论上一个很多用户使用的系统本是一件令人开心的事情, 越多人使用说明产品越重要, 能帮助更多的人解决很多问题. 但是当需求来临的时刻毫无节奏可言,当实现需求的方式是依赖各个第三方接不停的确认沟通接手动触发 一些脚本的话, 怎么想想都是消耗精力的.

当系统的 dev 和 ops 还依旧是独立的两部分, 相信我, 没有人会开心的. 拥抱 devops 文化的人那可是既懂演进式架构又懂持续集成持续部署的魅力. 然而很久很久以前.. 两个世界的东西沉重又重要, 不论是升级, 安全扫描还是相关集成的重要功能, 哪怕是功能性上线, 都要做好足够的支持, 怎么想想都是消耗体力的.

版本的升级黑洞

也不知道是什么原因, 依赖扫描使用的是传统的工艺, 传统到甚至会使用到一些现代工程师根本想象不到的方式. 更不用说 CI/CD, dependabot 啦.
更不要说身为骨架的东西碰也不能碰, 因为语言的版本也低得可怕.

其实安全依赖的升级倒也还好, 说到底还是扫描的方式太过于陈旧

技术债的“香味”

技术债都是一些奇奇怪怪但是绝对不可爱的债务, 首先需要收集足够的上下文知道 why, what 再到 how. 要知道就算知道 how, 也无法轻易做到呢
就算有了思路, 也要足够的沟通, 讨论, 计划和下一步, 不同的人重复的上下文, 那一刻我的脑袋瓜子真的是嗡嗡的, 已经恍惚到害怕还要重复描述很多遍

其实说到这里, 我突然想到为什么大家都是出来混社会打工的社畜一天天的为啥我就这么的不开心? 因为我一直非常认同敏捷宣言可以改变工程师的世界. 而我遇见的都是右边:

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说,尽管右项有其价值,
我们更重视左项的价值。

其实很多传统企业, 或者企业文化的确是看重右边, 因为那是他们之所以能成长至今的基因, 如果本身就运行良好, 又为什么要改变? 难道就因为我们觉得他好, 人家就觉得好吗? 礼尚往来, 人家也要问句为什么?

跨部门合作或许靠的不是部门 A 花大量时间写出来的 SOP, 因为 SOP 包含的人工执行的脚本或许是另一种恶性循环, 不如定期总结重设彼此的分工, 定期回顾可以改进的工作方式, 给彼此一些时间做技术改进, 给紧急到不行不行的需求来一点点延迟满足, 暂时的等待为的是长远的解放彼此解放双手解放心灵呢

如果系统的功能, 部署, 告警都做的符合基本的原则, 那么根本不需要像大海捞针一样看着字典一样厚的 wiki 文档. 也不知道那些写出来是让谁觉得放心的? 或许是管理层, 或许是领导层, 但一定不是每天都要和这些系统打交道的一线的工程师. 工程师要的是漂亮简洁可测试的代码, 要的是简单清晰的部署方式, 要的是坚固的测试金字塔, 要的是出现问题可以迅速回滚的策略, 绝对不是一个关键词搜出来了十几个文档点开十几个 tab 然后阅读完了觉得懂了又好像没懂, 实际操作起来一个红红的 pipeline 直接给爷整懵了

能写出计划制定计划我承认是一个高级工程师的基本素质, 但是排期, 估点, 制定里程碑那我可要说这是另一个话题了不要混为一谈嗷. 不同的立场思考的东西确实不一样, 但是响应变化也是很重要的一环呢, 对于热情负责的工程师来说, 信任他们要比当工具人产生的化学反应奇妙多了

不过不过, 每个人还是要不断的学习, 毕竟“偷懒”是聪明的工程师会做的事, 如何“偷懒”, 一定不要停止思考涅.