接手爛攤子該如何作。

何爲爛攤子？

在咱們作軟件項目的時候，有時會有這樣的一件事，尤爲是剛跳槽的時候：

咱們須要接手一個已經完成7788的項目，這個項目用是能夠用，可是問題不少，譬如說，時不時系統崩潰，業務邏輯有各類各樣的小問題，甚至是用戶體驗很是差，代碼徹底沒法直視，想問業務邏輯，卻無人能講的詳細，尤爲是跟數據結構有關的知識點（原來的程序猿都回大森林了）。好吧，有幸我也接到了如此一個項目，再通過1-2個月的艱辛，總算對這種事情的處理有點眉目了，先講講個人經歷吧：

一開始，這個WEB項目客戶已經在用了，可是尚未驗收。客戶老抱怨，我打開一個操做頻繁的頁面，總是須要等上10來秒中， 而後錄數據的時候，頁面有時候還會假死，有時候又會刷新，徹底不能鍵盤操做，要用鼠標一個一個點。 -------------------用戶體驗差。

而後，通過公司內部審覈，決定將這些頁面性能優化，固然也考察了下響應速度慢的緣由，因而，須要將這些頁面優化。但是問題來了。要優化總要知道原先的業務邏輯吧，望着上千行的方法，望着一堆狀態控制，望着密密麻麻的代碼，業務邏輯徹底和本身想象的不同。這可如何優化呢。經歷了一週的優化，結果效果卻不好。爲何呢。本身也仔細想過，主要緣由是不太敢動原先的業務邏輯。

 

再而後，上面也發現了這樣也不是辦法。決定快刀斬亂麻，索性重寫，但要求業務邏輯不變。 這可難倒程序猿了。原本就是業務的詳細業務不瞭解，重寫好多也是照搬之前的邏輯。至少交代上去能夠說是‘和原來同樣！！！’， 但這樣又有一個大問題， 重寫了仍是沒理清楚業務。要修改的時候又會出現越改越複雜，可維護性愈來愈差。

 

看到這裏，可能不少讀者都已經發現了爛攤子的根本緣由了：1.代碼的可維護性極低，而原開發員早已離職（通常這種都是廉價開發員，工做經驗不多），

2。 業務邏輯是口傳， 設計是根本沒有，開發人員想到哪，寫到哪。

那咱們要如何接手這種項目呢， 通過這麼長的時間糾結，也聽過相似的經驗， 好多都是徹底推翻原來，徹底重來。正所謂一朝天子一朝臣。原先我還不覺得然，如今很真的挺欣賞的。有魄力，可以決定重來並獲得容許（固然好多都是從局部開始的）， 重作的過程也是理清業務的一個過程。不要在糾結與原來的邏輯。 發現與原來的不一致，不正是完善業務邏輯的一個過程麼。

 

有朋友若是有更好的想法，能夠來講說。