首先说一个现状，当你去一家公司就职，很大概率你会发现公司的项目就像是一个垃圾场，各种恶心的代码堆成山。
在那之前，你可能对这个公司的产品充满了各种幻想，如今，幻想破灭。
你要做的事情，就是去维护这些老项目。你一直在疑惑，为什么项目的代码这么烂。各种 if else嵌套，也几乎看不到任何设计模式。随便翻看几个类，就能看到大量的空指针隐患。
终于有一天，有一个新项目下来，老板任命你是负责人，于是你在心中窃喜，终于可以证明自己了。我一定要让代码显得优雅，跟烂代码说再见。
前几天各种顺利，你用了很多设计模式，也知道用抽象类来做业务抽象，方便系统扩展。
你越做越有劲，感觉自己真是个小天才。
由于项目是多人合作的，随着项目的迭代，很多新人开始不按照你的架构来开发代码。
原本应该老老实实继承你设计的抽象类，可是别人为了图方便，毫不犹豫地在controller里面加一个else if，你看完后几乎要炸毛。
赶紧重构！
可是，项目已经运营了，上线了，光是生产数据就有好几十万。
老板问你，你有把握吗？你敢动吗？
你陷入了沉思，最终没敢在项目上大动干戈，然后反手也加了一个else if。
慢慢的，有的新人甚至都不用你设计的通用dao，而是自己在service里面写起了jdbc…
因为需求一直在做，原始的精美设计开始变得越来越臃肿，逻辑变得复杂无比。
没有人敢去重构，也确实不可能重构了。
终于，你接受了这个事实。有一天，你逮住一个在service里面写jdbc的新人，质问他为什么不按照规范来写。
新人一脸无辜，这个项目又没有开发手册，就连个像样的业务文档都没有，我那知道什么代码该写在哪里啊？
也是，这是一个n手的项目，完全精通系统的人已经没有了，老员工一个个地辞职，懂业务的人也几乎没有了。每个新人都无比痛苦，只能靠搜代码来反推业务逻辑，能完成任务已经不错，也就别提代码是不是优雅了。
虽然知道了这个项目的弊病，但是你也懒得去整理项目的开发文档，因为你知道就算整理了，老板也不会给你涨工资，多一事不如少一事。
后来，你也辞职了，准备去下一个公司，继续去面对一个讨人厌的老项目。
