※ 引述《bmzz (bmzz)》之銘言：
: 菜鳥回應，有錯請各位大大指正。
: ※ 引述《hsnucsc (hsnugo)》之銘言：
: 如果現階段不知道以後會不會修改，那就不要花腦筋在這上面了，不
: 然你會發現你設計了一堆用不到的「彈性」。
: 以後修改了怎麼辦？若狗吠聲突然要常常換來換去怎麼辦？
: 這就是你需要「重構(Refactoring)」的時候，而如何重構又是另一
: 個議題了....
: SA需剛剛好，
: 以彈性為例，將80%可以快速過濾以及確認的彈性處理好，剩下20%你
: 煩惱該不該保留彈性的部分，你花了80%的時間去想或許仍舊無法得
: 到答案。在還沒有面對外界複雜又多變的應用之前，你能做的，是在
: 「開發時間」與「程式彈性」之間做一個最佳的平衡。
我也覺得重構是一個好方法。
大部份在寫程式時，並沒有辦法全面性的掌控客戶端的變動需求，所以在
開始的時候先處理確定變動的部份，後面再用重構來調整架構。
花太多時間在處理可能用不到的彈性上，會在開發時間效率會打折扣。
事後的重構，其實花的時間不會很長，因為已經清楚了客戶需求，所以重
構上時間會比當初開發不確定性的部份會來的快。