入职后发现项目组代码异常混乱，是去是留？
好多忽悠楼主重写的，让我想起十年前年轻的自己。 这里说点不同意见： 从公司利益角度来说，如果系统已经发布给客户（上线），不要重写。 从个人利益角度来说，可以私下尝试重写来提升自己的能力，但不要试图用来替换已经上线的版本。 理由： 一个刚进公司的新人，对整个系统的了解可以说浅薄之极，你看到的东西、能理解的东西，只是冰山露出水面的那一小角，只是巨大的地下皇陵表面的一层浮土。你只看到了代码混乱这一个问题，但忽视了系统已经解决了的几百几千个其它问题，而一个系统的真正价值却来源于它解决的问题，也就是说，新手容易关注缺点而忽略价值。 这种情况下让新手来重写，可想而知结局一定是灾难性的。事实上就算让精通熟悉这个系统的老手来重写，结果也很可能是灾难性的，因为人的大脑容量有限，今天改动的代码几周之后可能就完全忘光了，更不要说去回忆几年前写过的代码。当时为什么这么写，为了优化做了哪些权衡，这些记忆早都已经烟消云散，重写的时候还要再重新面对一次同样的困难，而这次的解决方案还真就未必比之前的更好。 废话说了这么多，来个国外的老程序员Joel Spolsky在2000年写的文章： （15年前就已经有大牛总结过经验了，可见多读书有多么重要） 他的论点来源于一个简单的事实： It’s harder to read code than to write it. 写代码容易，读代码难。 年轻的程序员似乎还认识不到这一点，但任何一个老程序员都会非常的认同这句话。 还有一个更详尽的带图表的分析： 这篇文章的观点主要是： 1. 重写的代码即便能完全达到旧代码的所有功能、性能需求，为产品带来的竞争力也只有边际提升。（这个很好理解，因为代码的规范性和清晰度对产品的功能性没有直接帮助，只能降低远期的维护成本） 2. 由于重写代码过程中需要花费额外的钱和时间，可能会出现一些意外状况，比如预算不够了，核心程序员离职了，或是重写的产品没有达到原有产品的所有功能和性能需求，那么这个结果可能是灾难性的，重写的产品要么胎死腹中，要么市场竞争力反而更低了。（我马上想到一个例子，迅雷客户端，中间重写多少次都是越写越烂，最后大家都还在用原始的精简版） 当然以上并不是说我们写代码就不用管架构，随便敷衍了事一下算了。这显然也是不对的，具体情况具体分析，需要先看一下我们在公司写代码的目的和目标是什么。 有理想的人往大了说写代码是为了更好的服务人类，但不考虑开源和兴趣爱好之类的话，像我这样喜欢钱的小人往实际了说，写代码的本质目的是为了给公司和自己盈利，所以一切能够提高产出投入比的措施都是可取的，一切降低了产出投入比的措施都是不可取的。 在开发的早期环节，好好设计一下架构显然能够降低未来维护的隐性成本，所以好好设计架构是可取的。 在项目已经上线之后，重写代码在最坏情况下可能导致项目失败，最好情况下也只能获得边际效益提升，却同时要花费高额成本，所以重新设计架构重写代码是不可取的。 嗯你问如果公司的项目或产品代码混乱到无法再加入新功能或提升性能，跟时代严重脱节怎么办，那么应用以上原则，这时候既然这个项目已经快死了，那么放到新项目里重写显然是最合理的选择。