软件的复杂度

软件做大了，就会在集成的过程中发生各种各样的问题，尤其对于平台的一些更改，平台的开发人员永远无法意识到自己的一行代码的变更会对哪个业务组产生影响 ，而业务开发人员常常在软件运行的很稳定的情况下，某天突然磞出一个 BUG，忽然大吃一惊，怎么会发生这种问题呢？ 可是谁来管理模块之间的相互影响呢？实际上应该是在设计的阶段就确定下来各个模块之间的通信机制，可是由于在开发的过程中，不断的在解决各种各样的问题同时加入了新的需求，所以在设计阶段确定的通信机制，在不断的开发过程中发生着不断的变化，而这种变化没有能够及时的被人发现，如何让这些每天都发生的变化，暴露出来呢？

    我想一个可行的办法，就是每日集成，每日自动化的测试， 这可以保证第天的变化都会被在集成和自动化测试脚本之中暴露出来， 因为是每日的，所以每次的变化都是微小的，所以发生错误也显得容易，实际上软件中解决的问题也遵循2/8 原则 ，即80%的时间用来发现错误，而却只需要20%的时间来解决错误，每日集成确保发现错误的时间变小，因为一旦发现错误，你只需要将代码回滚到上一天，在代码管理器里查看previous version，就可以查出两版之间的差异，从而定位出错误，这种定位错误的时间常常是非常的迅速和有效的，可是为什么 用友U8的开发团队 很难建立起这么一个过程呢？ 
     我觉得是环境， 实际上，代码之间有版本，并且可追踪，可是要知道环境也是有版本的，编译环境，开发环境，测试环境，它们之间如何达到版本协调，如果无法协调它们，就会涌现出大量的不兼容，未设置with block 变量，等诸多问题,考虑到 U8 开发的特殊性（vb,vc,.NET）,三种语言混合开发，环境问题常常使开发人员无法集成精力去钻研代码及业务，无法使测试人员专心于测试逻辑，无法使管理人员控制进度，因为一个环境问题常常要耗掉 1一天的时间
    环境问题，常常让我们一头雾水，保谓环境，总觉得让人说不清楚， 实际上环境是软件赖以运行的环境的简称。 那是什么： windows操作系统 + 注册表+ 当前版本U8的所有组件的版本+ 所有运行的脚本 的总称，环境是如此的复杂，以至于当我们无法定位问题时，我们就可以理直气壮的说：环境问题，谁也说不清楚是哪一个环节上出问题了，只是一个环境问题了事，而且头头们也无法追踪问题的原因。
   其实我们也处在用友这样一个大的开发环境中，用友的很多问题无法得到有效的解决，我们也会堂而皇之的说是环境问题
    我在想如何创建一种有效的机制去解决环境问题？