我贊同小麟的說法，最有彈性的作法並不一定是最好的作法，開發時程是很重要的考量，我提到這個建議，並不是說要把現在所有的class的成員變數改為private，而是建議，今後撰寫任何的class，其成員變數最好都宣告成private，甚至繼承一個沒有被其他類別繼承的類別，亦建議把原類別所有的成員變數改為private，再繼承，除了享有封裝的好處，也可以避免copy/paste的後遺症，改寫繼承的變數可以半強迫讓編寫者再仔細看一次抄過來的code，了解所有copy過來的code是不是真的都需要。實際上重點是，這並沒有花太多的時間，以我的經驗，500行的程式碼超過10個成員變數，利用輔助程式替換，含測試不會超過30分鐘。這還是半熟練運用工具的狀態下，相信熟練的話會更快。花一點小時間，為自己留一點後路不是很好嗎。
但是我覺得程式的彈性真的很重要，一個程式的壽命與成長性取決於程式的彈性，因此我建議在開發時，第一輪先把程式完成，完成後先做簡單的重構，更名、萃取函式、封裝變數這種不浪費時間的小工作（善用工具的話，這真的是小工作）。在單元測試完後或α中後期，探討相關可能變動，對相關的架構做適當的調整。這段時間做大步重構，有三個原因，
- 第一、這時期功能已經開發完成，測試也進入中後期，經由多番測試大約了解變動的因子，再進行code review，知道程式何處無法因應將來可能的變化，也可避免所謂的過度設計。
- 第二、這時也對相關功能，可能需做的測試案例，已經相當的完備了，利用完整的測試案例，重構的品質更有保證。
- 第三、這是我認為進行重構最好的時刻，開發者這段時間對程式最熟練，經過一個專案週期後，會幾乎忘記上次為啥寫這樣的程式碼，將來要變動程式時，所花費的成本將逐漸遞增。開發者熟練重構的話，可以完全不改變功能，將架構改的更好。且此時進行重構已經不影響時程。
當然這些假設都是，開發時間來得及，解bug夠快以不影響時程來規劃。所以第二階段重構其實也是非必要做的，只是有做會比較好，但是我建議簡單的重構一定要做，我覺得一個容易理解的程式碼比完整的文件更重要，尤其當你面對一個函式，竟然要拉動三頁才能看完，或者一個神秘的判斷式，完全不能了解他在判斷什麼時，就更能體會了。
ps.蘇哥用他的防毒軟體測我新抓的蕃茄有毒，可是我已經用五種以上的防毒軟體測過了，都沒掃到，norton最新的病毒定義碼也裝了，就是沒毒啊！真是奇怪？可能我的電腦天生對此病毒免疫，所以新版蕃茄還是不要散發出去好了，還是有勇者願意嘗試。
我真的是瘋了，又打那麼多。
留言