总是有人说，drupal做的网站很丑，说实话，这是现实——至少在国内，大部分用drupal做的网站确实很丑，哪怕有少数几个做的好的网站也无法掩盖这一点。
反对这个观点的人也非常有道理，他们往往会告诉你，网站做得好看不好看那是设计师的问题，与Drupal无关——其实这句话说的也是有一定道理的。
网页设计往往被认为是整个网站建设流程里面门槛最低，技术含量最低的一个环节。但是，有些时候，设计师就算设计出来了一个好的方案，Drupal也不一定能实现。哦！不对！我表达的不够清楚，不是Drupal不能实现，而是某些Drupaler不能实现。前面几节内容就是一个很好的例子。
让我们来回顾一下，这几节的内容能对我们有什么启发？
要做出前几节中的views区块，需要哪些技能呢？可能不同的人给出的答案会不一样，这里，我来给出我的版本：
- 懂设计（角色：设计师）
- 会用views（角色：themer、site building）
- 会为views定制主题（角色：themer、前端）
- 会最新的css grid layout技术（角色：themer、前端）
- 知道设计一个不规则views区块，前端或者themer不会跑过来跟我吵架，说我没有按照bootstrap的设计规范去做设计（角色：？）
这里面最难的其实是第五条，因为短时间内很难在一个正常的开发团队中找到担当这个任务的角色，css grid layout技术还没有流行起来，连大部分的前端开发者都还不会，这种情况下，我们不可能强求设计师去了解它。前端开发者大部分的时候也不可能去教设计师怎么做设计，不然，办公室里的火药味就太重了一点。后端开发者脑子里根本没有设计的概念，项目经理和助理实习生什么的就更加不沾边了，这几个不提也罢。所以这个时候，我们唯一能够寄希望的人就是团队里有那么一个神一样的存在，设计、前端、后端一个人搞定的那种。不过这种人比较少，剩下的就是我们这些爱好学习的看了晴空的主题专栏而且付了费的人了。。。。。。
说了这么多，大家有没有发现，上面的情况其实核心问题集中在设计师和前端工程师之间的沟通及合作上。从公司和团队的角度来说，我们当然不能指望所有的设计师都懂前端、所有的前端都会设计。因为公司的存在意义就在于它可以为不同的人相互协作提供一个良好的平台，把合适的人放到合适的位置上，让每个人都能做自己最擅长的事情，发挥最大的作用。
不管你是设计师，还是前端工程师还是后端工程师、架构师、或者别的和网站开发有关的角色——我们的工作都是和其他人一起合作完成的、并且是为别人完成的。因此，缩小这种沟通及合作上的鸿沟，就成为了每一个正规的网站建设公司和团队所必须面对的问题。
谈到沟通与合作，代码、注释的标准化，版本控制等是大家早都熟悉的手段。
在主题这个层面其实也有类似的沟通与合作问题——在网络出现以前的平面设计时代，设计师和施工方之间就有过同样的问题。比如某公司在设计师做好logo和其他视觉标识之后，如何保证其名下的几千家门店都能按照正确的方式施工，而不会影响品牌的视觉识别度？于是，前辈们发明了所谓的“视觉识别系统”，英文简写VIS。
而在网络出现后的这几十年里，人们逐渐发现，在网络世界里，类似的问题同样不可忽视，类似VIS的东西依然起着非常重要的作用。并且，由于每一个大型的网站在整个生命周期内都会存在着无数次的升级和变动，因此，一本印刷出来，拿在手里的VIS手册已经不管用了，我们需要的是一份“活的”能够随时自动更新的在线的视觉识别系统。它的出现，更清晰的划分了设计师和前端工程师的工作界线，为设计师和前端工程师们，甚至于项目经理和客户们提供了一个更方便的讨论和沟通的平台。它在西方的设计界有很多与之相关的概念，比如：design system 、living style guide 、 pattern library，并且还会涉及到诸如前端自动化、SMACSS、BEM之类的前端技术和概念。他们是Drupal主题和其他网站系统设计及前端技术的趋势走向。越来越多的大公司大网站都开始在这方面进行自己的实践并惊喜的从中获得各种好处。
我们将在之后的第二篇中，讲述和这些有关的内容。
Ok，到这里，我们这个专栏的第一部分就结束了，如果你仔细阅读并掌握了这40节内容，那你就已经对Drupal的主题系统有了一个大致的了解。当然，这并不意味着你学会了所有的东西，比如预处理函数的使用，库文件的控制，其它主要网页元素，比如表单、分类术语等的覆写、断点的设置、响应式图片的处理都还没有讲。但是，有了第一部分的基础之后，通过谷歌和检索Drupal文档，你会发现以上这些也都不再有什么难度了。
各位读者朋友如果有关于Drupal主题开发相关的问题，希望我做出教程的，也可以在这个页面上留言，我会选取值得一讲的问题，在第二篇中详细讲述。
谢谢大家的阅读。
敬请期待本专栏的第二篇。
