程序員的九大重構天梯

“java程序員”
開發一個項目系統和后續維護一個系統，這兩種需求對于程序員的能力要求是完全不同的。

全新開發項目對程序員的基礎要求是符合需求、符合技術規范。

而維護一個長期的系統，內部的代碼往往是不完整，紛繁雜亂的，很多時候程序員往往需要從這些代碼中理解程序的結構，理解其邏輯關系，然后才可以修改更新。

因此我們可以按照程序員重構代碼的能力劃分成九個層次。本文就講講代碼重構九重天。

一、看不懂代碼，按照需求重寫

如果需求和程序實現不一致的話，那么就只符合需求了。

這雖然是重構最低的一級，但是放在程序員開發中，也是中等的程序員了，因為很多程序員按照需求文檔都不能正確實現需求。

二、能對照需求理解代碼，按照理解后的需求重寫

和第一層類似，不過在對照需求理解代碼的同時，能挖掘出很多需求文檔中沒有寫，但是代碼中已經實現了的需求。

這時候有了一定的領悟理解能力了。

三、能對照需求梳理代碼，按照梳理后的需求重寫

理解和梳理不同，理解是看到一塊代碼理解一塊代碼，而梳理則是在理解的基礎上，還可以抽象出已經實現的代碼的結構，盡管這種抽象是體現在代碼中，但是并沒有明確的寫出來，而且散亂在很多地方，需要程序員匯集整理。

這就是在領悟了各種代碼之后，能自己把獨立的抽象概念匯聚融合在一起了。

前面三個層次，都是重寫，也就是需要重新完成原有的工作，需要投入相當一樣的工作量。

四、當原有代碼有一定質量的時候，能看懂代碼結構，可以遵照原有代碼結構進行小范圍增加

這里面的要求是原有代碼有一定質量，如果原有代碼質量差，那么還是重寫吧。

第四層還有一個意義，也就是這個級別的程序員，工作可以不斷的累積，同時不會降低代碼質量。

五、當原有代碼有一定質量的時候，能看懂代碼結構和所涉及的代碼，可以遵照原有代碼結構進行小范圍修改

增加和修改不同，增加是追加邏輯，不影響原有邏輯，而修改可能影響原有邏輯，特別是原有邏輯之間存在隱含的依賴關系的時候。

修改的前提也是原有代碼有一定質量，而且代碼的修改也是要一直不低于這個級別的程序員，這樣工作才能累計，而且不會降低代碼質量。

六、當原有代碼有一定質量的時候，能看懂代碼結構，可以遵照原有代碼結構修改代碼結構

修改代碼結構可能很多人覺得這種情況很少見，事實上最常見的就是升級框架，升級第三方庫等各種基礎代碼。

在實際項目中往往被忽視，甚至有的企業會安排新手做這件事，因為覺得沒有實現什么新需求，不創造價值。

對于成熟的框架、第三方庫來說，因為已經有大量的升級實踐發現了各種缺陷，不過對于不成熟的框架和第三方庫來說，特別是企業內部專屬的框架和庫，升級后不兼容甚至原有邏輯混亂的情況就很常見了。這時候不可能全部項目重寫，就需要有這個能力的程序員在升級結構的同時保證程序質量。

和前面兩層同樣，類似的工作需要有相同能力的程序員才能保證代碼質量，有些公司經常是讓新手重構，然后搞砸了讓熟手打補丁。

七、當原有結構清晰健壯的時候，能擴展原有結構

這種情況主要出現在集成的時候，幾個程序的結構都清晰健壯，但也需要有人把兩者集成在一起，當然，到了這個層次的程序員的重構工作就不再是具體需求了，而是擴展結構后讓其他程序員按照擴展后的結構繼續開發了。

八、當原有結構清晰健壯的時候，能調整原有結構

這種情況主要出現在基礎架構調整，同時不想重寫業務代碼，就需要在中間的結構層面進行調整，例如單機部署變成集群部署，就需要調整結構，使得調整過程對業務代碼透明。當然，這不意味著是最優的，后續還需要對業務代碼按照新的結構調優。

九、當原有結構清晰健壯到時候，能重構原有結構

這種大神級的世界我是不懂的

但是

不能否認有這種超乎想像的程序員存在。