Web应用上线之前程序员应该了解的技术细节

【伯乐在线注】：《Web 应用上线前，程序员应考虑哪些技术细节呢？》这是 StackExchange 上面的一个经典问题贴。

最赞回复有 2200+ 顶，虽然大多数人可能都听过其中大部分内容，但应该会有你没有深入了解的内容。一起来看看。

问题

Web 应用上线前，程序员应考虑哪些技术细节呢？ 如果 Jeff Atwood 忘记把 HttpOnly cookies、sitemaps 和 cross-site
request forgeries 放在同一个网站，那我会把什么重要的东西也会忘掉呢？

我以一个 Web 开发人员的角度思考这个问题，别人为网站进行美化设计并填充内容。因此，他们可能认为可用性和内容比平台更重要，程序员在这方面没多少发言权了。而你需要考虑到的是：你实现平台的稳定性、安全性和满足其它商业目的（如成本不要太高、耗时不要太长和网站排名）。

而以一位已经在相当可信的环境下，完成了几个企业内网应用程序项目的开发者角度思考，并在一个流行且权威网站上为整个糟糕的万维网打响第一枪。

另外，我希望能回答得更加具体一点，而不仅仅是一个“Web标准”这样模糊的答案。通过 HTTP 传输的 HTML、JavaScript、CSS 是必须要掌握的，特别是针对那些资深 Web 开发者。所以，超出上述范围，哪一个标准？在什么环境下，并且为什么这样？麻烦您提供一个跳转到该标准说明的链接。

最佳回复

下面列表里的大部分内容，我们大多数人都应该已经听过了。所以在这之前，你可能只有一到两个项目没有深入查看和理解透彻，或甚至没听过。

界面和用户体验

应意识到浏览器实现标准不一致，并确保你的网站能在所有主流浏览器上合理运行。至少起码在最近的
Gecko 引擎（Firefox）、Webkit 引擎（Safari 和一些移动端浏览器）、Chrome、支持
IE 浏览器（利用 Application Compatibility VPC Images 进行测试）和 Opera。另外，也要考虑浏览器在不同操作系统下是如何渲染网站的。
要考虑到用户除了通过主流浏览器来浏览网站外，还有其它方式：手机、屏幕阅读器和搜索引擎等。 这有一些相关信息：WAI 和
Section508，移动开发：MobiForge。
Staging：如何部署更新而不影响用户。进行一次或多次测试或 staging 环境可用来实现架构的更改，确保代码或全部内容能部署在一个可控的方式而不会破坏任何东西。有一个自动化的方式部署批准改变网站。最有效地实现方法是使用版本控制系统(Git、CVS、Subversion 等)和一个自动构建机制( Ant、 NAnt 等)。
不要向用户直接显示不友好的错误提示。
不要以纯文本的方式显示用户的 Email 地址，否则他们将会收到该死的垃圾邮件。
为用户链接添加属性 rel = “nofollow” 来 避免垃圾邮件。
为你的网站建立深思熟虑的限制 – 这也属于下面将要讲到的安全性。
学会如何实现网页的 渐进增强。
POST 提交成功后，要重定向，以防止再次提交引起刷新。
别忘了考虑到访问性（accessibility，即残障人士如何使用网站）。这一直是好想法并且有时这是法定要求。WAI-ARIA 和 WCAG 2 都是这方面很好的资源。
别让用户思考如何操作。

安全性

阅读 《OWASP开发指南》，它提供了全面的网站安全指导。
知道注入相关的知识，尤其是
SQL 注入，并知道如何防止它。
千万别相信用户的输入，也不要相信任何请求（其中包括 cookies 和 表单域的隐藏字段值！）。
使用 salt（密码散列技术）散列密码并为你的彩虹表行使用不同的 salts 来防止 rainbow 攻击。 使用一个效率较低的散列算法，如 bcrypt （ 久经试验的）或 scrypt （更新，甚至更强）（1，2），来存储密码。（如何安全地存储一个密码）。NIST
也批准用 PBKDF2 散列密码，FIPS 认可
.NET （想了解更多信息，请 点击）。应避免直接使用 MD5 或 SHA 家族。
别尝试提出你自己喜欢的认证系统。这很容易在微妙且不可测的方式下出现错误，而且你可能直到被入侵才知道发生什么事
了解 处理信用卡的规则。（也可以看看这里这个问题）
在登录页和任何涉及敏感数据的网页（如信用卡信息），使用
SSL / HTTPS。
防止 会话（session）劫持。
避免 跨站脚本攻击（XSS）。
避免 跨站请求伪造攻击（CSRF）。
避免 点击劫持。
系统补丁要保持更新。
保证数据库连接信息安全。
你自身要保持关注最新的攻击技术和影响你平台的漏洞。
阅读 Google 的《浏览器安全手册》。
阅读 《Web应用黑客手册》。
考虑
最小特权原则。尝试将你的应用程序在 非根模式（non-root）的服务器下运行。（tomcat
案例）

性能

如有必要，就实现缓存。了解和正确地使用 HTTP 缓存（caching）和 HTML 5 离线缓存。
优化图片 – 别使用一个 20 KB 大小的图片做为一个重复背景。
学习如何用 gzip / deflate 压缩内容（deflate更好）。
合并多个样式表单或脚本文件，以减少浏览器发送请求次数，而且要利用 gzip 压缩文件之间重复的部分。
浏览 Yahoo Exceptional Performance（雅虎优越性能）网站，里面有很多优秀的指引，其中就包括提高前端性能和它们的 YSlow 工具（需要 Fixfox、Safari、Chrome 或 Opera）。另外，Google
PageSpeed （以 浏览器扩展 的方式）是另一个测试性能的工具，而且它也会优化你的图片。
为较小且有关联的图片使用
CSS 图片精灵 技术，如工具栏（看“把 HTTP 请求减到最低”那点建议）
繁忙 Web 站点应考虑将 网页的内容分开存放 在不同的域名下。特别是…
静态内容（也就是图片、CSS、JavaScript 和无需通过 cookies 获取的一般内容）应放进独立且 不使用 cookies 的域名上，因为所有域名和其子域名为客户端生成的 cookies 都会伴随请求发送回给自己。 一个很好的选择是使用内容分发网络（CDN），但要考虑到这种情况：CDN（包括可替代的 CDN）可能会失效，这时本地副本能代替它来进行传输。
将浏览器渲染页面所需 HTTP 请求数量最少化。
用Google的 Closure Compiler 压缩 JavaScript，当然也可以使用 其他压缩工具。
确保有一个 favicon.ico 文件在网站的根目录，也就是说 /favicon.ico。浏览器会自动请求它，即使在 HTML 中并未提及到它。如果没有 /favicon.ico，那么请求返回的结果是 大量的 404 错误，这将会耗尽服务器的带宽。

SEO（搜索引擎优化）

使用“对搜索引擎友好”的链接，比如说 example.com/pages/45-article-title 优于 example.com/index.php?page=45。

是 googlebot（Google 的 web 爬虫）用来替换 #! 的

。换句话说，

./#!page=1

会被Google搜索引擎转成

./?_escaped_fragments_=page=1。

（通常来说
URL 中的 # 后的东西都不会被传到服务器上，所以，为了要让 Google 可以抓取 AJAX 的东西，你需要使用 #!，而 Google 会把“#!”转成“_escaped_fragment_”来向服务器发请求，Twitter 的大量链接者是#!的，比如：https://twitter.com/#!/your_activity —— 陈皓注）。另外，用户也许会使用 Firefox
或 Chromium，那么

history.pushState({"foo":"bar"}, "About", "./?page=1");

是一个很不错的命令。因为即使地址栏上的地址改变了，页面也不会重新加载。这可让你使用

?

而不是

#!来

动态加载内容了，也告诉服务器，当下次访问该页面时给该链接发邮件，AJAX
无须再发送一个额外的请求了。
别使用
“点击这里” 这类的链接。这是浪费一个 SEO 的机会，并且会对使用屏幕朗读器用户造成困惑。
拥有一个 XML 网站地图，它的默认路径最好是 /sitemap.xml。
当你有多个 URL 指向同一个内容时，请使用

<link rel="canonical" ... />。这个问题可利用 Google Webmaster Tools 解决。

使用 Google Webmaster Tools 和 Bing Webmaster Tools。
在一开始就正确安装 Google Analytics （或一个开源的分析工具，如 Piwik）。
要知道 robots.txt 和搜索引擎爬虫是如何工作的。
重定向请求（使用 301 永久性移走），要求 www.example.com 重定向到

example.com

（或反过来），从而防止分裂两个站点之间的谷歌排名。
知道并不是所有的爬虫都是好的，有些爬虫的行为并不好。
如果有非文本内容（如视频等）需要添加到 Google 网站地图的话，你可以到 Tim Farley’s answer 看看，里面有一些关于这方面的，而且不错的信息。

技术

搞懂 HTTP 协议，以及诸如 GET 、POST、sessions 和 cookies 这些概念，而且要知道“无状态”是什么意思。
根据 W3C 文档 编写你的
XHTML / HTML 和 CSS 代码，并确保它们 有效。这里的目的是避免浏览器的怪异模式，并让它们更容易在非传统浏览器（如屏幕阅读器和移动设备）上运行。
搞懂浏览器是如何处理 JavaScript。
搞懂页面上的 JavaScript、样式表单和其他资源是如何加载和运行的，并考虑它们对性能的影响。现在广泛认同的做法是：除了通用脚本，如 analytics apps 或 HTML5 shims，将其它脚本放到页面底部。
搞懂 JavaScript 沙箱如何工作，特别是你打算用 iframes。
要意识到 JavaScript 可能会被禁用，因此 AJAX 也只是一个扩展，不一定会被运行。即使大多数普通的用户并不会理会 JavaScript 被禁用，但要记住
NoScript 正变得更流行，移动设备可能默认禁止 JavaScript，而且 Google 在索引你的网站时，并不会执行大多数 JavaScript。
学会区分 301 和 302 重定向 的不同之处（这也是一个 SEO 问题）。
尽可能多地学习你部署平台的相关知识。
考虑使用 Reset Style Sheet（重置样式表单） 或 normalize.css。
考虑使用 JavaScript 框架（如 jQuery、MooTools、Prototype、Dojo
或 YUI 3），它们会解决很多在使用 JavaScript 操作 DOM 时的浏览器差异问题。
把性能和 JS 框架合在一起讨论，考虑使用诸如 Google Libraries API 服务来加载框架， 以至于浏览器能使用已缓存框架的副本，而不是从你的网站下载同样的副本。
不要重复造轮子。在做任何事之前，可搜索一个组件或案例是如何实现的。但有 99% 机会是其它人已经做过了，并发布了 OSS 版本的代码。
另外，即时确定你需要的是什么，但也别使用太多库。特别是在 Web 客户端，保持轻量、快速和灵活非常重要。

BUG 修复

要明白你将花费 20% 时间敲代码，而剩下 80% 的时间是在维护你的代码，所以代码质量很重要。
建立一个良好的错误报告解决方案。
为用户提供一个能向你提交建议与批评的系统。
为将来的维护和技术支持人员撰写文档，解释清楚系统是怎么运行的。
经常备份！（并确保那些备份是可用的）除了备份机制，你还必须有一个恢复机制。
使用版本控制系统来存储你的文件，如 Subversion、Mercurial 或 Git。
别忘记进行验收测试。框架（如 Selenium）能为你提供相应帮助。特别是如果你想完全自动化测试，也可通过使用持续集成工具，比如 Jenkins。
在网站运行时，要确保你有足够的日志，当然你可以使用框架，如 log4j、log4net 或 log4r。因为当你的网站某部分发生错误，你将需要一种方式找出是哪里发生的。
当日志能确保你能同时捕捉到处理异常和未处理异常。那么可通过记录/分析输出的日志，可显示网站的关键问题出现在哪里。

其他

服务器端和客户端都要监控和分析（应主动而不是被动）。
使用能与用户保持联系的服务（如 UserVoice 和 Intercom，或其它类似的工具）。
采用 Vincent Driessen 的 Git 分支模型（Git branching model）。

文中有很多省略掉的东西，并不是因为它们不是有用的答案，而是它们过于详细，且超出本问题的范围。而对于想懂得更多的人来说，他们希望学到更多的东西，因此他们应该知道这些概述。另外，我也欢迎大家编辑补充这个答案，因为我可能忽略了一些东西或犯了一些错误。