春江花月夜

很久没有写长一点儿的东西了。 一半是由于太懒，另一半是因为这半年来在忙一个最终不算太成功项目。 而我认为，我们在这个项目中大量使用了SSIS package来实现业务逻辑，部分地导致了项目目前的结果。

1. SSIS Package 的编辑器，就是visual studio 2008, 是我用过的最烂的编辑器，没有之一。

   我不明白为什么总有人鼓吹用画流程图一样的方式去写程序， 我也不知道如果使用一个相当强大的对这种编程方式有良好支持的编辑器/IDE会不会非常高效。 但是，如果编辑器的质量是像visual studio 2008这样，那简直就是个噩梦。

   • 在打开script task的时候你经常会看到Error: 0xxxxxxx， 后面跟着一句废话，msdn搜到的信息也是一堆废话, 唯一的解决方案是删掉重建这个task，甚至整个package。 已经记不清楚具体的错误了，项目结束之后再未碰过ssis package。
   • 打开一个稍微大一点儿的package需要不短的时间，因为SSIS会验证连接和相关的组件。 有好几种workaround可以绕过这个验 证过程， 但是没有一个one-click的方案， 每种都有局限。

   更糟糕的是，没有可替代品。 不像文本编辑器你可以有很多选择，而且差别不算太大， 就算你在记事本里写c#， 也就损失智能提示跟语法高亮而已。但是你不可能用文本编辑器写SSIS Package， 你唯一的选择就是visual studio 2008。更离谱的是， 直到vs2012发布， vs2010都没有支持ssis package。

2. 隐藏了太多东西

   编辑一个task的时候，通常你需要双击这个task打开一个对话框，因为重要的属性有很多都不在visual studio 的“属性”窗口 里。 这还不算， 有很多属性甚至要右键点击这个task， 在所谓的advanced editor里面才有。 task中充满了隐晦的参数设置和模态对话框，定位问题时相当头痛， 编程效率非常低下。

3. 几乎不可能进行code review

   SSIS Package的源码是xml。 xml是文本格式， 但问题在于SSIS Package为每个变量和task生产guid，所有变量和task的引用都是通过guid，并且会生产大量的只有SSIS 本身才能理解的属性， 再加上每次build一次package， guid会重新生产，xml节点的顺序也会打乱，code review就变成了一个不可能的事情。 每次有同事发package的code review邀请， 你都需要把package复制到本地， 用vs打开， 才能review。 这样你无法有效的diff，只能打开每一个task， 一层一层的打开模态对话框，然后去看每一个属性该了没有。 这根本是个不可能的任务。

4. 没有人愿意再去动一个已经写好的package

   基于1和2的原因， 除非这个package确实有问题，不能正常运行。 否则大家倾向于能不动就不动，就算有点小问题，也会改其它地方来迁就package。 这是很可怕的事情， 没有优化，没有改进， 并且为了迁就它做的其它部分的改动扭曲了本来应该有的良好设计。

这就是七宗罪了，谁说一定得有七条来着？ ：）