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

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.115.87.185