說說咱們在維護一個龐大的系統過程當中遇到的問題以及本身的一點想法。
先從design提及吧。
與design相關的概念根據其涉及的對象主要分爲三類:
- SOLID, 低層次的,單個或者多個類間的,設計原則,
- 設計模式,中層次的,多個類間的,單個模塊或者多個模塊間的,設計模式,
- 架構設計,模塊、系統層次的設計模式。
SOLID 是agile design的一些原則。
agile design不是軟件開發過程當中的某個階段,而是對code持續改進的一種PROCESS。
SOLID 應該發生在coding的各個階段,包括第一次實現,fix bug, 增長feature,以及其餘的一些維護性動做。
TDD是coding的策略,是一個從無到有,從微觀到宏觀的過程;他徹底不是先有了一些預期,或者high level design後的「照章」執行。
TDD而是根據需求寫code,逐個User story, task去實現的一個過程。
這個過程包括功能的劃分,design,類的識別等.
Baby Step是TDD的策略。
因爲人腦的工做記憶容量有限,因此假設一次Baby Step須要考慮n項因素,那麼n 不要超過 m +/- 2, 通常心理學書籍都把 m 設置爲 7 -- 這是一個統計數字。
m +/- 2 中的 2 也是是一個統計數字,具體狀況因人而異,請根據本身的記憶力狀況作調整。
好比記憶力通常,7也許就是那個合適的值,若是記憶力超強,那麼調整爲 m = 9。
每次Baby Step都須要激活不一樣的知識點來做爲refactor的前行的依據。
若是這些知識點很陌生,那麼請設置m = 3。
每Baby Step都要考慮哪些因素呢?
- 好比對一個函數是否保持single responsibility的判斷,
- 若是已經違背了single responsibility,那麼如何拆分才能知足Open for extensibility and close for change?
- 對其它函數的影響是設麼?
- 對test的影響是什麼?等
這裏只是舉個栗子,實際操做時,每步所要考慮的內容都各不相同。
陽春白雪了一番,回到柴米油鹽醬醋茶上來。
當前這個很是大的,很是老的,同時也是一個code質量亟待提升的項目。
在咱們refactor的過程當中常常遇到的一個問題就是被已有的概念束縛,而且以爲那纔是正確方向。
好比咱們有一個類叫HxReader, MxReader, 以致於後續的refactor就老是以爲應該有一個toolReader, 也應該有一個caliReader,等等。
它們就像是魔咒同樣,讓人們沒法逃離舊有的限制而不自知,不能自拔。
造成這樣情況的一個緣由是咱們如今主要是經過從HzReader中分離代碼到其餘小的reader中,而不多真正的re-implement.
而分離的過程基本上就是把更小的reader中用到的方法、變量拿過來就行。--雖然這也符合Baby Step的某些思想。
在這個過程當中缺乏正向開發過程,TDD,中應有的對變量、方法、職責、design的思考。
用上圖來講話,可能就是邁出了一個concern number是50的大步子。
那麼,何來Baby Step的好處與樂趣呢?
《人月神話》中曾說,軟件開發就是開發一遍,扔掉,而後再開發一遍
以致於我一直在想,咱們是否應該從新把其中一些重要的component從新寫一遍。
在此次開發的過程當中,充分的應用agile design中的一些思想,結合實際去充分的實踐。
從而完全遠離魔咒,從小到達,從微觀到宏觀,逐步打造一個嶄新的羅浮宮。