减少和发现未知的bug： 方案征集

大家集思广益，共同寻找一个解决方案。
问题描述：
开发过程中常出现“牵一发而动全身”的问题出现，比如：A同学改了一个Bug，引起了B同学负责的模块出现新Bug。这类情况在二次开发与产品合作的过程中反复出现。只要存在Team之间或Team内部队员之间的协作就难免出现上述问题。事实上，即便是一个人维护的系统，也可能会有新的update导致现有功能模块的返工或错误产生。
随着系统的维护时间越来越久，依靠大家用记忆和沟通来确认每次系统更新对现有设计的影响也愈加困难，好的方法是加入覆盖全面的Unit Test。

现提出一些设计要求，请大家踊跃参与讨论，提出自己的见解：

1. 尽量覆盖所有的二次开发的业务Case
2. 测试完成后资源要释放
3. 方便扩展和修改
4. 工作量尽量小
5. 单元测试为独立的测试模块，建议用独立的项目和DB

---------------- 从代码复用的角度，看“牵一发而动全身”的问题。------------

关于模块1中代码的改动影响了模块2中功能点出现了异常的问题的分析。这个话题比较大，单元测试的部分平时也写的较少。
就从代码复用来看。
二次开发工作：

• 大部分时间是维护产品研发的部门的代码，当初的代码设计者的初衷是否理解，在理解的基础上再去分析设计意图是否合理，新的需求变更是否能纳入旧有的设计意图中。
• 添加新的功能（暂不做说明）。
  

业务层：
       1.需要什么样的功能模块，从研发部代码库中取得或者引入对应的代码块，不要一下子都拿过来(好多项目都是通过隐藏菜单来干这事，或许有更好的办法)。
       2.理解和判断原来作者的意图：原来的产品中与新需求的实现，有类似的功能，或者原功能的扩展。
理解和判断原来作者的意图（这一段的说明限制在业务层面），尽量不要绕开这一步（实在看不懂另当别论）重头再写一遍，而且把没有意义的代码留在那里，迷惑其他开发者而应该扩展原来的代码，提高重用。

持久层代码的重用：
       所有的功能都需要在数据库中记录信息，对这一块的重用概率比其他地方都多，我们的项目中这一块存在问题。
举例来说：
简单功能a：增，删，改，查表t_scs_product的信息。
复杂功能b: 增，删，改，查表t_scs_product,t_scs_instance_info的信息。
对这两个功能的开发，要针对表t_scs_product,t_scs_instance_info写dao层，表记录对应的结构体（c）或者数据对象（java）。
对表的基本操作的这些模块或者类，应该在表创建或修改后可以动态生成或者更新。对应的模块或者类是公用的，应该存放在指定地点中，而不是隐藏在各个具体业务层代码内。知道有这个dao和数据对象及其统一命名，才是我们项目中这一部分代码重用的前提。
假设：简单功能a，我现在要对表t_scs_product扩展一个非空字段，如果功能a和功能b没有复用表t_scs_product对应的dao及其数据对象，b功能点的程序会有问题，但不容易被发现。提前发现和定位问题也算一种开发中经常用到的技巧，避免某个晚上或者周末被未知的bug纠缠也是一种能力的体现。
维护性好的系统，应该允许维护工作，安全，准确，容易以较低代价的形式进行。