谈谈我理解的WPF团队模型——在UI Designer与Developer之间

            谈谈我理解的WPF团队模型——在UI DesignerDeveloper之间
                          
周银辉

1,旧的模式已经不再适用

首先看看如果我们将旧的(.net3.o之前)模式直接引入到WPF中将是如何工作的。无论采用什么样的沟通方式,我们需要DeveloperUI Designer之间对软件的功能达成共识,然后我们可以得到当前界面的大体LayoutOK,这个被验证和确定以后,UI Designer会细化他的工作,提出一些她的一些新观念,软件UI风格,然后细化出一张张的效果图(利用PhotoShopPowerPoint等等)。接下来,Developer所要做的事情是:“照葫芦画瓢”,照着UI Designer的效果图,再Blend中将其模拟出来,以便形成可供程序使用的XAML。我们可以将这个过程称之为Translate(将效果图(PNGJpg)翻译成XAML)。

这所带来的问题:

(1)UI Designer的大部分“产出”的丢失,我们知道UI Designer除了告诉我们UI应该是怎样来展现以外,其设计过程中的大部分作品被抛弃掉了(比如设计了很长时间才做得很漂亮得一个按钮图片),这是由于其产出不能直接用到我们的Project中(我们要得是XAML而不是PNG,Jpg)。到最后UI Designer那边好像仅仅给我们提供了很多idea,而没有实质性的东西输出给我们以便用于我们的的Project.

(2)Developer这边“费力不讨好”。所谓“费力”指的是就大多数Developer而言本身就不擅长绘图(即便您有Blend这类傻瓜式的工具),所以你很难得再Blend中将美工那边提供的图形完全模拟出来,所以,Designer那边有意见了,您将人家美丽的艺术品转化得一团糟糕了。即便某某很牛,模拟出来了。仍然“不讨好”,因为这是重复劳动,DeveloperBlend中做得这部分工作事实上美工再Photoshop(或其它)中已经做过一次了。

一个可能得疑问是:为什么不让UI Designer们再Expression BlendExpression Design中工作呢?先说在Expression Blend中工作,除了培训成本(我想这个培训成本应该是相当高的)以外,就大多数UI Design团队而言面临的最严重的问题是:他们没有软件开发的观念和知识,无法将他们融和到开发流程中来,如果他们负责Blend这块的话,他们的一举一动将直接影响软件的性能和功能。比如他们不会按照Developer的观念来合理组织资源,他们不会考虑XAML代码对性能的影响,没有模块话的观念,不会顾忌软件的可维护性,稳定性。他们只会关心“这样的界面简直太漂亮太好用啦”。那么结果可想而知。再说Expression Design,事实上这是可行的,如果老板愿意出这部分培训费用和培训时间以及UI Designer乐于使用新工具的话。

2,新的模式有那些?

新的模式有好几种,这取决于团队中成员的技能和职责,但我比较推荐的有两种。

(1)集成模式

WPF角度看,团队中除了UI DesignerDeveloper以外,我们再引入一个新的角色Integrator。首先看看他们各自的职责:UI Designer的职责保持不变,但我们稍稍改变一下她的“输出”,其除了输出各种idea,布局图,效果图等等之外,其还将为我们输出其它所有的图形(比如一个漂亮的按钮),但是以XAML的形式(这会用到一些插件或小工具,你可以在这里找到http://www.cnblogs.com/zhouyinhui/archive/2007/12/08/987928.html)。请注意,其输出的是一些松散的XAML零部件,仅仅描述了图形,没有StyleTemplateTriggerResource等概念。这样UI Designer既不会改变惯有的工作方式,又可以专注与图形和用户体验。而Developer的职责也保持不变,其专注于后台逻辑,但放弃对界面的所有权,其是C#(或其它)的拥有者。而Integrator将致力于他们两者之间的结合,其负责将从UI Designer那里得到的松散的XAML按照软件开发者的观念在Blend中组合成真正的项目中的零部件,比如其将负责TemplateStyleAnimation以及界面的模块化,资源的组织,考虑其可维护性,稳定性,对性能的影响等等,其是XAMLBlend的拥有者。

这有一些明显的好处

(i)                  没让成员做不擅长的事。在旧模式中,让DeveloperBlend中绘制出艺术品或者让UI Designer按照开发者的观念来管理Blend端显然是强人所难,并且这也会分散他们的精力甚至带来抱怨。但目前的模式将这些负担转移出去了。

(ii)                避免了重复劳动。旧模式中,Developer来“翻译”UI Designer的成果的劳动是重复和痛苦的。而当前模式中图形的XAML直接来自于UI Designer。我们需要做的仅仅是整合。

(iii)               避免了实际“翻译”出来的UI与设计时的UI的不一致。两者差距有多大完全取决于Developer的“翻译”能力,但往往效果时不理想的,以至于UI Designer觉得自己的艺术品被扭曲了。

(iv)              有人专注于Blend端,那么软件的表现层端质量将更高,更容易维护。

(2)收割模式

WPF角度来看,这个模式中只有两个角色: UI DesignerDeveloper。这个模式对UI Designer的要求较高,其需要能熟练使用Blend来创造一些成品供Developer“收割”。比如我们需要一个漂亮的按钮,那么UI Desinger直接输出给我们该按钮的Style。其甚至可以输出其它更复杂的东西,比如UserControl(不可能是CustomControl,因为他们不会写程序逻辑,除非和Developer合作)。他们的工作是在解决方案中的某个辅助项目中完成了,而负责软件的真正表现的Blend端由Developer来负责,因为这里需要考虑很多软件开发的东西。

该模式同样拥有集成模式的各种好处并且与集成模式相比,UI Designer更加融入到了项目开发过程中,但对UI Designer的要求较高。

其它一些建议:合理地整合Blend端,如果发现XAML文件过大就模块化。保持UI项目始终能用Blend打开,否则将导致团队中某些角色出局或工作起来很麻烦。别让界面和逻辑耦合在一起,如果发现逻辑对界面元素引用过多,那么可能在BindingTriggerResource等方面做得不够好。另外,相比之下,我更推荐第一种模式,我在这种模式下工作了不短时间,Integrator是我的职责之一。

个人理解,还不成熟,欢迎评论。

posted @ 2008-01-17 12:28  周银辉  阅读(...)  评论(...编辑  收藏