需求与实现的平衡原则

[b]1. 问题的起因:[/b]

a.总想尽可能的形成扩展,留出很好的接口

b.总想在这一次就支持相关的潜在需求

c.总想在同时对现有的代码做出更好的重构


[b]2.(对以上问题的)制衡点:[/b]

a.未知的需求本来就是未知的,所谓的扩展，并不一定会形成真正的扩展

b.时间总是有限的,从容的实现潜在需求几率不大

c.重构总是基于现有的认识以及旧有的所谓经验, 认识和经验的局限会导致很多重构也许是作用不大的


[b]3.关键因素是什么:[/b]

a.台面需求的规模

b. 潜在需求的确定性，以及规模

c. 实现方案的优劣选择

d. 允许的时间长度

e. 对经验的确信程度

f.已有代码的糜烂程度


[b]4. 什么才是好的平衡:[/b]

a. 无论怎样, 首先考虑台面需求的规模,以及时间长度, 其他因素应该根据这两点, 再占据稳定的比例,不宜过长

b. 确定潜在需求是否真的存在(不管采用怎样的方法), 是必须做的工作，无论它的规模有多大

c. 需求有实现与否，实现好坏之分. 与否不容讨论, 完全由用户定义, 好坏则由玩家与实现人员共同决定,在牺牲一点点体验的情况下,如果实现可以做得好(更简单，时间更段),那么这也是一种很好的方案

d. 台面需求的优先级制定需要考虑以上的关键因素; 确定平衡，是实现的前提; 越没有经验,以及越难重构, 就越难确定平衡, 在这一点上, 越难平衡的点,越需要先做，因为它们风险会更高,更有可能影响稳定的代码

e. 如何重构,是一门单独的学问,请看下篇:[重构的艺术]