网站上线管理101-第三件:制定Art/RD都遵守的开发convention

收藏文章 点赞鼓励

第三件事:制定Art/RD都遵守的开发convention

在传统的开发过程中,做法多半是:规格=>UI/画面设计=>程式设计。

其实如果专案规划结束的早(也就是实作类似最低可行性产品的概念),并非要等待UI/画面设计完工,才可以进行套版(程式设计)的阶段。

一直以来,我都认为套版是一个非常不友好的说法,造成了偏差的印象。因为一个网站实际上是一整套的软体,并非是画面设计的出来,程式就配合写的出来。双发必须都是要可以执行的部分才行。

程式一定要实际的美术画面被设计出来才能够被接着实作吗?其实不是这样的:只要有wireframe,RD往往可以先行动工。

但问题来了:若双方各自进行自己的部分,那最后要怎么组装起来?

这其实还不是最大的问题。

最大的问题是,其实Art切出来的版,多半是不能被套出来的。

画面不是切的出来就能套

这个问题其实不能怪Art,他们有的是艺术细胞,并非逻辑细胞。而:

  • 能够熟练的photoshop,并不代表能够写出良好的HTML结构与CSS code。这需要一定的经验以及技术实力。
  • 能够切成HTML与CSS,并不代表这一份原始码,可以被实际使用。有一些Art只懂得PSD to table,整个画面毫无结构可言,让人头疼万分。有一些Art专精制作但也的活动页面,但application需要整套的DOM能够重复利用,CSS一旦被重复使用时大爆炸。

在传统的专案进行到套版阶段,程式开发进度会难以掌控的其中一个原因。也是因为:RD面对着一套烂HTML。完全不知道如何下手套进去,不该结构无法让程式运作,或者程式的运作效率会很低;但一改结构,就别想Art再帮你调整细节style和追加细节了(东西被改的不爽情绪或原始结构被改变)。

套版这个过程中无端被追加浪费了大量时间,这也是一个上线前隐藏变因。

解决方法:制作一套HTML/CSS设计准则

多数的application有固定结构的DOM。差异在与<div id="content"></div>内的不同。

至于:

  • header
  • sidebar
  • warning
  • form
  • footer
  • etc...

其实多半是相同的。

与其抱怨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的不同,可以在很早期就被抓出来修掉),不但不会打乱开发节奏,反而会加速专案的进行。

参考文章

评论区