接手烂摊子该如何作。

何为烂摊子？

在咱们作软件项目的时候，有时会有这样的一件事，尤为是刚跳槽的时候：

咱们须要接手一个已经完成7788的项目，这个项目用是能够用，可是问题不少，譬如说，时不时系统崩溃，业务逻辑有各类各样的小问题，甚至是用户体验很是差，代码彻底没法直视，想问业务逻辑，却无人能讲的详细，尤为是跟数据结构有关的知识点（原来的程序猿都回大森林了）。好吧，有幸我也接到了如此一个项目，再通过1-2个月的艰辛，总算对这种事情的处理有点眉目了，先讲讲个人经历吧：

一开始，这个WEB项目客户已经在用了，可是尚未验收。客户老抱怨，我打开一个操做频繁的页面，总是须要等上10来秒中， 而后录数据的时候，页面有时候还会假死，有时候又会刷新，彻底不能键盘操做，要用鼠标一个一个点。 -------------------用户体验差。

而后，通过公司内部审核，决定将这些页面性能优化，固然也考察了下响应速度慢的缘由，因而，须要将这些页面优化。但是问题来了。要优化总要知道原先的业务逻辑吧，望着上千行的方法，望着一堆状态控制，望着密密麻麻的代码，业务逻辑彻底和本身想象的不同。这可如何优化呢。经历了一周的优化，结果效果却不好。为何呢。本身也仔细想过，主要缘由是不太敢动原先的业务逻辑。

 

再而后，上面也发现了这样也不是办法。决定快刀斩乱麻，索性重写，但要求业务逻辑不变。 这可难倒程序猿了。原本就是业务的详细业务不了解，重写好多也是照搬之前的逻辑。至少交代上去能够说是‘和原来同样！！！’， 但这样又有一个大问题， 重写了仍是没理清楚业务。要修改的时候又会出现越改越复杂，可维护性愈来愈差。

 

看到这里，可能不少读者都已经发现了烂摊子的根本缘由了：1.代码的可维护性极低，而原开发员早已离职（通常这种都是廉价开发员，工做经验不多），

2。 业务逻辑是口传， 设计是根本没有，开发人员想到哪，写到哪。

那咱们要如何接手这种项目呢， 通过这么长的时间纠结，也听过相似的经验， 好多都是彻底推翻原来，彻底重来。正所谓一朝天子一朝臣。原先我还不觉得然，如今很真的挺欣赏的。有魄力，可以决定重来并获得容许（固然好多都是从局部开始的）， 重作的过程也是理清业务的一个过程。不要在纠结与原来的逻辑。 发现与原来的不一致，不正是完善业务逻辑的一个过程么。

 

有朋友若是有更好的想法，能够来讲说。