【译】宁直接改代码，不写绕过方案
正文
我已经数不清有多少次听到程序员说要新写一些代码，去兼容、绕过其它一些他们不愿改动的代码行为（shit上雕花）。你要明白你是一个有权限修改代码的程序员！这其实是你的工作职责！只是把代码改成你想要的样子就可以了！不论修复 Bug，改变代码行为，还是新增功能特性！
- 打印出来的日志信息既干扰又没有用？那就删除对应的日志代码！
- API 没有向外暴露你需要的东西？那就添加一个新参数去支持！
- 你项目软件里的依赖库存在一些危险可怕的行为？那就阻止掉危险可怕的行为，并解除项目软件对它的依赖。
- 开源软件正在做一些不好的事情？那就在本地打好补丁，并把补丁同步推送上去。
我所要讲的是：你知道如何去解决你的问题，但是你选择绕过，从一些附加的代码层面上去实现这个解决方案，而不是直接修改原来就有问题的代码。正如以前常常说的，代码是一种责任；项目的代码越多，项目的情况就越复杂糟糕（你见过鲸鱼的shit吗）。所以，只要直接改原来有问题的代码就可以了！
这有一些可以用来作为你不能去直接改代码的技术说辞。例如：
- 我没有权限去碰这段代码
- 我不知道怎么去修改这段代码
- 我不知道源码在哪里
- 我不会构建这个项目软件
- 我不会执行测试
- 我没有办法使用这个软件的修改版本
在有些人的工作中，认为这些说辞是有效的，他们可能觉得这难以置信，但是在非常多的工作环境中，这些说辞并不适用。尝试着从前者转换到后者：不要使用这些有遗留问题的软件，让软件开源而不是闭源，辞去你的工作转而从事有好开发工具的工作。
这还有一些社交/制度方面的说辞。例如：
- 直接改代码意味着我们必须与维护这些代码的负责人沟通，那又怎样？他们可能会很高兴你正在看他们的代码，并有心改善它！如果他们不乐意你这么做，那么你正想要做的事情不管怎样都是邪恶的，你应该感谢他们阻止你。如果你所做的是有利的，但是他们仍然不乐意，那就
fork，日后再upstream。 - 直接改代码会影响到其他用户！如果你想要做的事情对他们有帮助，那他们将会很高兴，你应该接受和他们沟通协调的成本和好处。如果你想做的事情对他们有伤害性，那说明你不应该去做。如果你还是选择这样做，你肯定可以想出一个办法，让他们不必使用你修改的版本。
- 我们还没有评估出时间来用正确的方法做这件事!那么你就永远不会有预算时间来做正确的事情。现在就按正确的方式去做，否则你将一直受苦。
- 这应该支持快速验证环境。你完全可以通过直接改原来的代码做一个快速实验环境；其实这么去做应该更快捷。
不要害怕！直接改代码就可以了！
原文之外，一些想说的
手上有一个50w行代码左右的前端项目，项目已经跑了四五年以上的时间，以前全是用jquery写的，现阶段是jq+vue2混用。你见过鲸鱼的shit吗？我手上这个就是，这个项目历史债务太重，十分烫手，丢给谁，谁都摊手不愿接手。维护老项目是非常吃力不讨好的：
- 维护历史代码的人已经换了好几波，没有人能梳理清楚老代码的业务运行逻辑，到了重构不动的程度，只能重写了
- 改动风险很大，改漏、改动引发频繁，经常被人投诉
- 项目成员（包括新人）都喜欢复制/引用老代码到新代码里，review代码时常看到又烂又过时的代码
- 老代码维护久了，让人感到麻木，失去冲劲
我觉得老项目引入新技术，老模块不变，新模块采用新写法这种方案，从某些方面上来看，也属于绕过方案：
- 非常多的老模块是
jquery写的，一部分是用vue2 + options api写的，去年初又引入了vue-property-decorator，使用ts写新代码，各种写法混用，维护成本++，将来是不是也要把composition-api引进来呢？ - 新老技术混用，复杂程度++，新人的上手成本极高，容易劝退新人
- 不同写法的混用，考验成员的思维切换能力，你永远阻止不了有人在
ts里写着anyscript，他说是从老代码copy过来的，老代码是用js写的 - 新老技术并存，我们期望着在将来可以把老技术移除，只留下新技术。但是总有人喜欢在新模块里引用老模块，copy老代码到新代码，而且，老代码的维护使用的依然是老技术老架构，老代码的维护成本只有增加，不会减少，长此以往，只会形成新老技术并存的局面，没有办法把老技术移除。
我觉得不管是什么项目，只要它赚钱，都要制定阶段性持续性的重构计划：每隔一段时间重构一部分代码，不用担忧没有时机，项目里总会有窗口期让你有机会进行重构，想要项目长久，重构计划就要坚持下去。提倡直接改代码，而不是容忍老代码，选择兼容绕过。兼容绕过只会让项目越做越糟糕，历史负担越来越重，到最后难受。最后的最后，祝大家虎年大吉，愿天下没有shit山代码！
