《用户界面的可视化开发工具--一朵美丽的罂粟花》(转)

 

   

    ■ 文/ 杜玄、苏丽辉

    RAD为快速开发图形界面的软件带来了方便和快捷，但界面代码和控制逻辑代码的紧密耦合却又使开发人员陷入了软件界面开发的泥潭。怎样才是正确的进行界面软件开发？如何才能走出软件界面开发的泥潭和误区？

那是多么令人激动的时刻，至今还记忆犹新-- VB（VisualBasic）为开发者提供了令人震撼的开发手段。在VB集成开发环境中，只要用鼠标拖几个控件，填写几行代码，一个漂亮的图形用户界面程序就完成了。在VB出世之前的时代，最繁琐的工作就是开发图形用户界面。VB 的出现宛如一颗救星，每个程序员都为拥有了如此方便的工具而高兴。当年，VB的卖点就是WYSIWYG，所见即所得的界面开发，自动生成界面的代码。因为这项天才的创意，使VB成为了开发工具中的明星。从此以后，Delphi，Visual Age，JBuilder 等等，它们全都步VB 之后尘，被誉为4GL RAD（第四代语言快速应用开发）。

Borland 公司的王牌开发工具Delphi，更是把可视化开发能力做得出神入化。之后，Borland 又推出了JBuilder，把所见即所得的界面开发模式带入了Java时代。工具窗口，布局区，属性窗口，代码编辑窗口是经典的界面IDE 开发环境所见即所得的界面开发让人赏心悦目，她就象一朵美丽的“花”，在我们眼前展现。但是在现代大规模软件开发过程中，在全新的开发理念下，所见即所得的开发方式却象一剂毒药，慢慢麻痹你的思维，使你养成坏的开发习惯--使你背离敏捷的思想，使你远离单元测试，使你的体系层次不分，使你的模块紧密耦合。最终，界面部分成为整个软件系统的软肋，界面软件模块是一个没有单元测试覆盖的，业务与界面混杂的所在。她是一个Bug的集聚区，她是一个极难重构的地方。我们要警惕，所见即所得的开发方式是一朵美丽的罂粟花，花儿虽美，却会毒害我们的思想和整个研发流程。

    一个吸毒者，毒瘾的形成是因为毒品可以带来暂时的快乐。所见即所得的开发方式首先给予我们的也是一段快乐之旅。

    在VB 出世之前的时代，用C来开发界面软件，我们只能看到函数，只知道用一行行代码画出界面。实现一个菜单，要书写大量的代码；实现一个鼠标功能，竟然要用到了底层的鼠标中断。Windows的到来更加重了这一危机。VC和BC虽然简化了一些界面开发，但面对需要大量手工编码的用户界面开发，程序员还是不堪重负。

    在那个年代，VB 的出世确实是一个巨大的进步。VB 式的可视化拖放式开发，大大提高了单机版程序和C/S体系中客户机程序的开发效率。她带给老一代程序员的是无限的甜蜜，图形界面密集的软件系统几乎全部投入了她的怀抱。蜜月的旅程是让人甜蜜的，一时间，以VB 类软件为开发手段的软件系统极大发展。从单机版的软件，发展到C/S结构的客户端开发。VB，Delphi，PowerBuilder 成了C/S体系客户端开发的霸主。但是，随着软件的发展，新的开发理念，开发思想不断涌现。比如，多层体系构架、面向对象的开发设计、敏捷开发、模式、单元测试、每日构建等等。这些新思想，新方法为我们打开了软件开发的崭新之路。软件在发展，开发工具在发展，软件进入了应用服务器年代。今天，Java语言成为了企业应用的主角，它在企业软件市场中如日中天。Java如何来做软件界面的呢？贴心的集成工具厂商已为我们准备了JBuilder，Visual Café，Visual Age等等所见即所得的界面开发工具。这样，在Java年代，我们又可以延续VB时代的蜜月之旅了吗？确实，由于惯性，我们正是在延续VB 的开发习惯，然而这已是蜜月的结束，毒性开始发作的时候了。

    我们用JBuilder 是怎么工作的呢？实际上，它开发界面的工作思路还是与VB 一脉相承。

    首先，开发者会设计一个界面的原型，或者根据需求在头脑中有一个界面的原型。随后开发者就会打开JBuilder 之类的IDE环境准备做界面。

    第二，通过拖放把控件放在IDE的窗体设计器的画布上，根据XY坐标绘制窗口，把控件排放整齐。多么方便，工具还为我们提供了控件对齐工具。

    第三，调整窗体上控件的风格，位置，大小，字体,国际化等，使界面上的元素符合《界面编程规范》（正规的软件开发团队都有界面风格统一的要求）。

    第四，写一个main函数，把界面程序运行起来，看看布局，风格等是否正确。这时的界面又漂亮，又符合规范。

    第五，为需要响应动作的控件添加响应事件。多么方便呀，与VB 一样只要双击界面按钮，按钮响应的事件代码框架就生成了。

    第六，通过图形界面直接导航到控件响应事件函数，添加业务处理代码，比如连接数据库，与应用服务器通讯，处理业务数据等。这时的main函数已经不能运行了，因为数据库等还没有做好，没有地方连。

    第七，等待测试环境，等待数据库做完，等待应用服务做完，等待其它联调环境。这是界面开发人员的轻松时刻。

    第八，调试环境准备好了，进行联调。发现事件代码中有好多逻辑错误，赶紧修正问题。开发人员加班加点。

    第九，刚调试了一半，又赶上调试环境有问题，只好继续等待调试环境准备好。最后，总算见缝插针在调试环境具备的时候把界面逻辑和业务逻辑调试好了。终于提交测试了。

    第十，需求变更，要在原有界面上加一个按钮，处理一个新业务。恶梦开始了：这时的界面代码由于依赖XML国际化文件，IDE工具已经无法正确的通过代码来还原界面的布局。并且由于是用的XY坐标界面布局，没有IDE，界面不能加任何东西。没有办法，为了加一个按钮，也要重新画界面，再把事件中的代码拷贝过来；不幸又发生了，由于原来业务逻辑与界面代码混合写在一起，加的这个业务逻辑与其它界面控制互相牵连，没有办法，涉及到这个业务的代码全部要重写。更不幸的事情也发生了，因为没有联调环境，你根本就无法进行调试，根本就不知道修改的是否正确。我们只好等待，等待完好的数据库，等待完好的服务器，没有环境，界面没有办法验证一个小小的问题。一个按钮的添加竟然摧毁了整个代码。

界面开发人员只有拼命加班赶进度，因为大家都在等你。

第十一，我们抱怨：业务怎么总是变来变去。我们抱怨：JBuilder不好，无法从代码正确的还原界面布局；我们抱怨：联调环境怎么还没有准备好？

    第十二，最后的结果是工程延期，用户很纳闷，一个简单的业务变更也实现不了。可是我们开发人员有借口：GUI开发没有联调环境，IDE的WYSIWYG设计工具不好用，界面没有办法做单元测试。我们把“综合症”总结一下，如果你或你的团队有这样的症状，那么你现在或不久的将来就有可能经历上面的痛苦。

    界面代码开发中毒的症状表现：

    * 没有JBuilder 之类IDE环境就不会做界面。

    * 修改别人的界面程序成为大家都不愿做的工作。

    * 依赖人来画界面，同时还依赖人的眼睛来检验是否符合规范。没有自动化的检验手段。

    * 界面与控制逻辑紧密耦合。

    * 界面与服务资源紧密耦合。

    * 单元测试在界面代码中是“白区"。

    * 界面设计器产生的代码臃肿不堪，阅读困难。

    * 严重依赖调试环境，修改极其困难，改了也不知对不对。

    * 无法修改别人布局的界面，只好重画。

    * 界面开发成了最消耗时间的软件任务。

    * 开发工具被限定为一种，换用其它工具将造成界面代码无法正确打开的问题。

    反思

    经过了上面的开发经历，你还喜爱所见即所得的开发方式吗？这样的开发方式，就像我们吃一串葡萄，又大又甜的葡萄已经吃尽的时候，你面对的就只有又小又酸的葡萄了。酸葡萄可以丢下不吃，但是软件却不能不做。不但要做，而且要满足用户的要求，要负责到底，除非你有勇气炒老板的鱿鱼。

    曾经见过这样一句话--“懒惰的程序员才是优秀的程序员”。这样的一个程序员，在面对繁琐复杂的工作的时候，首先想到的是如何运用智慧少做工作而多出成果，而不是拼体力加班加点来完成工作。我们思考，分析问题的症结所在，从主观思想与客观情况入手，找出原因。是什么使我们陷入这样的境地？在思想上，由于所见即所得开发工具的麻痹，使我们忽略了软件开发的核心价值。

    开发阶段前期只沉醉于界面绘制的快捷方便，而忘记了后期软件维护的困难，没有从软件开发的整个生命周期看待界面软件开发；界面软件开发中在可视控件的响应事件中快速添加代码，只顾及了代码添加的便捷性，而忽略了客户端软件的体系构架的设计；在客观上，所见即所得的开发工具只是一个通用的开发环境，不能适应不同团队的界面软件规范的特殊性，大量布局，调整控件大小等任务在手工地重复，没有实现软件的复用。

    从IBM收购Rational，Borland 收购Together这两个事件中，我们看到开发工具厂商更加重视IDE环境中建模能力的加强。这也从一个侧面反映出，软件开发的技术核心价值在于模型的设计，而不在于界面的绘制（至于界面的美观性和易用性的问题已经不是简单的技术可以解决的问题了。它涉及人类美学和心里学的研究，不是我们这里所讨论的问题）。对所见即所得界面设计的依赖是历史原因造成的。从VB类开发方式所笼罩的过去，由于惯性，自然而然地把VB类的开发方式带到了现在，并且开发人员很难扭转这种界面开发的思路。其中一个重要原因是，拖放式开发界面上手很快，一个非IT 行业的人，也可以通过一天的培训做一个基本的图形界面。这样，初学者很容易尝到甜头。让一个软件如此简单地运行起来，使人内心充满了成就感。这样，初学者仿佛找到了进入程序殿堂的正确入口，会认为自己可以成为程序员了，并且在真正成为程序员后也乐此不疲。如果让这样的程序员去做实际的软件开发，蕴藏在背后的将是大量的问题。初学者在逐渐的成长中也会一点一点地体会到界面开发的痛苦。他们感受到痛苦，但他们无法分辩这痛苦的根源，也没有能力提出解除痛苦的办法。这是因为，他们进入软件开发殿堂的大门是一条“捷径”，他们忽视了必须的知识积累，其实他们还在门口徘徊。

    我们应该记住一个原则，当你感觉到开发过程中的某一部分过于繁琐，是影响项目的关键点时，这部分内容就是需要我们改进的内容。无论是从流程管理上，还是从技术上对关键点的一点改进就可以为整个  项目带来巨大收益。界面开发过于依赖人和工具，难于调试和重构，是系统的故障点密集区，也是系统进度的瓶颈。这就是我们要改进的地方。界面代码与控制逻辑代码紧密耦合，界面代码与服务资源代码的紧密耦合。这些问题，本质上不是JBuilder 类似工具造成的。用不用JBuilder工具，都可以设计出模块分明，层次清晰的客户端代码。但是，用JBuilder 类似的所见所得窗体绘制工具，往往会导致坏的开发习惯，对于初学者尤其如此。比如，直接在生成的控件事件代码框架中编写业务逻辑代码，编写控制代码，直接访问数据库等。对于一个初学者，对于一个“资深”VB 开发者，这样的过程却被看作自然而然的事情。

    随着初级程序员的成长，工作压力很大，他已经习惯了这样的界面开发模式，整天重复在界面开发的痛苦中。有些人就开始逃避，改做看似高级复杂的服务端的代码，从此远离界面开发，把界面开发交给新来的初级程序员。在服务端的软件开发中，接触到了大量软件核心的东西，比如模式，单元测试，重构等，但是他们并没有解除界面开发的痛苦，只是逃离了痛苦，还有其他人在其中挣扎。无论新老程序员，每当要开发界面的时候，总是要想到找一个IDE环境来画界面，总是不自觉的把资源依赖，逻辑控制与界面元素搅到了一起。VB拖放开发方式深入人心，就象一个魔咒禁锢了开发方法改进的思维。我们困惑，界面开发难道只能用VB式的拖放作为开发方式吗？为什么一定要人工排列图标？为什么一定要用JBuilder才可以画界面，为什么要去忍受臃肿的代码？为什么不可以引入单元测试，为什么不可以象服务器模块一样做到控制，资源与界面的分离？

    开动脑经，转变思想，做一个“懒惰的程序员”。我们完全可以打破VB式的开发思维，引入新的开发思想和方法，解除这个魔咒。本文后续部分将讲述如何解除界面开发模式对软件开发的影响。（待续）