共计 1659 个字符，预计需要花费 5 分钟才能阅读完成。
每个项目组的 GUI 开发流程都不太雷同。有些项目组的流程十分落后，根本没有框架设计，都是间接代码设置 UI 控件，不利于迭代。做的比拟好的会采纳 MVC 相干模式进行设计，上面也只讲应用了 MVC 的工作流程。C 由客户端同学负责实现。V 由 GUI 同学进行制作。M 和 V 的连贯工作在现实的状况下应该也是由 GUI 同学进行设置，然而因为上手有些难度，没有很好地落地，所以这块最终由客户端同学进行设置。
总体来看，GUI 开发流程分为以下几个阶段。策动会先提出界面需要，客户端程序须要认真浏览需要文档，确保需要是残缺。因为我之前遇到过策动给出不残缺的需要文档，需要前后矛盾、需要细节失落、需要模糊不清。有一次特地离谱，商城需要文档居然不给出具体的数值设计。在需要不残缺的状况下就开始做性能的工作效率是很低的，须要一边做一边问策动，有时候一个问题要半天工夫策动能力给回答。千万不要在需要不残缺的状况下开展前面的工作，跟策动和 PM 提了之后没有理睬就提多几次。肯定要让策动和 PM 器重后期布局工作，不然前面就会变成策动想到什么就做什么，想到一点内容就加一点内容进入，加到最初发现和后面的货色有点矛盾，又删除后面的内容。这会带来不必要的工夫节约，在极其状况下可能要颠覆重来。
需要明确之后就由 GUI 同学输入效果图。
等策动确认成果之后，客户端同学也要来看一下效果图。看看有没有比拟奇怪的成果，对这些成果进行探讨，确定实现计划或者换成果。如果界面比较复杂，须要跟 GUI 同学对一下层级构造。
进行界面资源输入。一般来说，界面资源输入工作交给 GUI 同学来负责，然而有些我的项目会将这个工作交给客户端同学。已经待过的一个项目组就是这么干的，须要将一张半透的效果图叠在界面最上层，一点一点的拼出来。有时一个界面能够拼一天，眼睛要爆炸，我都不晓得我是程序还是 GUI 了。无论是由谁来输入，都须要留神一下 UI 控件的命名，不要应用 a、b、c、1、2、3 之类的名字。最好能够表白出这个 UI 控件的类型、作用，比方 LoginBtn 代表这是个按钮，点击之后开始登录。客户端同学拿到界面资源之后，首先须要做的事件是查看 UI 控件摆放的层级构造是否正当。层级构造能够依照区域或者功能模块来划分，这么做的益处是能够疾速定位到本人想要的 UI 控件，之后做 UI 资源迭代会轻松很多。个别一个界面的 UI 控件量都不会很少，即便结尾很少，随着性能、成果的迭代优化也会变得越来越多。如果没有解决好 UI 控件摆放的层级构造，做资源迭代时寻找资源会让你狐疑人生的。
UI 界面资源解决好之后，就能够开始进行数据绑定工作了。这个过程须要将 V 和 M 关联起来，个别都会提供可视化编辑工具，不须要写代码。所以这项工作其实 GUI 同学也能够做的。然而因为数据绑定须要对业务需要有更深刻的了解，大部分 GUI 同学都会感觉这不是他们应该做的内容，他们应该只负责输入难看的、满足性能需要的界面。如果能够由 GUI 同学来负责设置的话，客户端程序能够同步开始写业务逻辑代码，生产速度会更快。然而这要做好后期沟通的工作，确保大家对数据的认知是保持一致的，这个沟通的工作可能也要花费工夫。综合来看，这项工作还是交给客户端程序来解决会比拟好。
客户端程序这个时候就能够开始写逻辑代码了。这里须要恪守一个准则，既然都应用了 MVC 框架，就不容许通过通过代码间接操作 UI 控件，只容许批改 UI 控件对应的绑定数据。在实现性能的过程中个别也不能够在批改 UI 界面的款式。如果非要批改，在改变比拟小的状况下能够客户端程序本人改一下，而后让 GUI 同学过去确认下。如果改变比拟大，就间接交给 GUI 同学进行批改。GUI 开发工作整体难度不大，只有踊跃沟通就好。一般来说，如果开发工夫超出预期，大部分都是因为开发过程中呈现了莫名微妙的 Bug，由 UI 框架设计引起。针对这种状况，如果容易修复的 bug 能够间接进行修复。比拟难修复的 bug 能够记录到一个专门的文档中。不便他人遇到同样的问题时能够疾速找到解决方案，晋升整体的开发效率，也作为之后修复 bug 的 checklist。
