重構之重與敏捷之輕---身份證號重構回顧

尋找重構的案例

重構的案例很差選取,咱們本身實際的項目固然有很多重構的狀況,卻不適合做爲文章闡述出來。並非由於保密的考量,而是業務自己的內容太複雜。固然，這個複雜是相對的,對短短一篇文章來講,那怕是最小一部分的業務邏輯拿出來,也顯容量不夠。並且,過多的闡述業務邏輯,致使喧賓奪主,掩蓋了重構的注意力。因此,要選取一個你們都熟悉的東西,身份證號偏偏中了我第一個要求。

即然是重構,必然要有個原始的版本,並且,要完成了實際的功能。開源中國的代碼分享也恰好爲我提供了一個資源庫。代碼分享這個平臺,真是太理想了,代碼規模不大不小,每個分享又有一個明確的目標功能。
看起來,確實是個金礦。但是隨着深刻的搜索查看,能進入我目標範圍的倒是寥寥無幾。大部分代碼只是粘合劑,把外部庫的調用綜合起來,完成一個任務而已。還有些代碼,方法體太大,而代碼倒是簡單重複,彷佛重構的必要,卻未能展示出重構該有的不一樣側面,並且也有前面所提到的毛病,是粘合劑代碼塊。
（本文版權屬於© 2012 - 2013 予沁安 ）

而當我看到身份證這三個字,才眼睛一亮,看似簡單的身份徵號包括了太多內容:

1. 它是一個典型業務域的Value Object(不要與C#語法概念的Value Object混淆),咱們本身的系統中,恰好也有作一個身份證號值對象的想法。以前咱們已經做一個月份對象(YearMonth),很是好用,可是,由於功能多代碼量大,不適合做短篇。
2. 它沒有對外部庫的依賴。不是說,我只能對這種獨立的代碼重構,而是限於篇幅和重點突出的考慮。
3. 它的業務邏輯很大衆化,誰沒有身份證呢?
4. 分享代碼已經把足夠的業務邏輯包含進起,我所作的就是保持這個不變全力集中在重構上。再完美不過的重構案例了。

敏捷的方式重構和做文

讓子彈飛

定下了目標,當開始作的時候,滿腦子都是想法。原代碼是Java,要改爲C#; getXX能夠用屬性方式,更爲簡捷;既然是Value Object,彷佛用Struct比用Glass更合適;做爲Value,它應該是個不變類(Immutable),所以不該該動態解析,在構造器中解析,更爲恰當; Validation的實現也不太合適……
是的,像我這樣資深的敏捷實踐者,在第一時間仍有這種衝動,太多想法立刻實現的衝動。這實際上是人的一種天性,不要緊,我就讓思惟的子彈先飛一下子。
子彈亂飛以後的寂靜,我想到的第一件事情就是補測試。說到測試,我用MSpec曾屢屢想爲MSpec作個入門介紹,卻一直未能成文，而直接使用MSpec的博文我卻已經寫了很多, 你們就在實際用例中學習Machine.Specification吧。
說是補測試,其實從Java到C#的編澤錯誤修改已經開始了很多改動。測試這一塊是原代碼徹底缺失,補上這個,能夠說是重構的一部分。

迭代一：

準備工做作了很多，到最後,真正測試只寫了一個GetAddress()。而這成爲了個人第一天。第一個測試成爲我第一天的目標,圍繞這個目標,我放棄一切與此無關的工做,特別是以前子彈亂飛的內容。

迭代二：

次日,要作的事情一會兒很是明確,循序漸進的把其它的功能測試一一補全：生日,性別等等。幾乎不太用腦子,有時候,事情就是這樣,有波濤洶涌,有風平浪靜,惟有測試是船舵。
從測試的條數來看,次日進展很快。寫出來的內容也顯豐富。

迭代三：

第三天的進展就順利多了。把各個功能測試一一補全經過，如生日，性別和驗證。其中有個小插曲，驗證邏輯提煉成獨立的類。總結起來沒有什麼好說的，重構自己卻有看頭。

迭代四：

到了第四天，才真正開始作我想要作的事情，整理邏輯，清理代碼。再加上代碼覆蓋工具DotCover的幫助，VS的複雜度分析，從另外一個側面對重構效果加以驗證。其實應該在重構以前也分析一下代碼，兩相比較一下，效果會好不少。

今後，xx和xx過上了幸福的生活......

個人博文算是結束了，但是做爲代碼的改進，其實並無結束，甚至我最開始的想法，有一部分都尚未完成，如struct。我還丟掉了一部分業務，如15位號碼轉換18位。這是做爲重構的展現已經足夠。最重要的是，我已經創立了一個健壯的<測試-實現>對，這個基礎上你能夠繼續完善。

代碼自己的技術含量並很少，但重構的流程，任務細分，小步前進的理念，卻表達的很是充分。做爲體驗，若是你能按照我走過的流程，再踏踏實實走一遍，會有徹底不一樣的感受。敏捷是實踐，重構是實踐，惟有實踐才能體驗實踐。（本文版權屬於© 2012 - 2013 予沁安 | 轉載請註明做者和出處）