遗留代码动不得，Bug修不完！25年老程序员：我受够了，选择离职

dsfgdsg

编译 | 苏宓
出品 | CSDN（ID：CSDNnews）在 Reddit 上，一位干了 25 年的老程序员写下了他的离职感言，他直言：“我干了这么多年，但从没见过这种情况，就算是最糟的公司也没这么离谱。通常技术债只是让开发的人头疼，可在这家公司，我眼睁睁看着技术债导致客户大批流失，却无能为力。”
更离谱的是，这里的问题不是代码太老旧，而是公司根本不让动。修了一个 bug，新问题马上又冒出来。客户在受苦，开发者也在受罪。
这篇帖子一发，很快就在 Reddit 上引起热议，许多开发者表示深有同感，也分享了自己遇到的类似“烂摊子”经历。究竟是什么让这家本应高速成长的创业公司陷入混乱？接下来，我们不妨一起看看~

前因
事情发生在一家 VC 支持的初创公司，该公司研发的产品是一款面向工程和技术人员的移动应用。至于具体的应用名称，这名老程序员并未透露，只表示，此款应用在过去增长很快，广告投得也多，销售团队也很能「打」，但在最近几个月，公司却被大量客户流失和业务缩水搞得焦头烂额。
表面上看公司还在扩张，实际增长几乎为零。
这位老程序员坦言，罪魁祸首只有三个字：技术债。

“客户被逼着做 QA”
他解释说，很多技术问题都是不到一年时间里积累起来的巨额技术债造成的。这个应用是为专业人员在现场执行工作时用的，但近来使用它的客户频繁遇到数据丢失、应用崩溃，甚至根本打不开的情况，有些客户干脆转向竞争对手。
糟糕的是，这些 Bug 修不完：修了一个问题，又冒出两个新问题。
这就给客户一种“你们根本没在修啊！”的感觉。
该初创公司现有的研发团队自己也很崩溃，因为这个项目用的是 React Native 技术，依赖一大堆 NPM 包，其中不少早就没人维护，稍微一碰就崩。
为了继续用，有些包不得不自己 fork（复制一份自己维护），还有的因为依赖冲突也被迫 fork。
最近一个让客户出问题的包，其实早在 6 个月前就没人管了，现在直接在客户设备上崩溃。公司里的人完全复现不了这个问题，有人甚至亲自跑到客户现场，用 Macbook 连上他们的 iPhone 调试，还是查不出原因。
这名老程序员表示：“那这个依赖真的有必要吗？其实并不需要，但大家就是不敢删。”
据这位老程序员透露，对依赖相关的根本问题，公司从不去解决，而是头疼医头、脚疼医脚。比如：应用初始化时完全没有日志。这已经多次引发线上事故。原因在于后端要求用一个自定义 logger 接入观测系统，而这个 logger 会“屏蔽”常规日志。
为了解决这个问题，该研发团队只能做出一些临时“补丁”：增加一堆“验证器”去检测应用能否启动。
结果，这又引入了两个新依赖和大约 50 个额外的间接依赖，只是为了掩盖根本问题。但因为本地看不到错误，新 bug 还在不断冒出来。
更糟糕的是，该项目的日志系统本身完全不可靠，要么是一堆没人能读懂的垃圾文本，要么啥都没有。
现有的新研发人员无法从观测、遥测或 bug 追踪工具里看出任何有用信息。但公司内部有话语权的高层出于个人喜好，强行规定“不许动”。
于是，一旦系统出问题，真正负责的人根本不知道，只能靠客户自己报 bug 和崩溃。
与此同时，“开发体验也很差。应用依赖的子包一改就得重建，哪怕只改一行代码，也得等几分钟重新编译，没法调试，更没法热重载。而且这也是公司的硬性规定，不能动”，该老程序员吐槽道。
此外，公司还有很多“表面功夫式”的规定。比如，强制要求所有新的前端组件都要写 Storybook，但 Storybook 已经坏了半年没人修。结果大家只能把东西丢到错误的文件夹里“应付差事”。修的时间没人给，但规矩还是要遵守。
简单来说：客户在忍受 bug，开发在忍受工具。

“这是文化问题，不是 skill issue”

在这名程序员看来，真正的根源不在于研发团队能力不行，而在于企业文化：

• 公司里流行一句话：“这是 skill issue（水平不行）”。开发者之间会公开羞辱。当 CEO 问“为什么应用老是崩”，没人能回答，除非有人跳出来说：“这是因为你们不会写代码”。这已经变成文化了。
  
• 初创团队普遍抱有一种错觉：“初创公司就该写烂代码”。团队的工作模式基本就是两种：要么赶着上线新功能，要么赶着修客户 bug。
  
• 但偏偏负责修问题的团队，正是制造问题的团队。每当 CTO 或其他人想要尝试解决根本原因或改善工具链，内部完全没有动力，最终不了了之。
  

一句话总结：再好的战略，也救不了烂文化。

最后的选择

这名老程序员说，他从这家公司学到的唯一经验是：

• 当新人抱怨“东西太难用”时，应该认真听。
  
• 当有人动不动甩锅“skill issue”时，要毫不客气地让他闭嘴。
  

最终，他决定离开。而他的整个团队，也都在面试新工作。
这篇帖子在 Reddit 上引发了不少共鸣，很多开发者分享了类似的“战场故事”。
有位名为 zapporius 的网友分享道：
我之前最后一份工作的公司，问题出在 CTO 身上。他们在关键程序里设计了一个效率非常低的操作，算法复杂度是 O(n²)，自己完全没意识到，直到我做了简单的性能测试才发现。CTO 对我发现并记录这个问题非常不开心，他和他的亲信一直在掩盖问题、淡化责任，搞得好像没什么大不了的。这彻底打破了他们自认为“很厉害很酷”的幻想。
与此同时，CEO 还在向投资人夸海口，说公司所在的市场潜力有万亿美元，用户有上百万，而实际上他们的产品连六个人都放不进一个会议房间。我甚至提出过，把项目分叉，尝试不同的设计方案和取舍，看看能不能解决问题。
结果公司的人说：“不，我们现在需要你去做一年前向投资人吹嘘的那个‘区块链’功能，投资人现在在追问它在哪里。”
我照做了一阵，然后就彻底离开了这家公司。
还有开发者吐槽称：
我虽然不在创业公司，但也遭遇过类似的文化问题。
公司管理层非常看重某些东西表面上“运行得好”，但根本不关心它是怎么做成的。与此同时，任何指出问题或不良模式的人都会被排斥，好像问题根本不存在，直到有人提出来才被承认。
多年下来，这自然导致了难以解决的技术债务，以及我们依法必须维护的各类仓库分支——无论是自己开发的，还是第三方的。
我真的越来越讨厌那种“先不管，改天再修”的思路。以前留下的各种捷径至今都严重影响了开发效率，而所谓的“改天”几乎从未发生过。没人敢去动那些基础代码。
其实，技术债不可怕，可怕的是公司文化把技术债变成了死局——客户在流失，团队在出走，最后连投资人可能都会后悔。
原文链接：https://www.reddit.com/r/ExperiencedDevs/comments/1moz96e/cautionary_tale_company_is_crumbling_in_part_due/

lovejuan0104

@新闻妹AI 你来讲几句

dsfgdsg

一个bug是bug，一堆bug就能work

52pj

自己也很崩溃

com2

谢谢楼主分享！