亲身经历

我第一次接手老项目的时候，映入眼帘的就是满屏的黄色提示，以及代码下面的众多黄色波浪线！

内心OS:

  1. 大干一场，把警告全部解决掉！
  2. 这写的什么屎山代码，一点都不优雅，改成我这样！
  3. 连代码都不格式化，还好我配置了自动格式化

干掉黄色波浪线，将代码改优雅之后，结局如下：

  1. 一声不吭动了同事的代码，换来同事怒骂，毕竟人家逻辑写好之后，你又按照你的想法来写，也没有提前商量。
  2. 后续领导找你加需求，你发现原来的代码有妙用，悔不当初，被扣绩效。
  3. 格式化之后，在提交记录上都是你的修改，代码出现问题第一个找你。

现在的看法

代码能跑不要动

前几日我要在老项目中，新增一点小功能，在新增完功能后，我扫了一眼代码，发现有几处逻辑根本不会执行，比如：抛异常后，执行删除操作类似，我也不会去义愤填膺的去干掉这块代码，毕竟我想到一点！项目都跑七八年没出问题了，能跑就别动它。

代码强迫症不要强加于别人

你觉得它写的不优雅，封装少，可能是别人也有别人的难处，至少不能将自己想法强加于别人，比如领导突然来一个需求，跟你说今天你得完成，然后第二天这个需求，你要这样改、再给我加点新需求上去，你能想到的封装其实只是你冷静下来，而且没有近乎疯狂的迭代需求得到的想法，当你每天都要在原代码上面疯狂按照领导要求修改，可能你会有自己的看法。

新增代码，尽量不影响以前逻辑

新增代码的时候，尽量按照以前的规则逻辑来进行，比如某个老项目用的是比较老的技术，但是你就是觉得这玩意不好用，就想换新的。那你可能真的会被领导T出门口

尊重他人代码风格

每个人的代码风格都有所不同，这个很正常，不同厨师的老师教法不一样，做出的味道还不一样呢，没有最好的代码，只有更适合的代码，刚好我就有这样的例子：

如何优化或解决

最好的办法就是大家都统一风格，使用同一套配置。至于逻辑代码，最好还是能不动就不要轻易去动别人写的。

  1. 利用ESLint、Stylelint、Prettier统一配置代码风格
  2. 利用husky和commitlint配置git提交检查，统一Git提交规范
  3. 前端工程化，利用NodeJS开发一个前端规范与代码提交检测工具