敏捷界面重构

敏捷界面重构 — initial idea

很多人都觉得界面的事情是细枝末节，等功能做好了，找个时间一起清理一下就好，不会占用太多工夫。很多人也都是这样做的。

这里说的界面开发是指系统的交互设计和界面可用性及易用性设计，也包括CSS的界面布局、颜色、字体等基本的视觉元素。这些问题的重要性不用多谈。

我在项目中期加入过几个项目，这时候最令人头疼也最令人兴奋的莫过于在开发中期对于界面和UI进行变更了。一个项目在初期如果没有做良好的界面设计，想要在中间来进行大的变更简直是噩梦一般。在一个敏捷团队中，做这样的事情尤其困难。

敏捷开发中的一个实践，是需要客户的协作和参与，及时由客户认可做完的需求以及由客户决定下一步的开发。这种客户享有决定权能够使开发变得更顺畅，客户关系变得更融洽，是一个很好的实践。

但是，这种实践给界面的改进带来很大的麻烦：如果在项目中期打算进行界面的变更，自然要写出很多跟界面相关的需求，而客户按照需求的价值决定优先 级，他们有时候不理解这样的界面改进如何带来价值，为什么改善一些文字描述和交互方法还要占用开发时间，他们更希望在有限的时间内增加更多的功能和修复更 多的BUG。这时候，这些界面调整的优先级就被排的很低，在几个开发周期内都没有得到采纳。

我们先后尝试了几种方法来改进这个过程，例如给客户培训交互设计和可用性知识；将开发人员分为两组，其中一组专职负责界面改进；或者将界面改进需求单独分成一组，要求客户每个迭代从其中选择一部分等等。但这些办法都不是很理想，没有达到预期效果。

事后总结原因，觉得最大的原因还是在于：客户不是用户。他们虽然负责对项目功能验收，但他们并不最终使用系统。系统使用上的问题不是他们最关心的。他们需要得到投资回报，因此选择了回报更快的功能开发。从这方面看，客户的选择是无可厚非的。

理想的解决方案应当是在一开始就对界面及UI进行控制和把握，并进行持续的度量和改进，或者称为：界面重构。将界面重构和代码重构等同到同样地位，在开发过程中持续随时的进行改进。

我们都知道，代码重构是在不改变代码行为的基础上，改变其内部的结构。通过一系列小的步骤进行重新构造，系统不会因为这些小步骤的改变而停止运转， 仍然会保持顺利正常的运行。重构的结果是一套良好可读的代码，它不仅能够对我们扩展功能有帮助，也是我们适应变化的基本手段之一。

我们将其类比到界面的开发过程中：我们需要在不改变界面功能的情况下，通过一系列细小的步骤，来改变界面的交互行为和可用性。最终结果，不仅仅是一套良好的界面，也是保证我们扩展新的功能和适应变化的基础。

重构的一个要点是测试。测试可以保证重构的正确。而界面开发的过程中，测试工具的缺乏导致我们不得不采用其他的方式来保证功能的正确。一种可行的办 法是维护一个界面原型，纸质或电子形式均可。在不停地开发过程中，不断的维护这个原型，使之先于实际实现被用户感知和体验，提前获得用户的反馈和客户的认 可，并将原型用于指导团队的开发。这种不断的用户体验和用户测试过程，可以在一定程度上保证界面重构的正确性。BA阐述需求或QA进行验收测试的时候，也 不妨考虑使用界面原型作为一个验收条件来展现给开发者。

重构的另一个要点是要经常不断的进行，每当写新代码之前，先进行一点重构，使旧的代码更好阅读。界面重构也应该是这样。对每一个开发完成的需求，提 高界面验收的标准。不仅仅是完成功能就可以，还需要达到一定程度的可用性和可维护性要求。例如必须遵循提前制定的UI Guideline等等。避免因为界面开发的涣散导致的破窗户，这种疏于整理的小细节可能最终成为最头疼的问题。

比如，我们在开发的过程中，以前只以60分作为界面的验收标准，等积累一段时间后再批量修改界面一次，但可能这次修改只能达到80分。现在我们需要 改为以80作为验收标准后，在开发的过程中多花点时间来重构一点点，一直保持80的水平。这样如果我们需要进行更大的改进，可能很容易就能改到90或 100分，从而达到我们最终的目标。

由于开发团队的人员多数不太擅长界面的知识，并且界面的测试和度量工具缺乏所致，界面的持续改进在项目中较难做的很好。这些实践又要求BA或QA能 够有相应的交互设计能力和可用性工程的经验，也限制了其在项目中的实践。但这些确是在一个项目中长期被忽视地方，应当进行一些加强和发展。

总而言之，敏捷过程和界面设计并不是矛盾的，将敏捷的思想应用于界面开发和交互设计的过程中，我们可以获得更多更广泛的想法。

4月23日，和Erik谈 了谈这个想法，他也认同这类做法，但觉得由于目前没有一个显然的Vision，或者说，不像Code Refactoring那样有良好的OO设计准则和可读性在前方可以到达，这样的UI重构的准则不是很明显。原因可能还是由于Developer大多缺乏 这方面的Sense。路还很长。

评论

17 楼 neora 2007-06-13  

dlee 写道

对于页面进行有效的重构有一个前提，一定要将页面中结构、表现和行为严格分开。这并不是什么学究的理论，实际上这正是W3C设计XHTML/CSS/DOM三个规范的意图。这是一个最低的要求，而不是什么高不可攀的要求。

什么是页面中“结构、表现和行为”？哪些属于结构，哪些属于表现，哪些属于行为？分别靠哪些技术或哪些技术标准来实现和规范呢？

16 楼 过河卒 2007-05-31  

冰云 写道

由于目前没有一个显然的Vision，或者说，不像Code Refactoring那样有良好的OO设计准则和可读性在前方可以到达，这样的UI重构的准则不是很明显

dlee 写道

对于页面进行有效的重构有一个前提，一定要将页面中结构、表现和行为严格分开。

dlee说的不就是lZ要找的标准吗？

15 楼 InnocentBoy 2007-05-31  

其实什么事情做好都不是一件容易的事情！

14 楼 maoone2003 2007-05-27  

楼主说得都非常到位啊

13 楼 tv9 2007-05-22  

要UI好，就得投入精力与金钱，两者差一都不会成功，没精力与毅力，CSS样式学不好，没金钱，请不到精通UI的开发人员

12 楼 dlee 2007-05-13  

对于页面进行有效的重构有一个前提，一定要将页面中结构、表现和行为严格分开。这并不是什么学究的理论，实际上这正是W3C设计XHTML/CSS/DOM三个规范的意图。这是一个最低的要求，而不是什么高不可攀的要求。

实际上，目前的服务器端一些开发框架和开发技术为达到这个目标添加了一些额外的障碍。例如一些JSP Tag所生成的代码中结构、表现、行为是完全混在一起的，包括Ruby on Rails及其内部所使用的RJS生成的代码一样存在着这样的问题。

我们的页面都是程序员手工制作的。我在指导程序员制作页面时，要求他们一定要达到上面的这个要求，并且尽量达到最简化，通过使用CSS消除重复的部分。我还鼓励他们过一段时间就检查一下页面的HTML和CSS，看看有没有可以进一步简化的可能，并且我本人也会经常检查程序员制作的页面，并且手把手指导他们如何对页面进行简化。CSS是非常重要的技术，《精通CSS》这本书应该成为每个界面程序员必须熟读的书籍。

界面程序员要精通页面制作，这里没有什么价钱可讲的，而是必须要满足的要求。同时，收入分配并不会因为工作性质的不同而分成三六九等，界面开发程序员的收入应该与业务逻辑开发程序员的收入水平持平。

一步一步来，不要急于求成。先想办法达到这个最低要求，养成良好的习惯，以后你们对页面代码的测试和重构会容易的多。

11 楼 baseline 2007-05-11  

贵公司是否也会限制开发人员在写jsp的时候只能用一种标签？因为不同的标签，都用各自的表示方式。如果一个项目到了维护期，界面代码中有各种各样的标签风格，我想也不会是一件好事吧。

10 楼 BirdGu 2007-05-11  

引用

因为所有人都觉得有了css布局，就不再考虑代码的可读性、干净与否、是否结构化良好等等

使页面代码可读性更好，更干净，结构更良好，这些不都是使用CSS布局的出发点之一吗？

9 楼 laochake 2007-05-11  

lkfnn 写道

yananay 写道

冰云 写道

yananay 写道

如果使用css布局，我真的觉得界面的重构不是什么大问题

正是因为用了css布局，重构才成了一个问题。因为所有人都觉得有了css布局，就不再考虑代码的可读性、干净与否、是否结构化良好等等。而这些是应该被时时考虑的。因此才有 界面重构 一说。 并不是让你把界面重新设计，而是说，要保持一个良好的可读的可扩展的界面代码和界面设计。Refactoring --  Improving the Design of Existing Code

作为表示层，难道会那么复杂吗?
只要把相应的现实放入相应的div里，不就可以了。
除非你在页面里混入了逻辑。

赞同，如果页面只是数据展示，把代码写的整齐一点，结构清晰一点，应该没有必要重构。

页面是直接与人打交到的，要让界面易理解，操作方便，效率高，是件很困难的事

而且随着用户的使用，会提出一大堆界面优化的需求的

代码的可读性、干净与否、是否结构化良好等等是界面可维护性的有力保证

8 楼 canonical 2007-05-02  

要重构，首先就要在界面层有良好定义的结构。需要建立一种良好的组件结构

7 楼 hideto 2007-05-02  

太长了，看不下去

6 楼 haha1903 2007-04-29  

非常同意冰云的意见，个人感觉而已。

5 楼 lkfnn 2007-04-27  

yananay 写道

冰云 写道

yananay 写道

如果使用css布局，我真的觉得界面的重构不是什么大问题

正是因为用了css布局，重构才成了一个问题。因为所有人都觉得有了css布局，就不再考虑代码的可读性、干净与否、是否结构化良好等等。而这些是应该被时时考虑的。因此才有 界面重构 一说。 并不是让你把界面重新设计，而是说，要保持一个良好的可读的可扩展的界面代码和界面设计。Refactoring --  Improving the Design of Existing Code

作为表示层，难道会那么复杂吗?
只要把相应的现实放入相应的div里，不就可以了。
除非你在页面里混入了逻辑。

赞同，如果页面只是数据展示，把代码写的整齐一点，结构清晰一点，应该没有必要重构。

4 楼 yananay 2007-04-27  

冰云 写道

yananay 写道

如果使用css布局，我真的觉得界面的重构不是什么大问题

正是因为用了css布局，重构才成了一个问题。因为所有人都觉得有了css布局，就不再考虑代码的可读性、干净与否、是否结构化良好等等。而这些是应该被时时考虑的。因此才有 界面重构 一说。 并不是让你把界面重新设计，而是说，要保持一个良好的可读的可扩展的界面代码和界面设计。Refactoring --  Improving the Design of Existing Code

作为表示层，难道会那么复杂吗?
只要把相应的现实放入相应的div里，不就可以了。
除非你在页面里混入了逻辑。

3 楼 冰云 2007-04-27  

yananay 写道

如果使用css布局，我真的觉得界面的重构不是什么大问题

正是因为用了css布局，重构才成了一个问题。因为所有人都觉得有了css布局，就不再考虑代码的可读性、干净与否、是否结构化良好等等。而这些是应该被时时考虑的。因此才有 界面重构 一说。 并不是让你把界面重新设计，而是说，要保持一个良好的可读的可扩展的界面代码和界面设计。Refactoring --  Improving the Design of Existing Code

2 楼 sunnyshuhai 2007-04-25  

很有新意的idea.

1 楼 yananay 2007-04-24  

如果使用css布局，我真的觉得界面的重构不是什么大问题