看那看不到的東西，聽那聽不到的聲音，知那不知道的事物，才是真理。
－ 達摩
繼數學女孩系列(*1)後，結城浩的第三本書(其實應該是第四本)終於入手：Java 重構。這本書除了翻譯有些怪怪的、程式碼部分的單字大小寫有些有問題；其餘都還不錯，範例淺顯易懂，而且重要的一些重構手法都有提到。
最近時間比較多一些，於是開始K這本書，看了大約一半，突然有了一些心得。書中常常重複的提及：
1. 重構，在不改變外部可見的程式行為的前提下，將程式內部的結構進行改善。
2. 重構一定要Step by step。
3. 重構過程中，需讓現存及新的方法同時並存，再用新的取代現存的。
4. 重構每一步都要經過仔細的測試(一般會撰寫單元測試搭配重構)。
這樣的定義，讓我想到前幾個月我在修改負責的AP時所做過的事。由於leader的一些疑問，因此要求我將使用SharedPreference(*2)儲存的機制，修改成使用Database來儲存。
這個問題困擾我很久，因為SharedPreference幾乎跟整個AP交纏在一起，我想這就是鮑伯大叔提到的僵化性(Rigidity)(*3)，也就是牽一髮而動全身，修改一部分全部的地方就要跟著改。
過了幾天，我還是想不出一個簡單可以修改的方法，於是突然想到：不動手，想太多都是沒有用的。於是我開始動手改，果然隨便改一下就編譯不過了，過了幾個小時，整個code終於被我改爛了，YA！然後我又默默的從Codebase中下載一份全新、未改爛的程式碼。
有了上次的經驗，經我反思後，想到了一個方法：就是讓現存的方法和新的方法同時並存，然後再去比較使用新方法獲得的值是否跟現存方法的一樣，如果不一樣就表示新方法有bug。於是我依循著這個原則，開始了我的修改程式大作戰。
一開始因為怕改爛，所以一次改一小小的部分，然後測試了一下好像OK耶，於是就繼續改下去。慢慢的愈改愈有自信，就想說一次改多一點吧！結果，又被我改爛了，害我花了點時間Rollback到沒改爛的進度。這讓我學到，真的還是要一步一步的修改，確認無問題再繼續往下走。
終於，兩種儲存的方法終於並存且可以獲得相同的值。接著，我慢慢的將判斷式中有使用到值，從由SharedPreference獲得的方法改成由Database獲得的方法，改好一小部分就測試一下。慢慢的改慢慢的測，終於SharedPreference已經不被原來的程式所使用到。於是我就忿忿然將所以存取SharedPreference的方法砍掉，真的是超爽的。
回到開頭提到的Java重構原則，恰恰都跟我在修改程式的過程中所體會到的不謀而合。
1. 在替換Database的儲存方法後，使用者使用的功能要跟原來的一樣。
2. 讓SharedPreference和Database的儲存方法並存，再慢慢的替換它們。
3. 急躁的修改易造成失敗。
4. 不斷的測試這兩種方法獲得的資料是否相同。
經過書籍的閱讀及這次的經驗，我覺得重構只是一種系統化的流程，只要根據這個流程並小心的修改，應該都不太容易失敗；反而是為什麼要重構，重構前後對開發者或現存程式碼有什麼影響才是最重要的。如果只為了重構而重構，只會讓程式變得更加複雜與難以維護；適當的考慮每個環節，評估現有程式的結構性，找出重構與不重構的平衡點，我想才是重構真正的原意吧！
莫名其妙寫了一堆，其實自己也不是很懂，果然資管的就是愛嘴砲。
註：
*1. 結城浩所編寫的關於數學的高校愛情小說。
*2. SharedPreference是android提供的一種儲存機制，可以將資料存成xml的格式，並寫入到磁碟中。
*3. 僵化性：系統難以修改，因為每一個修改都會迫使系統其他部分也要變動 (出自：敏捷軟體開發 - 原則、樣式及實務一書) 。
沒有留言:
張貼留言