再读《你是一个职业的页面重构工作者吗?》

张大晴 2012-06-01

这段时间常给来面试的同学用《 你是一个职业的页面重构工作者吗? 》中三个部分的不同阶段去做自测,发现很多人都自我感觉良好,给我的回答基本都是比较高的,只不过实际上提交的面试题所反应出来的并没有那么高。我总结了下,主要有3点:

  1. 对自己的能力没有足够的了解,没有实事求是的认清自己
  2. 存在侥幸的心理,希望以较高的答案赢得面试的机会
  3. 对文章里每一点的理解存在偏差

简单做下说明:

  1. 对于我们来说是很重要的,只有真正的认清自己的能力,才能知道自己还有哪方面的不足,才能有针对性的提高自己。
  2. 就是人的问题了,这里也提醒下各位正找工作的同学,正直、诚信,是很多公司十分看重的,也是做人很重要的品德。我不会因为你没有达到文章中的要求而不给面试的机会,但会因为不正直而扣分。
  3. 也就是我决定写这篇文章的原因了。在文章的讨论中gulu77提到希望能为每个阶段写一篇详细的文章,之后就在想可能需要写一个更详细的说明,当初不想把每一点写得太细,是担心可能会变成误导,毕竟有些地方我有自己的想法。直到在 Webteam 中发表了这篇文章后,很多人对里面的点有疑问,让我觉得现在还不用担心误导的问题,因为根本就没能明白我想说什么。

写《 你是一个职业的页面重构工作者吗? 》的目的是为了帮助暂时找不到方向的同学,所以在读的时候对自己更诚实些,相信会得到更好的效果。

一 设计稿的分析

  1. 能分清设计稿中的公共与私有的部分

    从最基本的开始,分清公共部分如菜单、导航、大框架和每个独立页面所用到的部分等,至少在想法上做不同的对待。

  2. 在1的基础上对各部分的实现方式有一个初步的方案(包括如何切图、写结构、写样式)

    在分清公共和私有部分后,分析最简单的实现方法,如哪些部分是可以平铺的,哪些是可以重复被使用的等等。

  3. 在1的基础上,准确的给出各部分的实现方案(包括如何切图、写结构、写样式)

    在分清公共和私有部分后,能准确的给出各部分的实现方案,如“滑动门技术”的实现方法有2种,选择哪种方法更合适项目?图片应该如何切?应该使用哪种HTML和CSS的写法?

  4. 在3的基础上,能同时考虑方案的扩展性、复用性及页面性能(包括如何切图、写结构、写样式)

    在给出的方案中考虑是否可扩展、如何重复使用、将哪一类的图合并可以最大化页面的性能。这里还要注意有些模块的内容可能是动态的,当内容改变后如何兼容。

  5. 在4的基础上,考虑整站的结构分布(包括文件分布、目录结构)考虑上面方案的综合效率,如维护所需要的成本、页面打开速度、带宽成本、服务器开销等等。

1~3点应该成为基本的技能,4~5属于更高的要求。这块的熟练度会影响到后继切图和写代码的效率、返工的机率及维护成本的高低。

二 切图

  1. 切成所需要的图片(如何将需要的部分切出来)

    最基本的,将需要的图切出来,有时候会需要PS出自己需要的图。

  2. 在1的基础上,对切出来的图片进行一些优化(包括压缩文件大小、选择图片类型)

    压缩输出的图片,在不影响画面质量的前提下,尽可能的减少文件字节数。这个工作很重要,优化一张图片所带来的效果可能比优化很多的代码所带来的效果要明显得多。

  3. 在2的基础上,规划切出来的图片(包括文件分布)

    规划切出来的图片,哪些图应该被合并,存放于哪个目录等等。

  4. 在3的基础上,考虑整体的性能(包括合并图片、压缩文件大小)同样是综合整体的性能、效率。

1~3点应该成为基本的技能,4属于更高的要求。这块会影响到HTML和CSS的写法,还有页面的性能(流量、链接数)。

三 HTML和CSS的编写

  1. 还原设计稿视觉效果,并通过标准验证(HTML)

    还原设计稿,是页面制作最基本的要求,不管设计稿是否符合自己的审美观,做为页面重构工作者,还原设计稿是一项职业素质。通过标准验证是检验我们输出的质量很重要的一个方法。虽然最终的页面不一定可以通过验证,但我们所输出的静态页面大部分是可以做到通过验证的,除非有特殊的需求。当然我们不是为了过验证而做页面,是为了标准化。

  2. 在1的基础上,实现多浏览器的兼容(HTML)

    兼容多浏览器,要实现多浏览器的兼容,少不要了解下各浏览器的习性。不过对于什么才是兼容,在《中国式WEB标准》中有讨论。

  3. 在2的基础上,标签语义化(HTML)

    标签语义化,是WEB标准的核心内容,只有做好了语义化,才能说得上做到了WEB标准。虽然在国内很重有统一的标准,不过一些基本的语义标签的使用还是可以定下的,如段落、列表、表格等等。

  4. 在3的基础上,选择较优的实现方式(包括模块化结构,方便程序脚本使用,HTML和CSS)

    做好了上面3点,只能说单一的页面做好了,下面得考虑两个以上的页面了。模块化就是为了更好的提高复用,减少重复开发所带来的浪费。模块化也是被越来越多的人所关注,可以说是发展的一个趋势,随着大家对HTML和CSS掌握越多,如何更好的发挥它们也成了提高工作效率的重点,其中模块化就是很好的一种方式,打算在之后写相关的内容(时间不好确定)。

  5. 在4的基础上,考虑到扩展性、复用性和可维护性(HTML和CSS)

    做好了模块化,并不一定就是最优化的,如果考虑上扩展性、复用性和可维护方面的内容,模块化有时反而会不利于这几个方面,如何平衡这几方面,是一个更高的要求。

  6. 在5的基础上,考虑到整站的样式分布(包括如何实现分布)

    这个算是整站的规划了,需要多少个样式,多少个目录,这些样式文件分别存于哪个目录(当然同时也需要考虑图片的分布)

  7. 在6的基础上,样式写法的优化(包括技巧的应用)这点需要跟上面的第4、5、6点结合,需要做综合的考虑,使用更合适于项目的样式写法。

1~3点为基本的技能,4~7属于页面优化方面的内容。这块影响了一个页面甚至一个站点从无到有、从有到优。掌握好各个点的知识,会让页面在越短的时间内达到最优的状态。当然这也是个人能力的体现。

Rock在 Webteam 文章中的评论十分精彩:

“即设计师给三天的时间,制作只给一天的时间完成”

这一点我有些微言。呵呵,我觉得有些不现实。除非是非常专业的团队,虽然说通常都是这样的流程,但现实来讲:

1.很多设计师不具备模块化的思想,(即使有)通常设计出的稿子也是公用元素太少。往往现实的流程上3天设计师可能做出3个以上的设计。以及“产品经理/策划”无计划的修改。扰乱你的进程不说,还会对你的现有结构(html)产生更改,比如这个加个下一页链接,这个头像上悬浮一个什么图标。这都是很现实的问题。你的结构和你的css会因此看起来很不堪。

2.设计上对自己的要求不严格,通常会有1px-10px的差错,因为我做页面的时候每1px都会很计较,因为没有相应的规范,所以我都是在设计稿上量来量去,会发现很多的问题,因为如果不这样做,上级会认为你工作不认真,1-2px的padding甚至都会影响你的工作成果,在这个问题上我经常会和设计师们沟通很久,通常也会很不满设计的粗糙。

3.高质量的切图与psd/png文件的规范性,这也不得不提,从事这个行业毕竟会遇到各种各样的这类问题,有些psd文件会很规范,分组清晰,栅格化合理,图层混合方式不影响大局栅格化的效果,这些因素都会影响你的切图质量和效率。

4.浏览器的兼容性,这个问题不大,只要做的够久就会知道哪些浏览器的哪些特征,但往往特殊的需求还会使你在ie6上痛苦一番。代码洁癖的你是否愿意结构hack和多层嵌套的html,鱼与熊掌不可兼得,想要更加通用,你需要更多的嵌套和更多的class,想要完美,就意味着随便一个改动就破坏你的平衡。

5.与程序的合作,通常很多程序员也不具备这方面的知识,也就是说,你交给他的模板,等他套完程序,可能完全就是另一套模板了。而最遗憾的是,公司可能并非使用SVN或VSS等源代码管理系统(一种节省成本的方式?),你没有管理模板的权限,你的权限仅限于图片文件夹和css文件夹。仅此而已。程序每套错一个地方,你要花时间去排错。可以说,这个成本很高。

一点个人见解,工作效率的决定因素究竟取决于什么,团队中每个人的专业性

呵呵,我觉得楼主在这些方面太过理想化了,其实我更想这样的操作方式。因为那真是太节省时间和成本了。但现实是完全不同。

从现实的角度说出了大家或多或少遇到的问题,Rock所说的问题的确存在,我也都遇到过,甚至目前还有。设计师和程序员不具备相关的知识的确是一个很大的问题,当然还有领导的重视程度和项目成本等原因。

从WEB标准开始在国内推广算起,差不多有三年半的时间,到现在才有多少同行真正的认同它、学习它、使用它?相信大部分人都还处于“别人都这么做,我也得学学”的状态,更别说是设计师、程序员了。为此,帮助他们认识到标准的好处,如如何使用标准提高工作效率、减少工作压力、减少成本等等,只有他们接受并使用标准,Rock所说的情况才会有好转。要影响、帮助别人,自己就必需先提高自己的能力。做技术的人大都有个特点:有代码洁癖、对自己写的代码要求严格、追求完美。其实很多人并没有一个标准,会这么写往往只是因为自己喜欢,所谓的代码洁癖、严格,都是以自己的喜好来决定的,对个人来说可能算得上是特点,但对项目来说却十分不利,可以说是一种片面的完美。

很少项目是可以一次成型的,也就是说大部分情况下并不完美,修改是少不了的。如果在前期的规划中就没有把这些修改(扩展、兼容)也考滤进去,后面必然会给带来很多困扰。当然扩展和兼容的考滤是在合理的范围内尽可能的支持,并平衡与性能间的矛盾。如何让产品经理、设计师、程序员去减少无理的、不必要的需求、修改,把修改变得可控,这些已经不只是页面制作的内容了,有兴趣的同学欢迎再讨论。

相关推荐