编码人员和美工的配合问题

公司的项目都是基于B/S结构的，绝大多数操作界面都是通过网页的形式展现在用户面前的，页面的美观就成了非常重要的问题。记得去年的这个时候公司迎来了它历史上的第一个专职美工。同时到来的就是程序员与美工的合作问题。

矛盾篇：

公司以前的系统都是由程序员来编写界面的，美观与否先不必说，单从效率上讲就是一个很大的问题。大部分时间都花在了界面的编写上，严重影响了项目的进展速度。美工到来以后，页面的美观程度和制作速度都有了很大提高，随之而来的程序员与美工的配合问题又成了一个新的问题。其中主要的问题、矛盾有以下几点：

1. 美工何时参与到项目中来

2. 程序员不懂如何将页面弄得美观，美工也不懂如何向页面中添加代码（即使是使用了Velocity）

3. 程序员和美工是两种完全不同的人，他们关心的事情也完全不同，这就导致两种人对页面代码（html）风格的要求大相径庭——程序员要得是简单易懂，美工要得是美观漂亮

4. 程序员要做的是将数据展现在页面上（使用简单的条件、循环语句），美工要做的是将美丽充满整个屏幕（程序员会叫道：天哪！这么复杂，我怎么用if、else、for来实现）

解决篇：

上面的这几点问题和矛盾从关系上来讲是层层递进的，要一个一个依次解决。先来说说美工何时介入到项目中来，在公司做过的这些项目以及我听说过的项目看，大致有以下几种：1）先有美工制作静态页面，完成后程序员直接向页面中添加程序代码；2）程序员随时和美工沟通，向美工描述页面需求，随要随做；3）程序员自己编写测试页面，然后让美工进行美化。

这3种方式可以说是个有利弊。方式1）对程序员来说绝对是个喜讯，它能使程序员最大限度的远离那些烦人的页面编码，提高程序员工作的含金量。同时，一套完整的页面可以展现全部业务的流程，对程序员开发也起到了规范的作用。但这种方式对美工的要求极高，美工要了解项目的需求，而这一般是达不到的。但可以让了解需求的人为其讲解，或是描绘出希望的页面的样式。这样虽然可以弥补美工对业务了解的不足，但也确实花掉了很多时间（而且是花掉了比较重要的人物的时间，因为了解整体业务的一般都是公司的牛人，他们的时间可是一刻千金呀）。方式2）是一个比较折中的方法，这样做无需太多的准备就可开始编码工作，程序员把握页面内容和样式，向美工详细描述，美工再根据描述设计页面，最后返回给程序员添加代码。这个反馈的过程一般比较迅速，效果也不错，可以达到程序员预期的效果，适用于项目时间要求比较紧的情况。该方式的问题在于没有一个形象化的完整的流程可供程序员参考，一切掌握在程序员手中，容易造成对需求的贪污和系统整体风格的不统一。方式3）一般用于对已有项目的美化上，对美工的要求也很高，她们需要具备在html和其他代码混合体的环境下工作的能力。而且修改的效果一般不是很佳，不到万不得已不推荐使用。

问题2.3.4.虽然表现出来的问题各不相同，但解决的方法却很相似。首先，美工要养成一些程序员编码时惯有的习惯，比如：文件命名要有意义、html代码要根据层次进行缩进等。其次，页面代码的一些细节也要注意，比如，使用居中或右对齐标签来取代空格，必须使用空格时也要用“&nbsp;”，不使用<p>标签，尽量使用表格等。再次，如果在条件允许的情况下，美工也可以学习一下夹杂在页面中的各种程序代码，了解其语义和工作原理，这将对与程序员的合作起到很大的帮助的。最后，就是程序员要在向页面文件中添加代码前先对页面代码做一下审核工作，在这里并不是看美工的页面是否美观，而是看在原有页面代码的基础上是否能够使用简单的条件、循环语句来显示数据（比如，页面布局过于复杂，不能通过简单的循环来显示所有数据），否则就需要修改页面代码直到能满足要求为止。