Tibco Designer是一款不错的IDE，可惜一些基本功能，搜索，重构，错误修复比起"传统的"基于source code的IDE来说，还很不足。
图形化开发好处是每天只要点击点击鼠标就把事情搞掂了，坏处是事情变得简单之后就让人不愿意多想，加之需求的变化，设计的变化，在不断的连线画图之后，怪物就此诞生。
这些天吴老板叫我重构，花了很大力气之后，有了以下的感慨。
细化process，我觉得在一个process里要么就全是调用其它子process，要么就只有具体的activity，不包含子process，子process之间的数据传递完全用copy或者copy contents of的方式传递，这是比较完美的。每一个最底层的process（只会被其它process call的）只做确定的一件事情，涉及到两种schema的转换或者是把多个process的output汇总到一个xml node的行为都用单独的process封装起来。
这样的带来的附加好处是方便unittest，每一个小功能都可以直接用tibco test测试了。
另外，一些数据长度判断等数据有效性校验都封装在底层的process中，外面的流程尽量简介易懂，美观第一。
谨慎地定义接口，在定义接口（process的start和end的数据结构）时，全面分析各项impact，应该是什么数据类型，该节点是不是 mandatory的，最宽泛的接口定义是把所有的节点都定义成optional的string类型，这最终会害死人，苛刻的接口定义会把许多错误在开发 阶段暴露出来，并且有个附带的好处，用tibco test做unittest的时候，系统会自动生成mandatory的节点，方便我们填写测试数据，如果没有含混不清的接口定义，填写了 mandatory数据后这个test就能跑了。
如果一个数据结构在超过两个地方出现，在外部Schema文件中定义它，然后将该数据结构导入。
以后要修改该数据结构只要修改schema，refresh project，update修改该数据结构的activity即可。而且在designer的input editor里面是不能定义一个节点的attribute的（我没发现相关的方法），在schema文件里可以，虽然这好像没什么用处。
在schema中可以对数据进行进一步的限定，如最大最小长度，枚举类型等等，结合上面说的接口定义可以做出更严格的接口。
在process的Description里面填写一些说明和测试数据。
进行有意义的命名，填写label，对线条着色都能让项目好看一点。
如果视图超过了一屏，就改考虑要重新规划一下了，把功能相关的调用封装起来，无论从视觉效果还是做debug，unittest，感觉都会好得多。
其实还是老话，封装变化，模块化开发。
W. C. Fields - "I cook with wine, sometimes I even add it to the food."
