作者 | Tina
近日 Hacker News 上有一则帖子热度非常高，其主题是：我接手了一份极其糟糕的代码和一支技术团队，接下来该怎么办？
他给出了一份概述：
该代码每年产生超过 2000 万美元的收入。已经在生产环境中直接开发了 12 年，没有源代码控制 (hello index-new_2021-test-john_v2.php)。从未删除任何代码。只是不停添加东西。可能是因为直接在生产环境中开发的，删除东西风险太大。
在 PHP 上运行，没有 MVC 或任何其它模式。没有模板库。它是 PHP 2003 样式。JS 和 CSS 也是一片混乱。jQuery 的不同版本互相打架，具体取决于你在哪个页面，有时甚至同一个页面也会有。它不使用 composer 或任何依赖管理，都是 require_once。也不使用任何框架。
在许多地方，类似控制器 Controller 的文件，向其自己的 rest API（通过域名，而不是本地主机）发出 curl 请求，进行 oauth 授权等…… 只是为了获取菜单项或产品列表……
路由管理完全是在 Nginx 中重写的（Nginx 配置约为 10,000 行）。数据库结构乱，没有迁移等… 添加列时，由于数据量大，他们一般会建一个新表，然后用 join。没有缓存，但有 memcached ，仅用于 Session 会话……
贴主还表示他的团队目前只有 3 人，还都相当初级。一个后端，一个前端，一个 iOS/android。生产力非常糟糕，变革的阻力巨大。虽然管理层对该项目制定了非常激进的路线图，但实际上总部对这些阻碍因素没有真正的了解。
我们知道代码会随着时间的流逝变得越来越差，而且复杂繁多的应用程序往往牵一发动全身，更改代码存在一定风险，在这种情况下，从头开始重新编写代码看起来是个不错的主意。
他本人也认为这种糟糕的代码，完全重写是必要的，但在 COVID 之后，预算真的很紧张，他不知道该如何平衡，所以在 Hacker News 上将问题抛了出来。
没想到帖子发出一天多，总共得到了 650 多条建议，很多人有过类似经历，所以其中不乏详实具体的回复，但是也存在一些明显的分歧。
建议一：不要考虑重写了，赶紧跑路才是正常的
从头开始重写是一个坏主意，尤其是在业务做得很好的情况下。
如果“此代码每年产生超过 2000 万美元的收入”，那么从商业的角度来看，这里的投资回报率是疯狂的，这份代码简直是一只下金蛋的鸡。
就算它很陈旧，对业务人员而言，也是没有任何问题的…… 因为他们可能认为自己已经建造了一台印钞机，商务人士根本不在乎代码质量，他们在乎价值。如果 2003 风格的 PHP 代码能做到，那就这样吧，忘记重写这回事儿。
从他们的角度来看，源代码控制、依赖管理、框架、Nginx 路由等……相对 2000 万美元来说，并不重要，所以很难说服他们。因此，重写不仅是一项技术挑战，更是一项政治挑战。贴主必须同时解决文化问题和技术问题，该过程的每一步都将是一场艰苦的战斗，即使成功了，也可能不会有人注意到，因为应用程序看起来是一样的。只有在市场份额和收入开始下降时，变革的欲望才会出现，届时可能为时已晚。
“很多人都在给你技术建议，他们很棒，但现实是除非你在执行层面有权力，或者作为他们信赖的高管来推行重大改变，否则就是在浪费时间。作为中层管理人员或开发人员来执行变革是行不通的，而且会付出巨大的个人成本。而且代码拖成这样，是不重视工程文化的表现，遇到这种情况，如果我还是一位年轻人，可能会留下来并试图成为无名英雄，但现在我年纪大了，我对这种愚蠢行为嗤之以鼻。”作为一名资深开发，swat535 给出了他的建议。
不少人对此表示赞成，认为改变环境是困难的，建议再找一份新工作，“如果高层给出的答案含糊不清，或者有什么东西闻起来不对劲，就应该马上跑路。”
“他们从 3 个廉价开发者那里获得了 2000 万美元的收入，据公司称，目前进展还顺利，那么他们不会吸取到什么教训。一旦事情搞砸了，负责人肯定会受到指责。我的选择是退出，因为我也曾处于类似的情况。”另一位有同样遭遇的人说道。
建议二：不要完全重写
也有人认为贴主在假设自己对原始团队和技术非常了解，但事实上新加入的开发人员通常并不知道应用程序为什么会演变成这个样子。
“如果不知道为什么，那么就算从头重写，也有可能导致新系统比旧系统更糟糕……”lumost 举例说，“我曾在一家广告技术初创公司工作，当收入达到约 1 亿的时候，公司更换了技术团队。新的技术团队震惊于奇怪的旧技术，于是将代码库重写为 ruby 微服务。为了加速重写 / 架构迁移，该团队甚至阻止在旧程序上进行投入。不可避免地，生产力直线下降，公司的收入开始下滑。该公司最终对该技术团队再次进行了深度整顿，这个过程实际上花费了他们整个 D 轮融资以及 3 年的产品开发时间。”
也就是说不了解整个情况的话，一旦重写失败，沉没成本会相当昂贵。所以，一些网友认为，在有每年 2000 万的收入的条件下，进行完全重写是不应该被考虑的事情。但是贴主可以使用一些严肃的技能，做一些风险系数小的改变：
比如 Fork 分支，小增量的推出更多的功能。如果该领域存在竞争对手，此举能给自己带来市场上的优势。
在尝试做出重大转变之前，可以引入一堆新的实践和模式，进行一些必要的更改。比如不改变代码结构的条件下，利用 git 对代码库，以及每个成员团队的职责进行更高效和更多的控制；对新加代码增加注释；建立分支进行测试；建立 CI/CD 自托管工具；在有测试和 CI/CD 的条件下，测试数据库迁移……
可以试图解决一些性能和用户体验上的问题，比如利用现代框架重写前端，让管理层和客户兴奋之后，再逐步重构后端（此时，更多的测试覆盖率可能会派上用场）。
建议三：如果不能完全重写，那还是赶紧跳槽吧
典型的建议是永远不要重写，但也许重写会让问题变得更简单。
维护古老的方法和技术对初级开发人员来说是职业生涯倒退，而且如果这份代码是一个企业的收入引擎，那么需要采取保守但果断的行动，否则有可能让当前的情况变得更糟。“只要业务继续运作，总会有最重要的事情进来。当添加越来越多的代码时，痛苦只会不断增加。”
另一位程序员也分享了自己的经历，“我在一个稍微小一点的团队中遇到了几乎完全相同的情况，并且也是值 500 万美元的 PHP 应用。我们对 Django 进行了完整的重写，花了 2 年时间，经历过难以言喻的政治痛苦，但绝对是正确的选择。遗留代码无法保存，团队中的每个人都同意这一点——这意味着我们没有内部斗争。为了获得支持，我们从非常小的项目开始，将其作为我们一些工程师的‘20% 项目’。在级别设置 auth、CI/CD 和基础设施的东西之后，我们从一个常用的功能开始，将旧的 PHP 页面重定向到新的基于 python 的页面，逐渐用新程序替换掉了旧功能。”
“最终，我们有足够的证据表明替换是好的（响应能力大幅提升，升级 UI 对用户十分友好等），我们有幸使这个项目成为一个更大的项目，并极大地降低了成本和复杂性，能够以敏捷的方式为业务提供真正有影响力的东西。随着项目的成功，我们得到了高层领导的体面支持。”
“但是，不是所有领导都愿意为此花费大量的政治资本，而且还需要自己团队 100% 的支持和参与。如果达不到这样的条件，你应该辞职，去一个更舒服的地方。简而言之，如果领导层不了解他们处于不可持续的境地，并且不愿意投入时间和金钱来修复它，那么重写或重构的可能性为零。”