面
对每天繁重的开发任务和交付工期的压力
我们不会花太多的时间(更多的时候是根本没时间去考虑或经验不够丰富)考虑自己的代码在未来会如何?
或者说在相关环境变化后还能否工作?面对需求变化被修改的量有多大?
说的直白一点,就我们写出的代码没有前瞻性,不够健壮,自适应能力太差
将来整个业务系统中某一个模块的微小改动,都可能导致其他一个或多个协同工作的模块不WORK
每个开发Team对质量的要求"标杆"是不一样的
高效、稳定、可靠的系统是设计出来的,不是维护出来的
本文通过一个简单的PL/SQL案例来告诉大家设计健壮代码的重要意义
在我以前做的一个系统中,有5-6个核心业务数据库,各个数据库之间因为业务需要,有很多数据需要交互
特别是一些关键的数据模型在设计上,各个数据库之间含义是一致的
典型的比如app_col(我这里用这个app_col代表某一类字段)这样的字段
在各个数据库上的很多表结构中均包含这样的关键字段
但实际情况却是很让人头疼,我们的设计人员会设计出行行色色的定义来
我们不会花太多的时间(更多的时候是根本没时间去考虑或经验不够丰富)考虑自己的代码在未来会如何?
或者说在相关环境变化后还能否工作?面对需求变化被修改的量有多大?
说的直白一点,就我们写出的代码没有前瞻性,不够健壮,自适应能力太差
将来整个业务系统中某一个模块的微小改动,都可能导致其他一个或多个协同工作的模块不WORK
每个开发Team对质量的要求"标杆"是不一样的
高效、稳定、可靠的系统是设计出来的,不是维护出来的
本文通过一个简单的PL/SQL案例来告诉大家设计健壮代码的重要意义
在我以前做的一个系统中,有5-6个核心业务数据库,各个数据库之间因为业务需要,有很多数据需要交互
特别是一些关键的数据模型在设计上,各个数据库之间含义是一致的
典型的比如app_col(我这里用这个app_col代表某一类字段)这样的字段
在各个数据库上的很多表结构中均包含这样的关键字段
但实际情况却是很让人头疼,我们的设计人员会设计出行行色色的定义来
比如在ora_a数据库上: