敏捷界面重构

敏捷界面重构 — 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。路还很长。