※ 引述《bmzz (bmzz)》之铭言：
: 菜鸟回应，有错请各位大大指正。
: ※ 引述《hsnucsc (hsnugo)》之铭言：
: 如果现阶段不知道以后会不会修改，那就不要花脑筋在这上面了，不
: 然你会发现你设计了一堆用不到的“弹性”。
: 以后修改了怎么办？若狗吠声突然要常常换来换去怎么办？
: 这就是你需要“重构(Refactoring)”的时候，而如何重构又是另一
: 个议题了....
: SA需刚刚好，
: 以弹性为例，将80%可以快速过滤以及确认的弹性处理好，剩下20%你
: 烦恼该不该保留弹性的部分，你花了80%的时间去想或许仍旧无法得
: 到答案。在还没有面对外界复杂又多变的应用之前，你能做的，是在
: “开发时间”与“程式弹性”之间做一个最佳的平衡。
我也觉得重构是一个好方法。
大部份在写程式时，并没有办法全面性的掌控客户端的变动需求，所以在
开始的时候先处理确定变动的部份，后面再用重构来调整架构。
花太多时间在处理可能用不到的弹性上，会在开发时间效率会打折扣。
事后的重构，其实花的时间不会很长，因为已经清楚了客户需求，所以重
构上时间会比当初开发不确定性的部份会来的快。