【项目总结】扯一扯电商网站前端css的总体架构设计（1）

　　最近半忙不忙的写了一个外包网站，网站主要功能是艺术品竞拍和艺术衍生品的销售。工程已经完成了80%左右，如今先后端代码量已经50W行左右，我主要负责的是前端设计和前端布局。下面就先放一个网站的设计图吧，由于涉及到甲方的“商业机密”，因此打一下马赛克：

　　

　　

　　这篇文章主要算是我对于这个项目的总结或者说是对于这阶段本身看的一些前端书或者经验的一个总结吧，因此设计图就不贴那么多了。整个项目的设计图由最开始的ui定了个首页稿基调，剩下的界面大部分都是我在首页稿基础上作出来的，之后有机会再唠。PS:不过话说博客园里如今遍园子都是.net的文章，前端的文章除了js的，就是那些“可复制可粘贴”的源码文，但愿之后能看到更多前端好文吧。

　　整个网站的单界面（不包括后端）已经有3,40个了，css文件累积下来也有10多个（这个以后会细说，这块儿是我这个项目中作的最失败的一部分，也是我写这个blog的缘由）。

　　

　　

　　一个一个问题的唠,我就说说本身的理解，不太对的地方欢迎交流：

　　1、什么是css的架构？为何要作架构？

　　　　若是作的是一个小的博客网站或者说是一个小的CMS，那可能不少时候不用考虑css的架构，由于css文件不多，总共就不到10个界面，给每一个界面单独写样式、单独封一个css文件也没有太大的工程量。可是，若是换到这种界面数达到几十个或者几百个的大型网站中，css的架构就很是有必要了。并且，好的架构可以帮助团队共同开发，不可能说总共几十个界面，3个前端，一人分十几个，好，大家去写吧，这样的工做效率过低，并且极易致使样式冲突和样式被覆盖，可能写起来很快，每一个人都很勤劳的把本身的代码写完了，而后后端总合以后发现样式全乱了，一改改了好几天，比写都慢。

　　　　合适的css结构可以帮助开发者减小代码量，可以帮助前端开发团队在共同开发的过程当中可以更好的合做。同时它也能优化前端的总体结构，合理的css架构可以减小css文件数目和css文件总大小，下降对服务器的访问压力。

　　　　它也能大幅度提升前端代码的重用度和减小代码的维护成本。对于那种1个小时想改一次界面的甲方，没有好的css架构真是要疯了。好比说你每一个页面都有个标题栏，每一个页面都是一个单独的css，而后忽然有一天甲方深井冰同样说，我想改一下样式，这时候你只有两个办法：1.抱着甲方大腿哭诉求不改2.默默打开电脑开始一个界面一个界面的改。看到这里不少有开发经验的同志们应该都知道说，提取这个标题版块，写在统一的css文件内，每一个界面都引用一下，最后想改的话只要去总的那个css文件里面改就能够了。这就是最简单的模块化，不过，模块化的过程当中还有不少问题须要注意：1.好比3个界面都有标题栏，可是3个界面对于标题栏字体颜色的要求各不相同怎么办？对于上下margin的要求又不相同怎么办？2.忽然多了一个界面，它有标题栏，可是它标题栏里多了个背景图片，这个怎么解决？再麻烦一点，它标题栏里多了一个<p>表签，多出来的又怎么布局？这种解决模块之间差别的问题确实值得好好研究一下。

　　　　一般的css架构，或者是当前网站的css框架，包括了对浏览器默认样式的覆盖重置、对网站内部模块的提取抽象化、约定css代码规范、冲突解决等功能。若是项目中有引用其余的成熟框架，好比说bootstrap、yui,怎么把这些框架和本身写的分割开，能实现样式而又不冲突？稍后慢慢唠。

　　　　怎么作css架构或者怎么实现简单的css结构？

　　　　答：写代码啊！

　　

　　2、css的架构从哪里作起呢？

　　　　动手一个项目前，不能看到设计图就直接干，应该先想的是怎么样去写。就像咱们老师最常对咱们说的同样“只会写代码，你只是平庸的程序员。可以作出好的架构或者可以安排好项目怎么开发的，才是高端点儿的程序员。平庸的程序员只能吃香蕉，高端的程序员有时候还能吃点菠萝、苹果啥的”。直接动手开始写，写着写着就会发现不少时候本身是在作重复功，不断地复制粘贴或者是为了一个界面模块重写一种又一种样式，或者写着写着发现“卧槽，冲突了，样式乱了”，再或者写着写着发现本身写的不对想回去改，而后开始挨个文件的改...这种没有架构的、笨拙的在写css就是在干体力活，好久以前写的一个项目就是这样，20几个界面慢慢改去吧，改了整整两天，都要疯了...

　　　　动手一个项目前，最起码的，应该想清楚大体有多少个css文件，哪些css文件须要先写出来一个固定版本，哪些css代码可能会大量重用，哪些css文件可能会有大规模的改动。而后根据这些css的详细要求去开始动手写第一版。

　　　　好比我上面放的截图，最直观的header首部栏：，在每一个界面都是同样的。固然这个咱们能够在后端里面用分布视图layout来实现，可是在界面前端实现的初期，是否是也应该把这一起的html、css、js抽离出来，这样在后端进行最后整合的时候也能快一些，并且万一碰到个圣诞节，客户说给上面背景色换成蓝色吧，这样直接翻到header.css里改一改样式就行了，不用苦逼的去“体力活”了。

　　　　因此，第一种css前端架构设计的方式就是：按照区域划分。

　　　　按照页面内的元素或者模块的区域定位，网站中能够划分出来不少区域：header、footer、sidebar、slogan等等，针对于这些区域单独定位可以有效的实现分布视图的划分，每一个区域都被抽离出来，新建一个界面的时候咱们只须要在里面拼一拼就行了。没记错的话，yui就是这么干的。

　　　　在这个拍卖网站的css里我没有单独抽离出来，由于我以为单独抽离成一个header.css、footer.css文件有点赘余，css文件数在增多，而每一个文件内的代码行数却不多。这个还要根据具体代码来看，一个footer样式写了几十行的话，那就抽离成一个文件吧。因此我在总的css文件:layout.css里实际上是按照区域进行写的：。当我想要更改底部导航样式的时候，直接就去layout.css里往下翻找，改掉就能够了。

　　　　

　　　　然而咱们对界面进行分割以后发现，仍是有不少代码在大量重复出现，好比说登录框、好比说表格、好比说文本框等等，因此有了第二种划分方式：按照功能进行划分。

　　　　按照功能划分就是看元素的界面内功能是什么，而后根据具体功能，把具备相同功能的元素、模块抽离出来：font、color、button、form等等，这个应该是如今不少成熟框架采用的模式，好比我大bootstrap就是这么干的，下面是bootstrap2.3的less文件夹的截图，很明显，都是一个个功能模块，最后咱们直接应用的是被所有整合压缩的.min.css，里面其实也仍是这种结构：

　　　　

　　　　按照功能划分仍是蛮爽的，由于你能够为每一个功能划分添加统一的前缀，在有代码提示的编译器里写代码简直极速。换成那种按区域划分的话，有时候就略微蛋疼了“哎呀，页脚的css名是什么？哎呀，小王写的那块儿侧边栏的类名是什么”。

　　　　在这个项目的代码里，我其实采用的是第一种方式和第二种方式混用的模式，从我上一张css文件截图就能看出来，我不只把重复出现的区域模块的代码抽象了出来，并且也把侧边栏、遮罩这种功能模块给抽象整理了出来，尽可能提升个人代码的复用度。

　　　　以前还以为本身的这个项目的架构作的不错，可是后来越写越坑，由于不少时候本身都是在作无用功。我犯的傻X错误：

　　　　　　1.模块抽象有局限。好比说表单有要差一个特殊的元素，原来写好的模块就无法用了，又得重头写一遍。

　　　　　　2.模块抽象不彻底。在我认为本身已经把模块抽象作的差很少的时候就开始全力写，写着写着发现，有的模块被遗忘了，不少模块须要一遍一遍的手写。

　　　　　　3.css类名不规范说究竟是模块没有划分好。这个网站写到如今，个人命名已经词穷了，它这里有不少界面：加入购物车、加入收藏列表、查看购物车、确认支付、填写确认订单、一口价支付...没有好的英文底子真是噩梦...因此只能翻译汉语名，而后驼峰命名法：AddCart。其实命名法还有不少，驼峰命名法最大的好处就是能够很直观的命名，不用考虑别的，可是驼峰命名法在子类命名的时候就比较头疼了，一个又一个的长单词...另外一种命名方法是划线法，为了不麻烦直接用的下划线没用中杠add_cart，这种命名法对于子类命名特别爽，这个后几篇总结的时候再唠。

　　　　------------下面---------就是------------本篇-------核心-----了---

　　　　下面就是本篇文章的【核心】了，也是我痛心疾首的反思T^T最近项目受阻、半写不写的状态，因此看了一些前端代码规范、网站前端开发的总结的书，而后发现了一种新的结构方法，看完以后真是整我的都很差了。推荐这本书《编写高质量代码-web前端开发修炼之道》

　　　　另外一种比较推荐的css架构方法是：按照界面职能进行划分：这里将网站的整个前端抽象成了一个软件或者是一个项目，这时候咱们要考虑的就是项目底层是什么，项目的表现层是什么，相似于你们常说的mvc的思想，把前端架构也进行mvc般的划分，能够把全部的css文件概括为三类：

　　　　　　1.base类 　　2.common类　　3.page类

　　　　这三类并非像区域架构、功能架构中并列做用的模式，而是以base类为底层，逐层影响，层叠做用，大概画了个做用图：

　　　　确实，就像这种金字塔结构，下面详细介绍一下每一个类的做用。

　　

　　　　[1.base类]

　　　　　　顾名思义，基础，它是整个css架构中最基础的部分。它负责提供浏览器默认样式重置、基础功能实现。说到base里的基础功能实现，它主要指的是那种涉及范围极小、抽象程度高的原子级别的功能类实现。好比咱们最多见的.f12{font-size:12px;}，.mt30{margin-top:30px;}，每个原子类只负责实现一种功能，绝对不涉及到具体的页面ui，只是为上几层提供原子功能，具体某模块的实现则有这些原子类间进行组合实现。固然，base类还要负责浏览器默认样式的reset，这个我以为yui实现的就很靠谱，如今不少网站的<h123456>都是不加粗的，这个都须要提早在reset部分写好。

　　　　　　base类是整个css架构的地基，全部界面都会引用整个文件，这对这个文件提出了要求：1.文件大小不能过大 2.文件可靠性要高，不能出现多个版本 3.写成以后尽可能减小维护次数或者尽可能不用维护。并且不一样网站的base类能够共用，由于base类不涉及任何具体的ui样式，高度可移植。

　　　　　　具体base类文件都有什么，这个下一讲来好好唠唠，今天没空了。

　　　　[2.common类]

　　　　　　普通类，它是利用css基础类实现的基础模块的css文件，咱们已经把整个界面里的文字、边距、颜色等原子工程抽离出来了，如今须要咱们为当前网站定制模块了。

　　　　　　设计原则里“统一性原则”要求到同一网站必须保持风格一致，你不可能首页扁平化，进了列表页就来个高光高阴影还带酷炫flash的web2.0风格页。因此，同一网站内的搜索框、文本框、按钮、列表大多数状况下都是统一风格的，因此这就给咱们个机会，把这些会重复出现的模块抽离到common类里，相似于MVC里面的model，也相似于咱们上面讲述的架构功能划分的具体功能文件。为了尽可能保证可重用和灵活使用，咱们须要对这些模块进行完整封装。

　　　　　　话说，模块须要进行订制时怎么办？

　　　　　　我想到了两个办法，一种是利用less等语言给模块预留样式接口，直接修改配置文件，再动态输出css文件。2.尽可能减小模块的ui属性，好比bgcolor或者是border，能够空缺，而在实际使用时根据本身的须要与原子类进行组合。可是这种方法可能会对原子类有要求并且会对base文件产生影响，因此我本身又编出了个词：分子类，显而易见就是提供针对于模块的大原子类定制，为每个模块定制专属样式类，一样至于common层，须要定制模块样式时只须要彼此组合便可。以后的文章里写点东西示范一下。　　

　　　　[3.page类]

　　　　　　页面类，从图里也能看出来，它在金字塔的塔尖，而它的做用范围也是最小的，就是每个页面，到不至于每个页面一个css，可是也差很少吧。 page类就是负责提供页面级样式的。page类css可能产生一些比较使人纠结的问题：1.page太多，因此page css单文件太多，每个文件就是一个http请求，服务器能受得了不？2.page css为了避免多，因此合并在一个page.css里，可是命名怎么办？好比.part, .one, .main, .theme....这些频繁出现的类名合并冲突怎么办？

　　　　　　第二个问题能够经过命名范围限定来解决。

　　　　　　至于第一个问题，你能够把css单文件合并，而后你就去看第二个问题的答案吧。

　　　　　　

　　　　　　总结下来，在开发中，base和common类通常由一我的完成，在他完成这些类以后其余人接手项目，开始添些page.css，因此page层里代码奇多，若是应用到分布视图，一个整页面实际上是由若干个小界面拼起来的，那么如何避免冲突？如何避免样式覆盖？之后详谈。

 

　　　　

　　　　　_(:з」∠)_码了这么多字累死我了，今天就先写到这。下篇见~~【求交流求师傅带求内推求不吐槽...】

　　　　　下一篇文章，我们详细谈谈base类css文件，以及我本身对项目css的重构。　　

　　　　　最后，最后，我想说的就是↓↓↓