......
Ralin 说:
没有从需求中提炼出来究竟什么是实际需求。对需求一点抽象都没有。做什么通用产品啊。肯定会被这种无穷无尽的所谓需求搞死
icepeak 说:
是啊
Ralin 说:
我的神啊，那些用户要如何理解我们的概念啊。。。
icepeak 说:
我也面临着种问题
Ralin 说:
什么问题？
icepeak 说:
往往是时间很紧，不容我详细的去抽象
我的做法是先实现概念模型中的主要功能，实施的时候再逐步修改
Ralin 说:
你面对的和我们不一样，你可能是做项目，我们是做产品
产品的目的就是通用
不能把部分用户需要的概念强加给全部用户，这不是胡扯吗
icepeak 说:
你这种思想本身值得怀疑
Ralin 说:
怎么说？
icepeak 说:
产品的目的就是通用没错，但是你只说了一半
产品的核心部分是通用，但是面对用户部分是要个性化的
Ralin 说:
个别用户的需求不需要硬编码到数据库，到代码。这是我的看法
icepeak 说:
许多加大型的应用，他们实施的时间和开发的时间差  ，更有甚者，有很多是和使用单位联合开发
Ralin 说:
你所说的是项目。。不是产品
一个产品会面对千万个用户
一个项目的使用者一般是固定的，他的需求是具体的
icepeak 说:
我说的是产品，最典型的是企业应用类的系统
比如，我现在做的供应链管理系统，只能出功能模型，使是的时候50%的数据库结构会被更改或者取消
Ralin 说:
把会改变的东西和固定的东西分开来，这是程序设计的一个基本方法吧
icepeak 说:
很难啊
Ralin 说:
至少你可以把最抽象的东西独立出来。需要具体功能的时候再往这个框架上加东西。
icepeak 说:
打个比方：做客户关系管理软件，客户基本信息表是最基本的数据表
Ralin 说:
把固定的数据库设计独立出来
需要其它信息另建表，这种可以做到吧？
icepeak 说:
但是你的客户却告诉你，他们的erp系统中已经有了完整是客户基本信息表，现在的要求是把你们的系统靠上来
因为涉及同步维护的问题，新的系统中不可能建立客户基本信息表的副本
Ralin 说:
更改一下你获取基本信息的方法？
icepeak 说:
这种情况内核都会变的呀
Ralin 说:
如果你有个接口是用来获取基本信息的，有个基本信息的抽象类（只保存你需要的id）。就能比较灵活应对不同的基本信息
比如用Map来保存信息基本信息，灵活性就非常高
icepeak 说:
呵呵，理想是好的，肯定我们也应该这样努力，但是我觉得做到最后往往利这个目标挺远
写一个BasicInfo这样的类可能只是为了推广的系统能跑起来
Ralin 说:
你要有空去看看Shark的开源工作流，设计得非常灵活
icepeak 说:
那个是很多牛人的结晶啊
Ralin 说:
你可以写一个这样的类，但别写成
BasicInfo{
 String name;
 String phone....
}
用一个map来保存"phone"和05921234567 "name"和王xx 这样就不怕他们基本信息究竟要求些什么了
我是烦最近要改来改去YY的
icepeak 说:
用一个map来保存"phone"和0592...？？？？？？
为什么这么做呢？
Ralin 说:
这样做以后无论你想添加什么属性都无所谓。。。
客户要怎么改他的基本信息，代码都不用变
icepeak 说:
客户要改基本信息结构呢
Ralin 说:
比如说怎么改？
icepeak 说:
比如你设计是name做个key
现在客户的需求是用name+sex做为key
Ralin 说:
我指的是BasicInfo这个类的内部结构不需要因为客户的更改而更改
icepeak 说:
BasicInfo类比如有name等五个成员变量，现在按照需求多出来3个
Ralin 说:
没事...
你完全可以知道数据库里面有几个字段，字段名，值，类型
直接添加到map中就可以了
通过Recordset可以很方便获得表的信息吧？
象这种基本信息表，目的只是保存信息，显示信息。如果这样做可以实现，为什么非要硬编码到代码？每个用户需要变更的时候就要大动代码？
icepeak 说:
嗯
Ralin 说:
我现在就在想能不能在我的程序中这么做。但比较一下还是直接修改代码快。
icepeak 说:
一定程度上的适应性是要的
Ralin 说:
如果当时能够用比较灵活的方法，现在就不需要大改了，而且出错的可能性也会降低
icepeak 说:
这就是系统分析欠考虑的地方
Ralin 说:
我觉得这是具体编码上没考虑好.系统分析上也会存在这种问题。
不能把需求抽象化，肯定会有无穷无尽的需求。
icepeak 说:
是啊，系统分析的时候对需求估计的不足，经验问题