项目回顾：一个开发人员的观察与思考

胡健

项目背景

这个项目的客户是欧洲一家人寿保险公司。该保险公司目前进行的一个计划是对现有的业务流程（business process）和IT系统进行较大规模的改造，以适应新的市场要求。我们的项目是这个计划的一个组成部分，它的目标是建立一个浏览系统与保险公司的后端保险管理系统相连。这个浏览系统用Web浏览器作为用户界面，以取代目前使用的字符终端界面。 2002年初，公司的有关部门（专门作金融服务）曾作了一些可行性研究工作。项目于2002年四月底正式启动，主要的开发工作于10月底结束。然后由另一组人马进行用户接收测试（user acceptance test）。

技术与系统构架

系统采用J2EE技术，系统基本上是三层（3-tier）结构，即Web接口（web presentation），应用逻辑（application logic）和后端服务器（backend）。

系统需求与规范

该项目主要有两种文档提供给开发人员：一种是系统功能描述，由一系列的模块组成。每个模块类似于一个use case，主要给出了该模块需实现的屏幕/窗口（screen shot），并一般地描述了这些屏幕上的操作以及它们之间的切换。这样的模块描述文件在项目中被称之为“故事板”（story board）。“故事板”由业务分析人员（business analyst）会同用户产生。另一种文档是与后端服务器接口的规范说明，如命令格式，数据格式等，由后端系统设计开发组提供。按照项目规定，两种文件都需要经过充分讨论并基本稳定下来之后，由相关负责人员签发（sign off），然后交给开发组。

项目团队与工作地点

项目组有14个开发人员，2个业务分析人员（business analyst），一个项目经理。主要开发组在英国（10个开发人员），项目经理和其余人员则在客户所在地（与英国有一小时的飞行的距离）。

工作笔记

由于工作习惯，我一般每天都作工作笔记。而在这个项目中前两个多月中，我也每周都写一篇小结，主要是对项目运行的观察（所计述的都是对我所在的公司本部开发组而言）以下便是稍作整理后的前十周的小结（略去了公司和人员的名字）。这些笔记可能显得有些杂乱和琐碎，列在这里的主要目的是想忠实地把我眼中的项目进展情况展现出来。

第一周

• 开发组成员逐步聚集到项目组所在地。我们十来个人都坐在一起，边上一个大白板。这种坐位设置非常利于交流，特别是Cockburn所称的“渗透”式交流。各成员的技能方面也各有所专，如Java，EJB，JSP等。
• 项目有个时间录入跟踪系统（time tracker/timesheet）。每人需录入每天所做的任务和时间。这主要用于项目管理，而这些历史数据也是对新任务进行规划评估的基础。
• 这周的主要工作是设置工作环境。每人一个Windows NT或XP 2000作为工作站。我们选用的 IDE（Integrated Development Environment）是NetBeans。选用NetBeans的主要原因是经费问题（NetBeans是开放式源码并免费）。源码控制是用的Microsoft SourceSafe。源码库放在一个项目所用的专门服务器上。而项目的文档材料，如需求分析，系统架构以及开发管理文件，如时间进度表等。
• 虽然项目已决定使用J2EE技术，但具体的系统架构仍然需要建立。初步的选择是一个应用框架（application framework）。这个框架是由我以前参加的一个项目发展而来，我对它的起源和演化都相当了解，因此我也开始对这个框架进行评审（review）。
• 我注意到没有单元测试环境，便开始作一些这方面的工作，因为组里只有我有过建立及使用单元测试的经验。

第二周

• 我建立了一个基于JUnit的单元测试框架，并写了一份2页纸的简短介绍，包括单元测试的概念与实践，以及一种称之为“Mock Object”的技术，因为我认为我们的系统需用到这种技术。
• 本周有一次角色分配。一位精于JSP的同事将主要负责前端（front-end presentation），两位对项目所涉的后端有较多知识并参加过可行性研究的同事将更多地与在客户地点的business people （业务人员）打交道，一位对编码标准（coding standards）有浓厚兴趣的同事负责收集大家在编码方面的问题并执笔编码标准文档，还有一位精于Ant的同事主要做工具开发与配置管理（configuration management），等等。
• 我们的编码标准主要是以Sun Microsystem的“Java Code Conventions”为蓝本。另外，客户要求源码中所有的public and protected methods必须要有JavaDoc说明。一些与我们的特定系统有关的问题，如命名惯例（naming convention），将随着开发进程不断地编入文档中。
• 大家对现有的“故事板”进行的讨论分析，并分解出一些具体任务，然后大家根据自己的角色和兴趣sign up（“认购”）任务并开始设计与编码。
• 关于源码控制与源码库，大家同意每天早上更新自己的工作版本（working copy）。如果要修改或加入文件，在check in之前，一定要保证整个源码能通过编译。

第三周

• 大家继续上周的设计与编码工作。同事们似乎都是Cockburn所说的“good citizen”，工作中人人争先，个个奋勇。
• 随着编码的进展，一个问题开始出现了。我们这里没有后端系统，所以不能对开发的程序进行完整的测试与集成。
• 星期四，项目安排了一次电视会议（video conference），参加者是我们这边的成员与在客户那边的成员。两边的同事通过电视见见面，每人作一简短的自我介绍。然后主要是讨论了当前开发中的问题。最严重的问题包括需求与规范文档没能按时签发（signoff），以及我们这边没有测试环境。

第四周

• 由于客户对我们选用的应用框架（application framework）仍有疑虑，应客户要求，我们公司找了一位有着非常丰富的开发经验的、并且在我们目前所用的应用框架（application framework）上做出过系统的技术权威向客户解答他们的问题。
• 新来的技术权威是位敏捷方法（agile methodology）的热心者，我们在他的建议下准备采用类似XP的过程，首要目标是向客户，也是向我们自己显示出我们能出活（we can deliver）。周一下午，全组开了一个两小时的会议：
  • 确定了要实现的一个很基本的功能，该功能其实大部分的编码已完成。
  • 围绕这个功能，分解出若干需完成的任务，如：源码审查（code review），源码修改， 单元测试，建立“哑”（dummy）后端以作为初步功能测试与集成，找一台空机器以作 系统建造与演示，等等。
  • 大家根据自己的特长与兴趣来“瓜分”把这些任务。
  • 根据每人对完成自己任务所需时间的估计制订出工作流程与进度，以0.5天为一单元。
  • 根据进度表，“交货”时间为下周四中午12:00点。届时，我们需提供一份release notes， 上面将列出系统安装的步骤。按照这些步骤，我们需要：
    • 在一台只有操作系统的空机器上建立运行系统所需的环境；
    • 编译源码并安装系统；
    • 运行系统并演示所完成的功能。
• 因为下周一周二放假（庆祝女王登基五十周年），时间非常紧迫。大家开足马力，开始工作。

第五周

• 尽管大家尽了最大努力，星期四的期限没能完全达到，其主要原因是系统安装上有些没预料到的 困难。但最终在星期五中午完成了所有的要求并进行了系统演示。
• 星期五下午全组会议，主要是对这一周期中的开发过程进行讨论，特别是那些感到最困难的事情。 大家发现以下这些任务花的时间比预想的多：
  • 熟悉应用框架和系统架构；
  • 建立“哑”后端服务系统以作测试环境
  • 建立单元测试
  • 系统安装。

第六周

• 根据上周的讨论，编码标准（coding standards）进行了更新。
• 对第二三周所作的工作重新进行了讨论并制订了新的进度表。这个周期的工作其实包含了 三个use case（或“故事板”），每块“故事板”基本上由两个人负责。其他人则主要完善 单元测试框架及建造“哑”后端系统。
• 本周工作中发现，有一处设计/模型需修改以适应新的功能。多数人被吸引到讨论中并提出 了若干方案。我提出用一种“角色模式（role pattern）”，因为我认为它非常适用我们 现在的情形。

第七周

• 关于修改模型的讨论继续，最后是决定采取一个简单的方法（虽然hacking的味道很重），这主要是考虑到系统的特点和“简单性”原则。（有趣的是，我离开项目组后，有位同事做后续开发，又来和我讨论role pattern，并且决定使用一种更复杂的role pattern）
• 本周的开发工作中也发现了“故事板”的一些问题。因为“故事板”不是精确的规范说明，因此在编码时会遇到一些含糊不确定的地方，需要询问用户或business analyst。
• 由于新的class naming conventions（取名规则），对有些部分的源码进行了重写。这是件很花时间与精力的事情，特别是要非常仔细（据说有些IDE支持这种工作）。

第八周

• 由于发现了一个utility class的潜在的问题，大家同意需要用新的方式来使用这个class，并对现有的源码进行核查及修改。
• 在一个模块的编码和单元测试基本完成之际，最令人恼火的是发现描述这个模块的“故事板” 还在更新，而这个“故事板”在我们决定开始干这个模块之前是已签发（signed off）了的。没有办法，只得重读这块“故事板”，并对源码以及单元测试进行相应的修改。

第九周

• 这周的主要工作是在“哑”后端服务系统是建立新的“哑”功能和数据，以便能对新开发的模块进行“集成”与功能测试。这实在是一件太花时间的活。

第十周

• 非常不想看到的需求改变又来了。又是重读新的需求说明，修改相应的源码。而在与业务分析员的讨论中，又发现我们对一个“故事板”中的一处功能有不同的理解。最后，当然是得根据业务分析员的意见，对源码进行修改。
• 最后，终于作了源码审阅，并根据审阅者的意见对源码作了整理，然后整理出设计文档。把这些源码与文档传给在客户那边的同事们去和真正的后端服务系统连接并测试。

第三至六月

第3－6月基本上是顺着第6－10周的路子走，但也有一些明显的变化：

• 系统调试。建立“哑”后端作测试被认为有些不值得，因为花的时间太多。最后两个月的做法是等一块“故事板”在我们这边完成后（编码、单元测试、源码审阅），派一个或两个人飞到客户那边去待3－5天作系统调试。这样的花销也很大，但客户似乎并不十分在意。
• 源码质量。源码中需“重整”（refactoring）的地方被不断的查找出来并写入到文档中，编码也在不断地增补，源码审阅变得比较正规，并有一份专门的文档。审阅者对源码进行审读后，需列出需修改或进一步说明的地方。程序员需对每一处进行相应的修改或说明，签名后交给审阅者签名确认。审阅的标准主要是编码标准和源码“重整”（refactoring）文档。
• 进度规划。随着开发的进展，对每个新的“故事板”的规划和进度表制订越来越精确。

讨论与思考

下面的讨论将主要围绕一些XP的实践原则展开。

用户在场（On site customer）

尽管开发组的一部分在客户地点，但主要的开发工作却是在公司本部进行的。这里没有用户，没有业务分析人员。这点显然与XP的原则相违背，而其造成的不利影响贯穿于项目始终。首先是对制订计划与进度表的影响。一般来说，在制订计划之前，开发人员需要花一两天读一个“故事板”，然后作出初步估计。故事板简单易读，能使人很快地大致了解一个功能模块的需求。但是，很多地方比较模糊，有些地方在阅读文档中仔细一点就能看出来。这时最好有用户/业务人员在场，马上就能澄清。象我们靠电话和email，时间花的多，还不见得能说得很清楚。

第二个影响要更严重一些。“故事板”中的不确定性有些在读故事板时能发现，而有些就只能到了编码的时候才能暴露出来。由于业务分析人员在客户那边，只能靠电话和email，其质量当然不如面对面的讨论好。特别是当不能及时得到答案而时间又紧迫时，程序员往往得靠经验和“推理”作一些假定。如果是错的话，就只能在功能测试和用户接收测试时再改了。

另外一个类似问题是与后端系统通讯的规范说明，这是由另一个项目组提供。那么我们与他们之间也是有个沟通的问题。而糟糕的是该项目组也是在客户那边，因此只能靠电话和email。总之，我觉得这个项目的实践是从反面证明了用户在场的重要性。

制订计划与进度

如上所言，制订计划和进度表是从阅读“故事板”和规范说明开始。经过若干电话与email的往来后，制订出一个计划，主要是把需完成的模块进一步分解成一些任务，以及估计完成每个任务要花的时间，以0.5天为一个单元。该计划是一个spreadsheet文件，放在项目的文档服务器上，大家随时可查看。

“并行开发”

我们的项目有一点和正规的use case driven的过程不太一样。一般是一个周期主要是做一个 use case。在我们项目中，一个“故事板”大概算一个use case。如在“工作笔记”中所言，在项目走上“正轨”后（从第六周开始），一般是2－3人做一个“故事板”。所以，一般同时可能有两三个“故事板”在进行。每个“故事板”的周期约3－4周。这样做的好处是提高了生产率，但我觉得这样做的前提条件是每个开发人员必须是有足够的经验与技能，还有就是熟悉开发过程（第4－5周的实践是非常重要的）。

单元测试

单元测试是客户的一个要求。在前两个月，我们做还有些“过分”。我们是用NetBeans提供的工具对每个类（class）都生成相应的JUnit测试类（test class）。对一个类而言，其中的每一个 public和protected method都在test class中有对应的一个test method。而这个test method 里只有一个fail语句。这样强迫你用测试来替换这个fail（当然你也可以把它删掉）。结果我们发现花了很多时间去写getter和setter的测试，实在不值得，因为这些methods非常简单。我们因此说服客户，允许我们不用对getter和setter些测试。不过，我倒是发现，对 getter的测试，实际上是在测试相应attribute的初始值。设置初始值常常被忽略，而会在运行中引起一些问题，如最常见的NullPointerException。

单元测试通常要求把被测的对象孤立起来，即测试不要用到其他的类。而实际中，一个类往往要用到其他的class提供的服务来完成自己的功能，最常见的如使用数据库或一个远程服务。单元测试需要切断这种依赖性，即一次只测试某个我们需要测的类。这可以利用Mock Object （“模拟对象”）技术来达到，例如，用一个mock service来代替真正的service，而我们可以很方便地对这个mock service进行状态设置。在我们的单元测试中就大量地运用了这种技术。网上有一些工具可用来帮助产生mock objects，如MockMaker，可以节省一些时间。

总的来说，单元测试的确提高了源码质量。那些逐步建立起来的test cases，我感觉是起到了一张 “警戒网”的作用。源码修改需要作改动时，这种作用特别明显。不过，我们也注意到，对一个类进行完整的单元测试所花的时间往往不少于编码的时间。因此，一个很重要的问题是决定测试到什么程度。XP的建议是对“可能会出问题”的地方要重点测试。但什么是“可能会出问题”的地方则需视具体情况而定。

系统集成与功能测试

由于我们这里没有一个真正的后端系统，因此没办法作真正的集成与功能测试。在项目的前半期，我们曾建立了一个“哑”后端，这的确对我们的测试/调试起到了很大作用。但是，当越来越多的功能加入后，“哑”后端变得越来越负责和不可维护。最后，我们只得放弃这种做法。

项目的管理层曾作了很大努力，想使我们这里能直接连上客户那里的后端系统，这在技术上是完全没有问题的（毕竟这是网络时代）。但不幸的是，这个合理要求没能得到满足。所以项目后半期，当一个“故事板”的的编码与单元测试完成后，一般由编码者或测试者飞到客户那里去做集成与功能测试。

结对编程（pair programming）

在我们这个项目的实际中，pair programming与“传统”上的意义有些不同。首先，因为我们坐得都很靠近，如果某人有什么问题，只要一叫，一般就会有人跳起来跑过去帮忙。这可算是一种 “基于解决问题”的pair programming。

另外一种更主要的是方式是编码与单元测试的结对。由于测试者对于如何使用一个（待测试）的类一般不会有着与编码者完全一致的思路，这样对于发现问题是很有帮助的。另外，由于测试者一般都会在测试时详细阅读源码并与编码者讨论，这对于改进一个class的细部设计与实现也是很有用的。但这种审阅与源码有所不同，这里主要是着重“逻辑”的正确与有效，而源码审阅则偏重于源码的风格与标准的统一。

还有一种方式可称之为“结对排故”（pair debugging），我发现这种情况多在系统功能测试中出现。如果在测试中出现一个问题（bug），找来找去找不到（因为这时涉及的东西的较多），搞得昏头胀脑。那么最好是抓一个同事到屏幕边上（最好不是和你搞同一个部分的），然后给他讲讲是怎么回事。他可能会一眼看出问题所在（如果他曾遇到过类似的问题），或者会从另一个角度来提供一个思路。另外，常常也有这种情况，来帮忙的可能只是听着，而你在讲的时候可能就自己发现问题了。我想这是因为你在给其他人解释一件事的时候，你实际上是在强迫你自己清理自己的思路，而这肯定是有助于找到问题的（特别是在昏头胀脑的时候）。

编码标准（coding standards）

项目开始的时候，我们就决定采用Sun的“Java Code Conventions”作为我们编码标准的蓝本。随着项目的进行，大家不断地讨论并同意加入一些与项目有关的标准，例如：

• 所有的classes和所有的public and protected methods都必须要有JavaDoc注释；
• 对于packages,classes,variables的命名标准；
• 如何使用集合（collection）类型，如变量的类型需是interface，如Map而非HashMap；
• 如何使用实数类型，如规定用double而非float；
• 如何使用logging（我们使用log4j）；
• 如何处理exceptions，等等

源码审阅（code review）

源码审阅一直是项目的要求之一。但在项目的前半期，这点做得不是很正式。当然，一个主要的原因是大家想尽快地做出一些功能。这样造成的一个后果是源码开始有些杂乱并且不一致。项目后半期开始比较严格地进行源码审阅，并且规定一个“故事板”的源码在进入系统测试之前一定要有正规的源码审阅。

进行源码审阅时，审阅者一般是根据编码标准上所列的条款对源码进行检查，看是否符合标准。同时，也可对一些具体实现上提出自己的看法。这些意见用一张专门的表格一项一项地记录下来，交给编码者修改或给出进一步的说明。最后，审阅者对源码复查，对每一项进行核对，满意之后签字认可。我们的经验表明，这样的源码审阅大大地提高了源码的质量以及可读性和可维护性。另外一个作用是使refactoring得以经常及时的进行。

源码重整（refactoring）

我们项目里，refactoring基本上是与编码标准和源码审阅同步进行的。项目的前半期，基本没有refactoring，尽管有些不好的码段或实现被不断的发现并记录在案。当然，主要原因还是由于大家想集中精力先做出一些功能。在项目的后半期，开始和源码审阅一起较严格地执行。和源码审阅一样，这样做的结果是大大地提高了源码的质量。

以上这些就是对这个项目的一些观察与思考。总之，对开发人员来说，这个项目有许多的不确定性，这主要反映在需求与规范文件上，也反映在相关项目组之间的协调（或扯皮）上。项目组分散两地，测试环境的缺乏都是开发中的很大问题。在这种情况应用XP的实践原则，如密切沟通，单元测试，源码审阅与重整，能有效的（也许是艰苦地）推进项目的进展。

后记

记得几年前曾看过一篇文章是讲中国的MBA的教育的。大意是说工商管理是个实践性很强的专业，做MBA的一项主要工作是做大量的个案分析。而目前中国似乎还没有足够的个案，有待于现在的MBA们毕业后在工作中去积累。这些积累起来的个案将是今后MBA们一笔宝贵资源。由此想到软件开发，何尝不是如此。软件开发是个实践性很强的群体/团队工作，这点从三十几年前“软件工程”的提出时，人们就已经认识到了。提出的方法也是层出不穷，但真正在实践中运用的并不多。这几年出现的以XP为代表的agile方法兴起，主要原因就是在于它们是从工程实践中提炼出来，而其可行性至少在一定条件下或范围内又为他人的实践所证明。那么我觉得现在最重要的不是高谈阔论，而是扎扎实实的实践，即在了解这些原则后如何在工程实践中加以运用。更进一步，如果能把这些实践记录下来，加以总结，这对自己和同道都是一件好事。基于这样的想法，在下不避琐碎，把自己对一个项目的观察与思考写下来，期望能抛砖引玉，看到更多的同道能把自己的经验写下来，与大家共享。

修改记录

• 2003年6月：修订个别段落与用词。
• 2002年11月：初稿。

胡健
Email: jian4_hu2@hotmail.com
Web: http://members.tripod.com/jian_hu

转自：http://dev.csdn.net/Develop/article/28/61820.shtm

By Susan Villecroze
January 26th 2005
The translation is Last modified by Starlight in 1/31/2005 PM

写在译前 : Web 设计和开发是设计还是编程 ? 多年来我只是业余做一些 Web 开发 , 关于设计我是半懂不懂 ( 无论是页面布局还是 FLASH 和图形图像设计 , 但我现在已经向 Web 页面标准布局过渡 …), 所以目前我仅是业余的 Web 开发人员 .

现在 , 客户需要什么样的 Web 设计师 , 你符合 Web 设计师的要求吗 ? 客户如何鉴别和雇用适合自已的 , 优秀的 Web 设计师 ? 在 Susan 下面的文章中 , Susan 将解答这一切 .

Susan 在北美的范库弗峰为 hexaZen 做网站设计和 Web 开发 , 很早她就取得了物理和天文学的学位 , 但 Susan 更喜欢设计 Web 页面 , 这就像解答复杂的微分方程式一样有趣 .

今天 , 任何一个人想要发布信息 , 销售买卖 , 共享信息或者促进商务 , 借助于 Web 完成并表达这些所想是一个不错的方式 .

一个慈善机构可能想吸引更多有潜在的成员和志愿者 , 与此相同 , 某个机构要发布一些相关的时事通讯和文章 , 那当然必须要让每一个人都能知晓该机构 . 又比如 , 一个攀岩中心会显示一张方向指示图 , 借助于这张图你就能到达中心地点 , 在攀岩的技巧方面你还会得到一些暗示 , 提示在哪里可以找到更好的攀岩器材 , 一组关于攀岩的图片画廊还会向你展示攀登的动作 … 不同于其它的市场策略 , Web 站点可以全方位且 24 小时不间断地达到这些目的 .

如果你想拥有这样的一个 Web 站点 , 而你又不是一名 Web 设计师或开发人员 , 你该怎么办 ? 你不可能有很多的时间去学习 Web 设计并达到骨灰级的 Web 设计师的水平 , 同时你也不必抱太大期望你的兄弟姐妹有能力学习计算机 , 有足够的经验可以帮你建设专业级的 Web 站点 . 因此 , 你需要尝试着雇用一名 Web 设计师来帮助你完成这些 , 雇用谁呢 ? 范围很大 , 从单个自由设计师到大的 Web 设计代理处有数千名 Web 设计师和开发人员可供你选择 , 但是你如何确信你所选择的是你真正想要的 ?

你想做什么 ?

为了找到合适的 Web 设计师 , 首先你需要盘算一下你究竟想要做些什么 , 问一下自已 :

• 你想在这个站点上做哪方面的信息 ? 想一下你的你的站点空间可能会多大 ?
• 你的用户是谁 ? 你知道这些用户的使用操作系统和浏览器是什么吗 ?
• 你的站点需要定期的更新吗 ? 你希望由自已完成这些更新 ?
• 你愿意做销售物品的事吗 ?
• 你需要一个数据库存储和恢复信息吗 ?
• 你想借助于搜索引擎促进你站点的访问量吗 ?
• 你需要完成站点建设任务的大致时间是 ?
• 对于站点建设你的预算是多少 ?

调查开始

谁能够发现一名好的 Web 设计师 , 其自身通常也是一名好的 Web 设计师 , 至少他 ( 她 ) 会做一点儿 Web 设计 . 尽管如此 , 他 ( 她 ) 毕竟仍然非 Web 专业设计师 , 因此 , 选择一个专业的 Web 设计师似乎是一个无法避免的任务 .

被提名的人通常是比较可靠的 ; 尽管你知道你目前不可能在市内寻得一个最好的 Web 设计师 , 但你要相信这还不是最坏的 , 被提名的人出现在你的 Web 设计师列表中 , 一旦完成这个列表 , 你需要进一步做一些认真的考虑 .

如果列表中的一些设计师不在本市内 ? 如果你真的喜欢他们 , 请不要介意 , 你可以通过 email 或电话方式与他 ( 她 ) 联系 .

在评审潜在的 Web 专家列表时 , 有一些事情需要考虑 , 首先 , 显而易见要做的是检查他 ( 她 ) 们的 Web 站点 , 作为你能够做的是查找关于列表中这些人的更多信息 . 这个过程中 , 你问一下自已 :

• 查找信息容易吗 ? 回到起始处容易吗 ?
• 你喜欢导航系统吗 ?
• 页面的易访问性 ( 包括没有死链接 )?
• 全部页面的设计是否协调 ?
• 联系页面和站点地图能够很容易找到吗 ?
• 在站点上有足够相关的信息吗 ?( 关于公司的地点 , 公司从事什么 , 公司人员 , 政策等等 )
• 一些事物的排列适当吗 ?
• 文本容易阅读吗 ?
• 页面能很快地加载 ?
• 页面尺寸较短 , 因此不必要水平滚动条 , 并且仅有一点或根本没有垂直滚动条 ?
• 点击链接打开在同一页面上 ?
• 能够查阅到设计草图吗 ?
• 站点上有否谈及这设计师的技术背景 ?
• 站点上的颜色搭配如何 ?
• 页面标题适当与否 ?

上面的问题如果答案全部是 yes, 那就有希望了 . 如果你不喜欢 Web 设计师的站点 , 你也许就不会想让他 ( 她 ) 们来设计你的站点 . 检查他 ( 她 ) 们的设计草图风格看是否真的符合你 . 如果你真的喜欢这站点 , 再确认一下这名设计师 ( 或多名设计师 ) 可以长期的雇用并建设你自已的站点 . 这名设计师用的是采用什么技术设计站点 ? 这技术符合你的要求吗 ? 设计过程中遵循 Web 标准吗 ? 嗯 , 再完美些 , 让你的站点能够正常运行并不依赖于用户的操作系统和浏览器 .

在设计你自已的站点过程中 , 这些设计师还为另外的商业站点设计吗 ? 如果是这样 , 他 ( 她 ) 们可能会恰当地表现这个商业站点吗 ? 如果是 , 他 ( 她 ) 们应该已经能够知道你的站点需要什么 , 并且你需要这些具有更多的专长的设计师 . 如果这个商业站点提供了一些推荐书 ( 关于这些 Web 设计师的 ), 看一下过去的客户评价 . 附带的还有一些技巧 , 设计师应该继续深造以保持自身的技术和标准永远是最新的 .

要小心更多的公司或个人所声称的 Web 设计和开发仅仅是局限于图形设计和打印设计方面的工作 . 仅仅会用一些创建 Web 站点的软件 ( 诸如 Dreamweaver) 的人还不能算作是一名 Web 设计师 . 作为一名真正的 Web 设计师至少还应该能帮助你 Web 设计和开发 , Web 主机管理 , 图形设计 , 数据库设计 , Web 内容 , 维护站点和站点在 Internet 的市场以及站点的发展 .

自由设计师 vs. 大型 Web 设计公司

按上面的方式评估和选择后 , 你可能需要在有魅力的自由设计师和大型 Web 设计公司之间作出选择 . 一个大型的 Web 设计公司看起来有更多的可信度 , 这归咎于它的大型设计草图 , 许多证书 , 以及收集了许多专业设计人员在很多地区的设计案例 . 这些专业设计人员在一起工作 , 为客户提供一个所有 Web 页面设计一致性强 , 成功的 Web 站点 , 此外 , 大型的 Web 设计公司的服务也会使客户感到非常满意 .

个体的自由设计师们一般都具有全部所必需的设计和开发能力 . 他们经常配合地工作 , 在少数的几个人之间互相协作 ( 在一些案例中 , 甚至只有一个人 ), 这意味着保持所有 Web 页面设计一致性是很容易的 . 独立的或在一个小组中工作同样可以产生巨大的潜能 , 这些都确保了客户的满意度 . 他 ( 她 ) 们设计的样例将产生所见即所得 (WYSIWYG) 的效果 : 专业的自由设计师正如你在 Web 上所接触的一样 , 他 ( 她 ) 们将是为你设计站点的专家 . 与大型 Web 设计公司相比 , 一旦站点建设完成 , 即使一个完全不懂 Web 的门外汉都可以很好地管理这个站点 .

自由设计师们同样在价格和价值上更具有优势 . 使用一名自由设计师 , 你可以省去很多不必要的酬金 , 在站点设计和开发之前也不需要复杂的合同条约 . 如果你需要的话 , 自由设计师还可以为你的站点做更多的事情 .

根据你站点的规模和复杂度 , 一个大型的代理公司可能是比较好的选择 , 在建设并交付大型站点的速度更快些 , 这方面它比个体的自由设计师要做的好 . 个体自由设计为了尽快完成设计和开发工作 , 经常会将设计任务进行转包 , 或者在设计和开发过程中必需学习几个特殊的技巧或技术 . 这可能意味着需要额外的时间或额外的支出 , 并且 , 依赖于有关的自由设计师 , 设计结果可能比专业的设计要差些 , 例如 , 如果站点的设计和开发需要使用某种特殊的语言或技术 , 这就需要寻找有专攻这方面的设计师 .

价格和担保

进一步在可能的设计师列表中挑选出优秀的设计师人员 , 你要注意一下他 ( 她 ) 们的服务级别 . 设计师的价格会将他 ( 她 ) 们的服务列出 , 可能会有很大的差别 . 比较服务级别可以从各设计师之间的教育培训级别 , 经验和能力进行考察 . 像花钱买东西一样 , 现在你要花钱雇用 Web 设计师 , 如你所想正是 : 付了多少钱你就应该得到多少 . 如果站点相当的小 (' 小 ' 意味着站点仅需要很少的表单和数据库 ) 并且设计和开发也是非常的直接简单 , 雇用自由设计师的负荷会比雇用大型的 Web 设计公司要小得多 .

一旦你缩短了这份设计师列表 , 不知不觉你就陷入了公司或个体都关心的问题 , 阐述一下关于你的站点 , 咨询一下实际报价 . 确信你的设计师可以描述清楚所有的成本 , 并且在细则内为你工作 . 如果你有问题 , 不要害怕询问 , 请记住 : 如果你感到报价不是很恰当 , 你就应该商谈一个较低的报价 ( 这并非是不切实际的商谈 ).

如果有必要 , 同样可以考虑一下与雇员签订一份合同 . 这样你在这份合同下会受到应有的保护 , 当然还要确认版权和付款方式等问题 .

寻找并且要求一份工作的担保 . 定期的策略诸如 , “ 如果你不是 100% 满意这份工作 , 你离开后我们将会支付你一笔遣散费 ”, 或者 ” 我们支付的薪资是具有竞争性质的 , 如果你嫌少并找到一份相类似的工作 , 我们将乐意你的选择 , “ 这些担保说明会给受雇的设计师一个清楚的概念 , 并且这也是你所需要的 .

担保意味着被雇用的设计师是否能高兴的做事情 , 同时 , 这也保证了你的站点建设的成功率 .

最后步骤 : 联系和检查证明

当你确定仅留下几名设计师后 , 这时还要联系他 ( 她 ) 们并检查一下他 ( 她 ) 们的相关证明 . 首先 , 向他 ( 她 ) 们问一些问题 , 他 ( 她 ) 们在电话中是否礼貌 ? 认真听 ? 确实对你很有帮助 ? 如果他 ( 她 ) 们与你交谈不畅 , 并且你也不喜欢用请客的方式交谈 , 那么你会与他 ( 她 ) 们在一些工作会显得比较难处 .

你可以去每个即将受雇设计师的站点查一下的他 ( 她 ) 们的相关证明 , 并且有可能的话可以接触一下他 ( 她 ) 们过去的客户 . 如果没有查到相关证明 , 你可以直接电话联系她 ( 她 ) 们 . 既然你要雇用人员 , 那么你就要仔细地检查他 ( 她 ) 们的工作背景 .

最终 , 你会会见即将受雇的设计师并谈一下你对站点建设的一些想法 . 在这点上 , 你没有什么义务非要雇用他 ( 她 ) 们 , 除非你很确信他 ( 她 ) 们会为你工作 .

值得做的工作

上面的步骤 , 会使你成功地找到并雇用一名 Web 设计师或开发者 . 这个过程可能会比较繁琐 , 但是当你花费了数千美元后 , 许多年后 , 你再回过头看一下 , 这样做还是很合算的 !