W
whsmh320
Unregistered / Unconfirmed
GUEST, unregistred user!
在实际项目开发中,需求时常会有不同的改变;特别是客户不清楚到底自己需要什么样的东西时,就惨了;如何比较合理的构架组织,来适应千变万化的需求呢?
东
东兰梦舞
Unregistered / Unconfirmed
GUEST, unregistred user!
详细的需求分析，合理的编码。
W
whsmh320
Unregistered / Unconfirmed
GUEST, unregistred user!
(我的意思是：在不能清楚准确需求的条件下，如何通过合理的构架来适应变化）
怡
怡.梦
Unregistered / Unconfirmed
GUEST, unregistred user!
打个比方：出门都不知道去哪儿，还出来干什么啊。
W
whsmh320
Unregistered / Unconfirmed
GUEST, unregistred user!
虽然你的比方很确切，但有时实际开发中确实不能做到详细的需求分析，不过你们的话给了
我一些启发，谢了。
我一些启发，谢了。
X
xyzhou7
Unregistered / Unconfirmed
GUEST, unregistred user!
你可以将需求分为：可变的需求和稳定的需求两大类。
再对他们分别进行设计，在设计时尽量使他们互相独立。
再对他们分别进行设计，在设计时尽量使他们互相独立。
B
bluesaga
Unregistered / Unconfirmed
GUEST, unregistred user!
具体问题具体分析，什么都不能确定，就好像一个网状的结构，那你只能把每个节点都独立出来，最后确定以后在把节点互相连上。
7
76liujing
Unregistered / Unconfirmed
GUEST, unregistred user!
需求分析尽量详细，
但是无法再分析了就开始按现有需求分析做，
这个部分跟你以前的情况一样，然后
如果需求改动，你必须保证把你的程序改成，
对于相似的需求，以后再变化时可以很容易的改变；而不是简单的按新需求改！
简单的说就是：第一次客户告诉我需求变动了，我认栽！花力气改
下一次，如果客户告诉我同样类型的需求变动，我还是改，但几乎不花时间
关键是看第一次改动的功底了，这个时候可以用OO，模式，经验等等一切东西来保证。
但是无法再分析了就开始按现有需求分析做，
这个部分跟你以前的情况一样，然后
如果需求改动，你必须保证把你的程序改成，
对于相似的需求，以后再变化时可以很容易的改变；而不是简单的按新需求改！
简单的说就是：第一次客户告诉我需求变动了，我认栽！花力气改
下一次，如果客户告诉我同样类型的需求变动，我还是改，但几乎不花时间
关键是看第一次改动的功底了，这个时候可以用OO，模式，经验等等一切东西来保证。
小
小李飞哥
Unregistered / Unconfirmed
GUEST, unregistred user!
我们的做法是尽量不用硬编码,给以后留一下余地[
]
]
7
76liujing
Unregistered / Unconfirmed
GUEST, unregistred user!
to 小李飞哥:
硬编码只是很小的一个规则，当然对于需求变动来说，效果都是为以后的改动
方便准备的，但是硬编码应该是一个硬性规定，和我说的方式不同，不用等用户改动时
才这样做！
硬编码只是很小的一个规则，当然对于需求变动来说，效果都是为以后的改动
方便准备的，但是硬编码应该是一个硬性规定，和我说的方式不同，不用等用户改动时
才这样做！
