在传统的开发过程中，做法多半是：规格=>UI/画面设计=>程式设计。
其实如果专案规划结束的早（也就是实作类似最低可行性产品的概念），并非要等待UI/画面设计完工，才可以进行套版（程式设计）的阶段。
一直以来，我都认为套版是一个非常不友好的说法，造成了偏差的印象。因为一个网站实际上是一整套的软体，并非是画面设计的出来，程式就配合写的出来。双发必须都是要可以执行的部分才行。
程式一定要实际的美术画面被设计出来才能够被接着实作吗？其实不是这样的：只要有wireframe，RD往往可以先行动工。
但问题来了：若双方各自进行自己的部分，那最后要怎么组装起来？
这其实还不是最大的问题。
最大的问题是，其实Art切出来的版，多半是不能被套出来的。
这个问题其实不能怪Art，他们有的是艺术细胞，并非逻辑细胞。而：
不代表能够写出良好的HTML结构与CSS code。这需要一定的经验以及技术实力。不代表这一份原始码，可以被实际使用。有一些Art只懂得PSD to table，整个画面毫无结构可言，让人头疼万分。有一些Art专精制作但也的活动页面，但application需要整套的DOM能够重复利用，CSS一旦被重复使用时大爆炸。在传统的专案进行到套版阶段，程式开发进度会难以掌控的其中一个原因。也是因为：RD面对着一套烂HTML。完全不知道如何下手套进去，不该结构无法让程式运作，或者程式的运作效率会很低；但一改结构，就别想Art再帮你调整细节style和追加细节了（东西被改的不爽情绪或原始结构被改变）。
套版这个过程中无端被追加浪费了大量时间，这也是一个上线前隐藏变因。
多数的application有固定结构的DOM。差异在与<div id="content"></div>内的不同。
至于：
其实多半是相同的。
与其抱怨Art切出来的东西不能被套，不如设计一套general的实际准则可以被大家遵守学习。
不仅仅是HTML设计规则，其实开发当中会花掉很多时间的，还包括一些常见的CSS hack/IE hack。这些也可以被整理起来，结束开发时间（当然现在你只需要学compass就好）。
刚刚有一个问题我们没有被回答到：就是个人偏好如何组合？
比如说：美术的版面里有这样的DOM<div class="article"> </div>,class是article。
但是RD实际的程式码却是post这样的物件名称。
1 2 3 | <% @posts.each do |post| %> <%= post.title %> <% end %> |
这样套起来不是很有问题么？如何实现所谓我说的平行开发？
其实Art/RD双轨平行开发才可以有效的为专案争取到时间。
其实之前的所谓套，因为有完工的时间压力，DOM往往不能够被更改。但是不改DOM又不能让专案继续被执行下去。
若是双方平行开发，又有一个deployable的application让进度透明，所有的修改和沟通调整，只是一下子的功夫（article与post的不同，可以在很早期就被抓出来修掉），不但不会打乱开发节奏，反而会加速专案的进行。