大规模互联网产品的网页制作经验分享

想说下怎么做好比如新浪博客这样一个规模较大的互联网产品的网页制作，这个事情看起来很简单，开发leader会说，作为builder，快速提供优质的静态页就好了，可怎么做才能把这事做的漂亮，方便开发又易于后面需求变更和维护，我们先从文件夹部署开始说。

文件夹部署这事可小可大，一般builder都会划分为css、images等几个不同的文件夹，或者把样式图片放到一个文件夹里，每个人都有自己的习惯，先给大伙看看我们定的

四个文件，样式，图片，皮肤，预览页面都独立放置，当然里面的子文件夹有规定，这个下面会提到，为什么这么做，先列四个好处，更多的优点，这篇文章里会穿插提到

• css和images文件独立，方便一些特定情况下css和images包分别部署
• css和images文件相互联系，可以打成一个style包部署
• 本地相对路径跟线上保持一致（避免开发调试过程中需要反复上线修改绝对地址）
• html静态文件预览清晰
• 方便开发和上线svn

前面几个好处跟开发过程中的代码控制都有关系，重点说一下svn吧，我们知道：在一些项目里面涉及的前前后后的开发工程师比较多，必须用svn等版本控制工具进行代码管理，也方便配合上线部署。

而作为页面工程师来说，预览不需要环境（不管是本地配置的localhost还是服务器环境），我们修改一个css属性，都可以直接用浏览器刷新一下，相信大家在学校，或者在做一些规模不大项目，比如小型企业站的时候，一般采取的方式是：在本地开发完毕，然后找到服务器在哪，ftp传上去就是了。这个时候的流程就是

本地开发>>>>>服务器
这个事情如果把svn引入进来，就有点麻烦，因为大家再开发中，svn不光是代码控制的工作更是控制部署的重要手段。

本地>>>>>svn上传>>>>>部署到前端服务器
有些工程师会有自我保护心理，他感觉直接在svn文件夹里写代码会跟别人有影响，不安全，会在本地还分了开发，和svn检出两个文件夹，那这个流程就复杂成了
本地开发>>>>>（复制到）本地svn文件夹>>>>>svn上传>>>>>线上部署

这时候熟悉svn的同学会想到很多问题（这儿就说其中两点）
我们知道，在一个典型的svn结构里面分……三部分trunk tags branch，页面工程师写的东西因为有预览静态页面这个在线上用不到的东西，所以不能直接扔到svn的这些文件夹里，这样的话对我们如果把css image skin放到trunk，html预览文件放在外面，遇到一个问题，就是我们的文件相对结构乱套了！！换句话说，我们不能在写到页面里的img路径里面加上../../trunk这样的东西。
而且实际工作起来，流程也会出问题，一般情况下，开发的部署可能会滞后，我们在看到设计稿雏形的时候就要准备静态页的结构和css框架，但这时候开发工程师要做的是数据库等更深层次的部署，我们不能等他们把开发过程中文件的部署上线流程都定好再开工，这显然是不合适的。所以实际过程中会有两个svn（我们的静态页svn和真正的控制打包上线的svn）

说到这，肯定有人会问，我们把页面放到项目的svn下不行吗？先不说是不是合适做不同产品间的代码管理，即便放到项目下，为了避免影响，开发leader会指定一个比如“html”的文件夹供builder用，这其实还是跟控制打包上线的svn是两回事
第二个问题，我们在本地开发，只把css和images真正需要的东西传svn不行吗？这个问题……那我们的静态页不需要做版本控制了吗？

所以，我们不得已，在svn有个放html、css、images这些文件的地方，为了不同项目间的代码管理，放在了一个单独的svn库下，我们称之为builder svn，这样，刚才的流程就又加了一步
 
一段代码，一个文件，从开始写到最终上线（也可以指测试机或开发机……），到要复制四次，太恐怖了，在反复测试的时候不出错才怪。所以我们要做些事情：

1. 本地开发和builder svn的检出文件夹放到一块
2. 自动关联buildersvn和svn上线库
3. 让工程师帮忙，把部署这个事情简单化，至少在往测试机或开发机部署的时候简单的只需要做一个f5
那事情就简化了

 
前面提到的第二点，可以用svn的映射来实现，如图

而且有两个方案，一个是从buildersvn往上线svn库映射

但这样有个问题，因为在上线库里存的只是一个链接，在打包上线的时候都取不到版本号，不利于上线后的回滚等事情，我们只好反过来做

这样虽然还存在一些权限设置麻烦等问题，不过好在解决了上线的根本问题

部署方面还有更复杂的情况，比如在一和大项目下，不同的模块是不同的开发小组，甚至不同的上线库！！
这就涉及到我们刚才二级文件夹的部署，在这个层面，我们要做几个事情：

1.css和images文件夹下明确common下的东西
2.css和images文件夹的子文件夹，同名的文件夹联系紧密，不同的文件夹之间相互独立（见下图，css和图片的引入不能有超越红线的交叉）
3.skin虽然下面也有子文件，但部署的时候一般是打包一块做的，做好映射即可

把前面这些事情定好，作为builder工作效率可以高很多了，不至于在后面的开发中为这些事情挠头

部署做完，我们就可以做具体的事情了，先说说html文件，这个预览文件做出来无非下面的三个用处

1.我们自己开发
2.产品或设计师看效果
3.工程师开发时作为参考

先说文件本身，因为这个不会上线，我们开发只是在本地，跟服务器环境没关系，为了方便后面两个需求，建议所有的文件名写成汉语，文件名跟设计稿或ue原型图里面每个页面保持一致就可以了。另外，html的子文件夹也跟css等文件夹下的子文件保持一致。具体代码里面除了注意 DOCTYPE和编码（我们一般是用utf8）比较重要的一点就是css的引入了：

1.前面说到，文件夹部署里面有个common，这个是公共文件，首先引入
2.其次是引入自己页面或模块相关的css，就是第一部分里面提到某个文件夹它应该跟其他是相对独立的
3.如果后面有皮肤的话，引入skin文件

这个顺序是我们整体架构的一部分，必须严格执行。前面提到，html中要先引入common这个公共文件
这这个css里面分几个方面：

1. 清零

这次主要说部署和开发流程的事，所以清零这部分的技术细节不在赘述，但有个策略需要周知，就是（所有产品尽可能保持一致，升级或者打补丁要慎重，多人协作的话要提出来让大伙周知）
2. 通用的class类,包括下面几个方面

大家都会用到，或有必要在全局里指定，属性单一
比如：chear float wordwrap
文字色，链接色（类别化，不要语义化）
其他，由架构师和项目组共同确定
不建议的东西
比如f14，f12，fsun，p10，pt20，m10等属性
这些有个共同点：具体属性很具体的某个值，或者跟其他重复，是语义化的定义方式
不建议的原因：会造成下面模块化不彻底，不同人之间的维护费劲

说到这，会有人问，不是要推荐语义化吗？语义化当然要推荐，但不是在这，举个例子，如果我们在全局定义了.red作为文字色，那到下一个模板里，这个颜色成了蓝色，不就囧大了？
3. 公共元素

结构性样式各个部分都可能会用到的公共样式，比如分页，列表，
需要统一管理的样式：按钮，icon，实线虚线等
注意几点：
结构框架，不要定义内边距
公共样式，要写死细节，但不要定义整体位置
按钮灵活
icon用透明图配合样式，注意按照大小分类，同类下宽高一致
实线虚线等给出标准图，css中采用 只提供背景 和 平铺好的一像素div 两种方式提供公共样式
4. 皮肤基础

如果要换肤的话，把细节从2.3里抽出来放在这即可，再针对标准皮肤稿做些补充
这可以看得出:即便没有换肤要求，也非常有必要按照这个思想去做，统一常用的class类，一方面已经实现了可换肤机制，另一方面，对我们后面的开发也大有好处。另外，怎么换肤，哪些地方可不可以换肤，也需要我们从这里整理出来跟设计师沟通

皮肤这块补充一下，有几个点（12.29补充）

1. 文字颜色一定要按照类别分类，比如默认文字色，默认链接色，次级文字色，次级链接色，如果有结构样式的区别（比如左右色调完全不一样）再分左右，形成画笔的概念。总而言之，在这里把画笔准备好，后面就可以自由的发挥，画笔也不宜太多，一般三到五种就可以了，html里的写法如下：

在这行代码里，后面两个都是皮肤属性，txtc是三级文字色，dot是小圆点……

2. 边框、背景之类的细节，即便是在具体模块里是用背景图来实现的，也要在皮肤里定义样式，比如边框，定义一个border-color: #cecfcf;就可以了，方便扩展。

3. 另外，皮肤不要用模块继承的方式，这儿不是说不写继承，而是说不要把某个列表等具体的东西写到skin文件里。具体可以直接参照一下这篇博客的皮肤

http://simg.sinajs.cn/blog7tpl/13/13_19/t.css

这样也有利于商业化或外公司协作开发

5.模块中样式重叠的部分

整个common部分要注意下面几个方面，所有在common里引入的都应该在公共样式预览页面中有所体现，方便同项目下的其他工程师参照。

整个产品或项目下，css的公共类，除第二点外，最好订一个统一前缀

对于css引入的第二行

一方面不要太碎，另外根据模块的不同，结合设计稿之间的共性来定。这会有个矛盾，功能模块跟设计稿的共性不会完全贴切，比如一个细节可能出现在搜索模块下，也可能出现在首页模块下，这建议主要按照功能走，允许出现小范围的冗余，因为前面已经定下了，不同模块之间css是相对独立的。至于重复较多的属性，比如列表，就拿到common里去，就是提到的第五点

最后引入的是皮肤

skin下一般定位一个css和一个images文件夹，整体作为一个皮肤包，一定要有个皮肤包的概念，不要css文件在css的skin下，图片在images下的skin下

另外同产品下的不同皮肤之间，代码要保证一致（除属性具体定义值）防止个别皮肤单独打补丁的情况，如果有新需求，一定要想这个有没有可能以后存在类似的功能。比如春节模板下挂了一个鞭炮动画，我们要想在全局里做一个悬浮效果补丁加到皮肤里，并形成规范约定，倒不是说要升级所有皮肤，意思是说两个月后又一套商业皮肤挂一个气球效果的时候，我们有据可循。

另外就是尽可能的拼合图片
至于图片文件夹
首先文件夹结构跟css要完全贴切，其次common中涉及到的图片，建议按照公共元素，icon，皮肤基础，和刚才说的第5点分类，最后另外考虑到缓存机制，可能增加新图片的时候要改名。压缩拼合等技术细节问题就不在这说了

前面这些思想统一之后，作为builder，再遇到一个项目，就可以按照下面的步骤去做：

1.接到项目，沟通确定开发人员和方式，尽可能早的拿到设计雏形
2.根据项目的具体要求，按照上面提到的几个原则做文件夹部署，包括svn映射等类似的事情，跟开发组随时沟通
3.拿到其中一个设计稿或设计标准后，做结构、公共、等细节，换句话说，要尽可能早的做完common里面的前四项工作，明确css和images下的各个子文件夹的规划，并整理出一份完整的公共元素预览页面
4.根据不同的部分或模块做具体的页面，尽可能的不同的人做不同的部分，牵头人协调好common第五项的工作
如果不同的人做其中一部分的话，主css采用import的方式引入其他css
如果一个人做的话，做好自律
5.开发完毕后，配合工程师开发，这部分主要做培训讲解，让后台工程师明晰我们的框架。并抽空整理开发文档，特别是皮肤说明文档，随时供其他团队或其他合作公司查看，如果对文档的需求紧迫，这一步提前到第四步做。

关于皮肤说明文档，有一点，就是尽可能的把所有换肤的元素整理到一个页面里，把其他无关样式和模块删除，打一个皮肤测试包提供给合作公司
6.配合上线，要做的事情，合并之前做的import css，控制版本，确定版本号等工作

最后总结到一张图里面

嗯，这样做的话，事情就会明晰很多，不至于在开发中被前前后后的人呼来唤去。觉得有道理的话，下次按照这些办法试试？