请教业务功能扩展带来的软件修改维护问题.

[dd_zhouqian]

请教个问题，项目已经发布了，客户在使用一段时间(1年)后，需要在原基础上进行业务功能的扩展(这里数据库的业务表中需要增加表字段)，
并且客户亦需要保留历史业务数据的查询与统计，基于业务功能的扩展，我现在的项目需要修改数据库访问模块中的代码、界面显示模块中的代码、数据查询模块中的代码、数据统计模块中的代码等。
这样代码修改量好大，有没有好的设计方法？
各位一般如何处理这样的业务功能修改?
是否用框架设计的软件在进行该类型功能扩展修改时会很容易？

[dd_zhouqian]

自己先冒个泡

[advance_coder]

单独开发一个历史数据查询系统。 当前系统继续维护开发。 需要考虑新数据跟历史数据是否需要一起统计。 你这种多半是项目开启之前跟客户没对接好，所以要常与用户沟通，先把需求设计尽量做足做好。 没其他的好办法，大家对你具体业务也不了解。

[HerryDong]

数据库表要增加字段，那么界面显示肯定要改了（比如多个按钮、文本框），界面显示的修改肯定也得牵连到后台代码（比如原先只需要根据姓名进行模糊查询，现在多加了一个时间字段，需要根据姓名和日期进行模糊查询），所以数据库表的结构修改有时候是牵一发动全身，只能一处处改

[ying1234]

项目开启之前没有和客户沟通好，这是扯淡的，没法完全沟通好，客户做一期项目的时候估计都不知道要有二期，1年后他们才想起来要做新的功能，怎么可能提前沟通好?现在能做的就是尽量不动原先的表结构和代码,按你说的，这新功能不是对原有功能的修改，而是新的功能，那就尽量不要动原来的表结构，建新表，代码尽量用新增类，而不是改原有的类。

[ying1234]

我做过一个项目，用户连基本的功能都反复变来变去，他们自已都没定好，说好了一定不变的底层的业务规则，还是要改回原来的，你能怎么办？

[以专业开发人员为伍]

选择框架类库有一点作用，但是通常是比较初级的程序员才主要依靠的作用，一旦项目复杂、有创造性、比较多自己的核心技术，那么这条路其实也就不是什么主要的选择不大了。

回到编程本质，编程目的不是为了发布，编程的目地是为了通过测试。而测试的目的才是发布。发布以及培训的目地才是让用户良好地使用。那么当你感觉“工作量好大”的时候，往往是因为你没有一套长期积累的自动化测试机制，无法保证产品质量。

编写软件最基本的专业特征，初级的就要写大量的断言，高级的就是要写几百个甚至上千个自动测试。每当程序代码修改了，就要跑一下自动测试，每天重复、随机、并发地测试几万次，才敢提交发布。这样即使突发重大的事件需要修改代码中突发的几百个甚至上千个bug，也会非常从容。你看一个程序员此时是否有勇气，就知道是业余的还是职业的了。

[以专业开发人员为伍]

“尽量不动原先的表结构和代码”说实在的，这对程序员来说也许算是比较高级的东西，对用户和战略投资人来说则是粪土！程序员不能永远活在自己的孤芳自赏的象牙塔中，而是要跟自己所服务的组织保持平衡。而这种平衡就是用需求文档和工作日志的具体化、可操作化、精炼无废话、可以作为法律纠纷的证据来保证的。程序员又一大优势，未来社会几乎99%的行业的人都会失业，但是程序员的需求越来越多，这就是程序员的优势。所以程序员要学会把需求写成测试代码，学会测试驱动开发，不要永远只做最低级的拼凑“别人拿来的代码”的小工。

[outby]

代码量大？客户给你多长时间？给你多少钱？比如：给你一年时间，100万，一个人的工作量，这样代码量大吗？程序员要先讲钱，并且付出要和钱成正比，要让自己感觉爽才有动力做事情。 将客户的数据库复制过来，然后在原来的数据库升级，每一次对数据库更改或者增加什么删除什么，用东东记录下来，然后程序升级完了，再拿你记录的东东再更改客户的数据库，数据库改完了，然后再升级程序。

[牧歌ing]

首先代码肯定会改的，越复杂的项目修改的地方越多，选择框架有用那是肯定的，但对于大型项目来说，用处不大，因为这框架也是人提出设计出来的，对于大项目来说都有自己的框架，这套框架是基于自己项目的业务逻辑来的。

[我不懂电脑]

基本原则就是不修改老代码，可以用继承的方式增加新类处理

[左牵黄，右擎仓]

客户亦需要保留历史业务数据的查询与统计,代码修改量好大，有没有好的设计方法？ 开闭原则，对扩展是开放的，对修改是封闭的。 依赖反转原则，应该在代码中多使用抽象接口，尽量避免使用多变的具体实现类。