近日 Hacker News上有一则帖子热度非常高，其主题是：我接手了一份极其糟糕的代码和一支技能团队，接下来该怎么办？
他给出了一份概述：
该代码每年产生超过 2000 万美元的收入。已经在生产环境中直接开拓了 12 年，没有源代码掌握 (hello index-new_2021-test-john_v2.php)。从未删除任何代码。只是一直添加东西。可能是由于直接在生产环境中开拓的，删除东西风险太大。
在 PHP 上运行，没有 MVC 或任何其它模式。没有模板库。它是 PHP 2003 风格。JS 和 CSS 是一样的。多个版本的 jQuery 会根据您所在的页面或什至在同一页面上相互竞争。它不该用 composer 或任何依赖管理，都是 require_once。也不该用任何框架。
在许多地方，掌握器（如文件向其自己的 rest API（通过域名，而不是本地主机）发出 curl 要求）进行 oauth 授权等......只是为了获取菜单项或产品列表......
路由仅作为 Nginx 中的重写进行管理（Nginx 配置约为 10,000 行）。数据库构造乱，没有迁移等...添加列时，由于数据量大，他们添加了一个带有连接的新表。没有缓存，但有 memcached ，仅用于会话......
题主还表示他的团队目前只有 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% 的支持和参与。如果达不到这样的条件，你该当辞职，去一个更舒畅的地方。简而言之，如果领导层不理解他们处于不可持续的田地，并且不愿意投入韶光和金钱来修复它，那么重写或重构的可能性为零。”
参考链接：
https://news.ycombinator.com/item?id=32883596
