一个老系统， 有点需求改动，上面的人给了我份mail "please check all these sp and views "
下面是份清单，两百多个存储过程和视图，只知道这些东西和需求有点关系，有些需要更改。
最后差不多改了30~40个，很多是重复的逻辑。
不说点什么有点对不起这周自己的“辛劳”
客观的说，sp是过程式的比OO更容易理解。没有什么文档，甚至没有什么注释，而且也不需要run and debug，偶最后基本上还是搞定了。
如果是OO的话，一般说来不会那么轻松，接口，继承，多态，封装和交互，再加上若干巧妙的模式，缺少文档还真不好理解，尤其对OO的新手来说。首先现实环境下文档基本上是欠缺的（就算不欠缺你也不应该指望它质量好到哪里去），然后OO基本是貌合神离的（同高质量的OpenSource比起来），而且对有些结构既定的OO结构，有些需求可能也未必那么容易满足（我承认自己的设计能力，你要要承认真正能把需求分析做好的人不多），总的说来OO对维护来说未必是件轻松的事。
不过，偶绝对还是OO的Fans, OO的设计能力通过学习和实践总归是可以提高的，但是使用存储过程的话（暂时屏弃它的一些优越性），过程式的语言的确很难封装和重用，对小系统来说可能感受不是很深，我只是想说，偶这周解决的真的是个很小的需求，如果在Domain层面使用OO的话，可能半天就搞定了，然而这些历史的SP，却毫了我一周的时间。什么叫做维护成本，That is!
ps下，如果SQL Server的查询分析器里面也能象VS.NET那样，在SP里面把焦点放到某个引用到的SP然后Go To Definition，然后还能Go Back，我的工作效率肯定能提高很多。
下面是份清单，两百多个存储过程和视图，只知道这些东西和需求有点关系，有些需要更改。
最后差不多改了30~40个，很多是重复的逻辑。
不说点什么有点对不起这周自己的“辛劳”
客观的说，sp是过程式的比OO更容易理解。没有什么文档，甚至没有什么注释，而且也不需要run and debug，偶最后基本上还是搞定了。
如果是OO的话，一般说来不会那么轻松，接口，继承，多态，封装和交互，再加上若干巧妙的模式，缺少文档还真不好理解，尤其对OO的新手来说。首先现实环境下文档基本上是欠缺的（就算不欠缺你也不应该指望它质量好到哪里去），然后OO基本是貌合神离的（同高质量的OpenSource比起来），而且对有些结构既定的OO结构，有些需求可能也未必那么容易满足（我承认自己的设计能力，你要要承认真正能把需求分析做好的人不多），总的说来OO对维护来说未必是件轻松的事。
不过，偶绝对还是OO的Fans, OO的设计能力通过学习和实践总归是可以提高的，但是使用存储过程的话（暂时屏弃它的一些优越性），过程式的语言的确很难封装和重用，对小系统来说可能感受不是很深，我只是想说，偶这周解决的真的是个很小的需求，如果在Domain层面使用OO的话，可能半天就搞定了，然而这些历史的SP，却毫了我一周的时间。什么叫做维护成本，That is!
ps下，如果SQL Server的查询分析器里面也能象VS.NET那样，在SP里面把焦点放到某个引用到的SP然后Go To Definition，然后还能Go Back，我的工作效率肯定能提高很多。
