Skip to content

Latest commit

 

History

History
478 lines (377 loc) · 30.3 KB

前端代码规范.md

File metadata and controls

478 lines (377 loc) · 30.3 KB
Raw

[TOC]

概述

编写文档的主要驱动力是两方面：

  • 代码一致性
  • 最佳实践

通过保持代码风格，规范团队习惯，我们可以减少遗留系统维护的负担，并降低未来系统崩溃的风险。并通过遵照最佳实践，我们能确保优化的页面加载、性能以及可维护的代码。

核心思想

  • 表现、内容和行为分离
  • 标记应该是结构良好、语义正确以及普遍合法
  • Javascript应该起到渐进式增强用户体验的作用

总体原则

缩进

对于所有编程语言，要求缩进必须是软tab(空格字符)，在编辑器里Tab应该等于4个空格

可读性 vs 压缩

对于维护现有文件，我们认为可读性比节省文件大小更重要。大量空白和适当的ASCII艺术都是受鼓励的。任何开发者都不必故意去压缩HTML或CSS，也不必把Javascript代码最小化得面目全非。

我们会在服务器端或build过程中自动最小化并gzip压缩所有的静态客户端文件，例如CSS和JS。

注释

注释是了解代码写法和目的的最重要手段，特别是在阅读他人的代码时，注释就变得尤为重要了。

写注释时要注意：不要只写你的代码的作用是什么，更应写出你的代码为什么要这样写，背后的考量是什么，会产生哪些影响。当然也可以加入思考问题或是解决方案的链接地址。

var offset = 0;

if (includeLabels) {
  // if the labels are included we need to have a minimum offset of 20 pixels
  //we need to set it explicitly because of the following bug: http://somebrowserver.com
  offset = 20;
}

文件/资源命名

在 web 项目中，所有的文件名应该都遵循同一命名约定。以可读性而言，减号（-）是用来分隔文件名的不二之选。同时它也是常见的 URL 分隔符，所以理所当然的，减号应该也是用来分隔资源名称的好选择。

请确保文件命名总是以字母开头而不是数字。而以特殊字符开头命名的文件，一般都有特殊的含义与用处（比如 compass[1] 中的下划线就是用来标记跳过直接编译的文件用的）。

资源的字母名称必须全为小写，这是因为在某些对大小写字母敏感的操作系统中，当文件通过工具压缩混淆后，或者人为修改过后，大小写不同而导致引用文件不同的错误，很难被发现。

还有一些情况下，需要对文件增加前后缀或特定的扩展名（比如 .min.js, .min.css），抑或一串前缀（比如 3fa89b.main.min.css）。这种情况下，建议使用点分隔符来区分这些在文件名中带有清晰意义的元数据。

my-script.js
my-camel-case-name.css
always-index.html
my-file.min.css

协议

不要指定引入资源所带的具体协议。

不指定协议使得 URL 从绝对的获取路径转变为相对的，在请求资源协议无法确定时非常好用，而且还能为文件大小节省几个字节。

// 引入js
<scirpt src="//cdn.com/foundation.min.js"></script>

// 引入静态资源
.example {
  background: url(//static.example.com/image/bg.jpg);
}

代码检查

对于比较宽松自由的编程语言来说，严格遵循编码规范和格式化风格指南就显得极为重要。遵循规范固然很好，但是有自动化流程来确保其执行情况，岂不更佳。Trust is good, control is better.

对于 JavaScript，建议使用 JSLint 或 JSHint。

HTML

HTML5

HTML5 是HTML 和 XHTML 的新版本。 在 HTML5 草案 的规范中定义了可以用 HTML 和 XML编写的单一的语言，意在解决在之前HTML的迭代中发现的一些问题并满足web应用的需求，这是以前HTML没有充分覆盖到的领域（来源 ） 。

在合适的时候，我们会使用HTML5 Doctype 和 HTML5 特性。

我们会对照 W3C 校验器 测试我们的标记，以确保标记是结构良好的。我们的目标并不是100%的合法代码，但是校验肯定对于编写可维护的站点以及调试代码都大有帮助。

Doctype

标记中必须总是使用合适的Doctype来指示浏览器触发标准模式. 永远要避免Quirks模式。

HTML5特别好的一个方面就是它简化了Doctype需要的代码。无意义的属性被弃用了，DOCTYPE 声明也被显著地简化了。另外，也无需再用 CDATA 对内联JavaScript代码进行转义，而这在此之前为了让XHTML符合XML的严密性是必需的。

<!DOCTYPE html>
</html>

字符编码

所有标记必须通过UTF-8编码传递，因为这种编码方式是对国际化最友好的。必须在HTTP的header和HTML文档的head部分都指定这种编码。

<meta charset="utf-8">

省略可选标签

HTML5 规范中规定了 HTML 标签是可以省略的。但从可读性来说，在开发的源文件中最好不要这样做，因为省略标签可能会导致一些问题。

省略一些可选的标签确实使得页面大小减少，这很有用，尤其是对于一些大型网站来说。为了达到这一目的，我们可以在开发后期对页面进行压缩处理，在这个环节中这些可选的标签完全就可以省略掉了。

脚本加载

出于性能考虑，脚本异步加载很关键。一段脚本放置在 <head> 内，比如 <script src="main.js"></script>，其加载会一直阻塞 DOM 解析，直至它完全地加载和执行完毕。这会造成页面显示的延迟。特别是一些重量级的脚本，对用户体验来说那真是一个巨大的影响。

异步加载脚本可缓解这种性能影响。如果只需兼容 IE10+，可将 HTML5 的 async 属性加至脚本中，它可防止阻塞 DOM 的解析，甚至你可以将脚本引用写在 <head> 里也没有影响。

如需兼容老旧的浏览器，实践表明可使用用来动态注入脚本的脚本加载器。你可以考虑 yepnope 或 labjs。注入脚本的一个问题是：一直要等到 CSS 对象文档已就绪，它们才开始加载（短暂地在 CSS 加载完毕之后），这就对需要及时触发的 JS 造成了一定的延迟，这多多少少也影响了用户体验吧。

终上所述，兼容老旧浏览器(IE9-)时，应该遵循以下最佳实践：

脚本引用写在 body 结束标签之前，并带上 async 属性。这虽然在老旧浏览器中不会异步加载脚本，但它只阻塞了 body 结束标签之前的 DOM 解析，这就大大降低了其阻塞影响。而在现代浏览器中，脚本将在 DOM 解析器发现 body 尾部的 script 标签才进行加载，此时加载属于异步加载，不会阻塞 CSSOM（但其执行仍发生在 CSSOM 之后）。

<!DOCTYPE html>
  <head>
    <link rel="stylesheet" href="main.css">
  </head>
  <body>
    <!-- body goes here -->
 
    <script src="main.js" async></script>
  </body>
</html>

语义化

根据元素（有时被错误地称作“标签”）其被创造出来时的初始意义来使用它。打个比方，用 heading 元素来定义头部标题，p 元素来定义文字段落，用 a 元素来定义链接锚点，等等。

有根据有目的地使用 HTML 元素，对于可访问性、代码重用、代码效率来说意义重大。

<!-- The page header should go into a header element -->
<header>
  <!-- As this title belongs to the page structure it's a heading and h1 should be used -->
  <h1>My page title</h1>
</header>
 
<!-- All navigation should go into a nav element -->
<nav class="top-navigation">
  <!-- A listing of elements should always go to UL -->
  <ul>
    <li class="nav-item"><a href="#home">Home</a></li>
    <li class="nav-item"><a href="#news">News</a></li>
    <li class="nav-item"><a href="#about">About</a></li>
  </ul>
</nav>
 
<!-- The main part of the page should go into a main element -->
<main class="news-page" role="main">
  <!-- A section of a page should go into a section element. Divide a page into sections with semantic elements. -->
  <section class="page-section news">
    <!-- A section header should go into a section element -->
    <header>
      <!-- As a page section belongs to the page structure heading elements should be used (in this case h2) -->
      <h2 class="title">All news articles</h2>
    </header>
 
    <!-- If a section / module can be seen as an article (news article, blog entry, products teaser, any other re-usable module / section that can occur multiple times on a page) a article element should be used -->
    <article class="news-article">
      <!-- An article can contain a header that contains the summary / introduction information of the article -->
      <header>
        <!-- As a article title does not belong to the overall page structure there should not be any heading tag! -->
        <div class="article-title">Good article</div>
        <!-- Small can optionally be used to reduce importance -->
        <small class="intro">Introduction sub-title</small>
      </header>
 
      <!-- For the main content in a section or article there is no  semantic element -->
      <div class="content">
        <p>This is a good example for HTML semantics</p>
      </div>
      <!-- For content that is represented as side note or less important information in a given context use aside -->
      <aside class="article-side-notes">
        <p>I think I'm more on the side and should not receive the main credits</p>
      </aside>
      <!-- Articles can also contain footers. If you have footnotes for an article place them into a footer element -->
      <footer class="article-foot-notes">
        <!-- The time element can be used to annotate a timestamp. Use the datetime attribute to specify ISO time while the actual text in the time element can also be more human readable / relative -->
        <p>This article was created by David <time datetime="2014-01-01 00:00" class="time">1 month ago</time></p>
      </footer>
    </article>
 
    <!-- In a section, footnotes or similar information can also go into a footer element -->
    <footer class="section-footer">
      <p>Related sections: Events, Public holidays</p>
    </footer>
  </section>
</main>
 
<!-- Your page footer should go into a global footer element -->
<footer class="page-footer">
  Copyright 2014
</footer>

关注点分离

理解 web 中如何和为何区分不同的关注点，这很重要。这里的关注点主要指的是：信息（HTML 结构）、外观（CSS）和行为（JavaScript）。为了使它们成为可维护的干净整洁的代码，我们要尽可能的将它们分离开来。

严格地保证结构、表现、行为三者分离，并尽量使三者之间没有太多的交互和联系。

就是说，尽量在文档和模板中只包含结构性的 HTML；而将所有表现代码，移入样式表中；将所有动作行为，移入脚本之中。

在此之外，为使得它们之间的联系尽可能的小，在文档和模板中也尽量少地引入样式和脚本文件。

清晰的分层意味着：

  • 不使用超过一到两张样式表(i.e. main.css, vendor.css)
  • 不使用超过一到两个脚本(学会用合并脚本)
  • 不使用行内样式(<style>.no-good {}</style>)
  • 不在元素上使用 style 属性(<hr style="border-top: 5px solid black">)
  • 不使用行内脚本(<script>alert('no good')</script>)
  • 不使用表象元素(i.e. <b>, <u>, <center>, <font>, <b>)
  • 不使用表象 class 名(i.e. red, left, center)

内容至上

不要让非内容信息污染了你的 HTML。现在貌似有一种倾向：通过 HTML 来解决设计问题，这是显然是不对的。HTML 就应该只关注内容。

HTML 标签的目的，就是为了不断地展示内容信息。

  • 不要引入一些特定的 HTML 结构来解决一些视觉设计问题
  • 不要将img元素当做专门用来做视觉设计的元素

不推荐：

<!-- We should not introduce an additional element just to solve a design problem  -->
<span class="text-box">
  <span class="square"></span>
  See the square next to me?
</span>

.text-box > .square {
  display: inline-block;
  width: 1rem;
  height: 1rem;
  background-color: red;
}

推荐：

<!-- That's clean markup! -->
<span class="text-box">
  See the square next to me?
</span>

/* We use a :before pseudo element to solve the design problem of placing a colored square in front of the text content */
.text-box:before {
  content: "";
  display: inline-block;
  width: 1rem;
  height: 1rem;
  background-color: red;
}

Type属性

省略样式表与脚本上的 type 属性。鉴于 HTML5 中以上两者默认的 type 值就是 text/css 和 text/javascript，所以 type 属性一般是可以忽略掉的。甚至在老旧版本的浏览器中这么做也是安全可靠的。

CSS

盒模型

深入学习和理解CSS及基于浏览器的盒子模型，对于掌握CSS布局的基础是非常必要的。 box-model

Hacks

避免用户代理检测以及CSS“hacks” – 首先尝试不同的方法。通过用户代理检测或特殊的CSS滤镜，变通的方法和 hacks 很容易解决样式差异。为了达到并保持一个有效的和可管理的代码库，这两种方法都应该被认为是最后的手段。换句话说，从长远来看，用户代理检测和hacks会伤害项目，作为项目往往应该采取阻力最小的途径。也就是说，不要轻易允许使用用户代理检测和hacks。

声明顺序

这是一个选择器内书写CSS属性顺序的大致轮廓。这是为了保证更好的可读性和可扫描重要。

作为最佳实践，我们应该遵循以下顺序(应该按照下表的顺序)：

  • 结构性属性
    1. display
    2. position, left, top, right etc.
    3. overflow, float, clear etc.
    4. margin, padding
  • 表现性属性
    1. background, border etc.
    2. font, text
.box {
  display: block;
  position: absolute;
  left: 30%;
  right: 30%;
  overflow: hidden;
  margin: 1em;
  padding: 1em;
  background-color: #eee;
  border: 3px solid #ddd;
  font-family: 'Arial', sans-serif;
  font-size: 1.5rem;
  text-transform: uppercase;
}

格式

最低要求：选择器单独占一行，每个属性占一行。属性声明要有缩进。

作为提高的要求，关联或孩子样式要增加2-4个空格的缩进。这样有利于分层查看和组织，产生（对某些人来说）可读性更好的样式表。

另外，在给一个样式指定多个选择器的时候，把每个选择器单独放一行是个好主意。这样可以避免一行变得太长，也能提高可读性及版本控制流程。

Classes vs. IDs

对于所用的样式只出现一次的元素，给它设一个id属性。这个属性只会应用于该元素，不会用到其他地方。Class属性则可以用到多个具有相同样式属性的元素上。具有相同外观和表现的元素可以具有相同的class名。

<ul id="categories">
  <li class="item">Category 1</li>
  <li class="item">Category 2</li>
  <li class="item">Category 3</li>
</ul>

伪类

伪类 使你能动态地修饰网页内容的样式。有些伪类从CSS1 （:visited, :hover等） 和 CSS2 （:first-child, :lang）那时候开始就有了。CSS3又往列表里加入了16个新的伪类，这些伪类对于动态地修饰网页内容的样式特别有用。 学习如何深度使用伪类

明确度

浏览器会通过 计算选择器的 明确度 来决定应用哪个CSS规则。如果两个选择器都适用于同样的元素，具有更高明确度的那个会胜出。

ID 选择器比属性选择器明确度高，class 选择器比任何数量的元素选择器明确度高。尽量使用 ID 选择器来提高明确度。有时候我们可能会想方设法给一个元素应用一条CSS规则，但用尽方法也不能如愿。这种情况有可能是因为我们使用的选择器比另外一个的明确度低，所以明确度高的另一个选择器里的属性就比我们想应用的选择器优先了。这种情况在更大或更复杂的样式表里更为常见。在小一些的项目里，通常这不是大问题。

明确度的计算方式是对你的CSS的各种组件计数，并用 (a,b,c,d) 格式表达出来。

  • 元素，伪元素: d = 1 – (0,0,0,1)
  • 类，伪类，属性: c = 1 – (0,0,1,0)
  • Id: b = 1 – (0,1,0,0)
  • 内联样式: a = 1 – (1,0,0,0)

像素 vs. Em

我们使用 px 作为定义 font size 的度量单位，因为它能提供对文本的绝对控制。我们知道为字体大小使用 em 单位一度很流行，这样可以解决 IE6 无法改变基于像素的文本大小的问题。不过，现在所有的主流浏览器（包括 IE7 和 IE8）都支持基于像素单位的文本大小 和/或 整页缩放。既然 IE6 被广泛认为已废弃，用像素定义文本尺寸更好。另外，无单位的 line-height 也应该优先考虑，因为它不会从父元素继承一个百分比值，而是基于 font-size 的一个乘数。

#selector {
  font-size: 13px;
  line-height: 1.5;  /*  13 * 1.5 = 19.5 ~ Rounds to 20px. */
}

Javascript

总体原则：

  • 99%的代码必须封装在外部Javascript文件中。这些文件必须在 BODY 标签的尾部引入，让页面的性能最大化。
  • 不要依赖于 user-agent 字符串。进行适当的特性检测. (更多信息参见 深入 HTML5： 检测和jQuery支持文档)
  • 不要使用document.write()。
  • 所有布尔变量的命名必须用 "is" 开头(i.e. isValid = (test.value >= 4 && test.success);)
  • 给变量和函数的命名要有逻辑意义(i.e. popUpWindowForAd就比myWindow好多了。)
  • 不要人为缩短命名到最小。除了传统的 for 循环中的计数器 i 等简化的情况，变量命名必须长到有明确意义。
  • 文档必须遵循NaturalDocs结构。
  • 常量或配置变量(例如动画持续时间等)必须放在文件的顶部。
  • 尽力编写可通用化的函数，让它接受参数并返回值。这样有利于充分的代码重用，而且一旦与引入及外部脚本配合起来，能在脚本需要修改时减少开销。例如，相比硬编码一个带有窗口大小、选项和url的弹出式窗口，不如编写一个接受大小、url和选项作为变量的函数。
  • 给代码添加注释！这会有利于减少在调试Javascript函数上花费的时间。
  • 不要把时间浪费在用 给你的内联Javascript加注释上，除非你还在关注 Netscape 4。 :)
  • 把你的代码组织成一套对象常量/单例，按照模块化模式，或做成带构造器的对象。
  • 最小化全局变量 - 你创建的全局变量越少越好。一般来说，用于你的应用命名空间，1会是个好的数字。(window.globalVar = { ... })

留空

总的来说，使用留空应该遵循源远流长的英语阅读惯例。 例如，每个逗号和冒号（以及适用的分号）后面要空一格，但在括号内部的左侧和右侧都不要加空格。另外，大括号应该总是和他们前面的参数出现在同一行。

for (var i = 0, len = arr.length; i < len; i += 1) {
  // Do something
}

变量，ID 及 class

所有的 JavaScript 变量必须写成全小写或驼峰法。一个例外是构造器函数，按惯例是首字母大写。所有CSS里的 id 和 class 声明都必须只用小写。不允许用连接符或下划线。

事件代理

在分配低调(unobtrusive)的事件监听器时，通常可接受的做法是把事件监听器直接分派给那些会触发某个结果动作的元素。不过，偶尔也会有多个元素同时符合触发条件，给每个元素都分配事件监听器可能会对性能有负面影响。这种情况下，你就应该改用事件代理了。

从性能角度考虑，jQuery的 delegate() 优于 live()。

优化 JavaScript 的特征

  • 使用严格模式
  • 编写可维护的代码
  • 单变量模式
  • Hoisting：把所有变量声明统一放到函数的起始位置 （在后部声明的变量也会被JS视为在头部定义，由此会产生问题）
  • 不要扩充内置原型（虽然给Object(), Function()之类的内置原型增加属性和方法很巧妙，但是会破坏可维护性）
  • 不要用隐含的类型转换
  • 不要用 eval()
  • 用 parseInt() 进行数字转换
  • （规范）左大括号的位置
  • 构造器首字母大写
  • 写注释
  • 不要用 void
  • 不要用 with 语句
  • 不要用 continue 语句
  • 尽量不要用位运算

性能

优化CSS和Javascript传输

  • 遵循 Yahoo 性能指南
  • 使用 smush.it 对图片进行无损压缩优化。 还有，用 YSlow 可以把你所有的图片自动压缩(YSlow不仅仅提供性能优化工具，还详细说明了性能优化的34条规则，例如不要用CSS表达式、不要用空白的src或href、使用CDN、缓存AJAX响应、不要用过滤器、减少DOM元素数量等等)。
  • 不要在HTML中写内联脚本<script>块。 它们会阻塞页面渲染操作，对页面加载时间带来破坏性的影响。
  • 适当地设置缓存标题。
  • 针对静态资源，考虑单独配置一个无cookie的子域。
  • CSS 必须放在文档的<head>部分, Javascript 必须正好放在</body>标签的前面。
  • CSS 和 JavaScript 都必须以最小化方式加载。大部分人会使用 YUI 压缩器 做这件事。
  • CSS 和 JavaScript 都必须 以gzip形式传输。
  • CSS 必须串接在一起。显然，只有具备相同媒体类型（例如屏幕或打印）的文件才能合在一起。这里的总体目标是在加载页面的时候减少因为依赖关系而产生的HTTP连接数。
  • JavaScript 必须串接在一起。虽然用一个AJAX脚本依赖性管理器(类似于 YUI 3 Loader)可能会比较理想，但实施起来还是挺复杂的。 在这里我还是想推荐单次下载站点用到的所有脚本。(当然了，适当的缓存也是必需的，这样可以让文件在合理的时间内尽可能保持在本地)。
  • 串接和最小化通常发生在自动build的过程中，这时候要把代码打包用于发布或生产。有很多人用一些工具做这件事，例如 Ant 或 Maven 。

优化Javascript执行

  • 改变页面视觉习性的脚本绝对要首先执行。这包括任何的字体调整、盒子布局、或IE6 pngfix。
  • 页面内容初始化
  • 页面标题、顶部导航和页脚的初始化
  • 绑定事件处理器
  • 网页流量分析、Doubleclick，以及其他第三方脚本

图片格式

  • JPEG. - 这种格式涵盖了所有基于摄影的图片，例如主页和目录页推销广告图片，或任何颜色数很高的图片。

  • PNG24. - 这种格式在Photoshop里用起来很方便，它输出高颜色数图片，并完全支持像素级的渐变透明度。相对来说，它是相当重量级的格式，达到KB级大小。它也是IE6唯一需要执行pngfix的格式。在那种情况下，本公司推荐使用 DD_belatedPNG 脚本 （这是一个 pngfix ，它能修正 PNG24 在 IE6 里冒出灰色或浅蓝色背景的问题。它们并不总是和 background-position 兼容）。

    在很多情况下，你可以使用GIF替代PNG24作为对IE6的应变方案。这在需要用PNG24做sprite的情况下尤其适用。所有的 pngfixes 都会特别慢而且开销巨大，所以最好不要用它们。

  • PNG8. - 在256色中可以抓取到如此多样的颜色，所以用JPG之前尝试一下PNG是值得的。而且，PNG比GIF有更高的可压缩度（使用类似 pngcrush 和 pngquant的工具）。这种格式支持在几乎所有浏览器中实现渐变透明度，但在IE6中那些半透明像素会显示为100%透明。不过在很多情况下这也够用了。它也无需运行pngfix脚本，所以对于速度是优化的。

    Photoshop 无法正确输出这些半透明文件，但是Fireworks 可以。更多细节请参阅： png8

  • 透明 GIF 89a. - GIF 89a 提供透明度的灵活性和广泛的浏览器支持，但也有限制，它不支持渐变透明度和超过256的色深。就我们的经验而言，64的色深就可以提供质量很好的缩略图，并保持相对小的文件大小。

    所有低颜色数图片，例如图表或主题图形应该用PNG8格式制作，因为它是这四种格式中具有最高文件大小效率的。PNG8是我们对于大部分网站图形的主要推荐方案。

关于PNG格式、浏览器支持以及各种格式优缺点的详细信息可以在PNG that works中找到。 如需进一步优化所有这些格式，从 Yahoo的Smush.It查看图片可以发现缩小它们的办法。

缓存

对于静态内容，浏览器应该把文件在本地缓存，在合理的前提下，保留尽可能长的时间。应该较长远期缓存的内容包括：

  • CSS 和 JavaScript
  • 产品图片
  • 主题图形
  • favicon.ico
  • flash .swf's
  • 优惠信息图片（可能缓存时间会略短）

为了最佳缓存效果，利用http头部的Expires。下面是一个远期的Expires头，它告诉浏览器这个响应在2015年5月15日之前都无需更新：Expires: Thu, 15 Apr 2015 20:00:00 GMT

避免用IFRAME

Iframe 是能添加到指定页面的各种元素中上开销最大的一个。它们会阻塞页面让它无法触发onload事件，直到它们加载完成。有时候它们被其他机构用来处理追踪脚本。例如 Doubleclick floodlight 标签就是一个 iframe，管理员可以从他们的管理面板向里面增加追踪像素。在加入iFrame的任何情况下，它应该在window的onload事件被触发之后再动态加入到DOM中。 更多细节请参阅Yahoo 的性能站点。

代码审查

代码审查是用于降低项目风险的战略性时间投资：经常地，接口开发者被要求根据线框图或视觉构图编写标记。不过，有可能设计的屏幕不能轻易转换为标记，或者转换后质量有损失。代码审查为在页面投入生产之前发现并解决这些风险提供了一个机会。

代码审查能够提升跨项目的整体知识水平：既然代码审查涉及到项目内外的成员，这有利于在整个团队中分享技术和最佳实践。

代码审查能在bug从一些模板繁衍到多个页面之前就封杀它们：理想情况下，代码审查是在开发过程的早期进行的，早于页面开始全面投入生产。当模板被团队审查并在多个校验工具和浏览器运行，潜在的bug就会冒出来。这是修复bug的理想时机。

代码审查给不熟悉项目的外部成员提供了发现代码中问题的机会：项目外部的审查者比在代码上工作了更长时间的标记编写者更容易发现问题。

哪些人应该参加代码审查：

  • 归根到底，项目的前端工程主管要负责确保代码审查遵循合适的流程。
  • 理想情况下，一位部门主管应该作为代码审查的主持人，除非部门主管自己正好是被审查代码的接口开发者。在这种情况下，由一位项目经理进行主持。
  • 审查小组应该包括至少两位来自接口技术团队精通开发和最佳实践的资深成员。

代码审查中有哪些要求：在进行代码审查之前，需要审查的模板必须整体完成开发、经过校验、并针对项目需要用到的浏览器和平台进行了测试。

部门主管 和/或 接口开发者必须在代码审查前至少48小时 分发以下材料：

  • 所有页面代码，相关的服务器端引用，CSS 和Javascript。这些必须有完整注释，左侧列出行号，在每个打印页的页脚标明文件/页面名称。
  • 每个模板的截屏
  • 如果适用，标明模板对应的URL
  • 项目支持的浏览器和平台的清单
  • 已知问题和关注领域的清单
  • 很典型的情况是，直到代码审查进行之前，代码还在不断地修改。不幸的是，这样就没有足够的时间来校验和测试了。如果这种情况发生了，最好是重新安排代码审查的时间以确保其效果。

另外，部门主管 和/或 接口开发者应该预定一间会议室和电话会议号码并提供给所有参与者，因为有可能某些项目组或审查组成员不在现场。用一个小时来审查两三个模板应该足够了；不过，需要的时间也随模板的大小和复杂度而不同。

在代码审查过程中，一位部门主管 和/或 接口开发者应该主持会议，而部门主管或项目经理做记录并分配行动事项。审查者应该在事前审阅过代码并准备好提问或提供反馈意见。

记录和行动事项（包括负责人）应该在代码审查后分发给所有参与者。如果代码审查产生了本质性的变更，或没有完成对所有代码的审查，就有必要安排第二次代码审查。不过，这必须在项目组内讨论以确定其可行性。

附录