何为烂摊子？
在我们做软件项目的时候，有时会有这样的一件事，尤其是刚跳槽的时候：
我们需要接手一个已经完成7788的项目，这个项目用是可以用，但是问题很多，譬如说，时不时系统崩溃，业务逻辑有各种各样的小问题，甚至是用户体验非常差，代码完全无法直视，想问业务逻辑，却无人能讲的详细，尤其是跟数据结构有关的知识点（原来的程序猿都回大森林了）。好吧，有幸我也接到了如此一个项目，再经过1-2个月的艰辛，总算对这种事情的处理有点眉目了，先讲讲我的经历吧：
一开始，这个WEB项目客户已经在用了，但是还没有验收。客户老抱怨，我打开一个操作频繁的页面，老是需要等上10来秒中， 然后录数据的时候，页面有时候还会假死，有时候又会刷新，完全不能键盘操作，要用鼠标一个一个点。 -------------------用户体验差。
然后，经过公司内部审核，决定将这些页面性能优化，当然也考察了下响应速度慢的原因，于是，需要将这些页面优化。可是问题来了。要优化总要知道原先的业务逻辑吧，望着上千行的方法，望着一堆状态控制，望着密密麻麻的代码，业务逻辑完全和自己想象的不一样。这可如何优化呢。经历了一周的优化，结果效果却很差。为什么呢。自己也仔细想过，主要原因是不太敢动原先的业务逻辑。
再然后，上面也发现了这样也不是办法。决定快刀斩乱麻，索性重写，但要求业务逻辑不变。 这可难倒程序猿了。本来就是业务的详细业务不了解，重写好多也是照搬以前的逻辑。至少交代上去可以说是‘和原来一样！！！’， 但这样又有一个大问题， 重写了还是没理清楚业务。要修改的时候又会出现越改越复杂，可维护性越来越差。
看到这里，可能很多读者都已经发现了烂摊子的根本原因了：1.代码的可维护性极低，而原开发员早已离职（一般这种都是廉价开发员，工作经验很少），
2。 业务逻辑是口传， 设计是根本没有，开发人员想到哪，写到哪。
那我们要如何接手这种项目呢， 经过这么长的时间纠结，也听过类似的经验， 好多都是完全推翻原来，完全重来。正所谓一朝天子一朝臣。原先我还不以为然，现在很真的挺欣赏的。有魄力，能够决定重来并得到允许（当然好多都是从局部开始的）， 重做的过程也是理清业务的一个过程。不要在纠结与原来的逻辑。 发现与原来的不一致，不正是完善业务逻辑的一个过程么。
有朋友如果有更好的想法，可以来说说。