Web开发人员最易犯下的十种常见错误
对于如何完成同一项任务，摆在我们面前的方案选项似乎无穷无尽，特别是在开发一套能够运作在现代网络环境之下的网站时。Web开发人员首先需要挑选一套Web托管平台及底层数据存储机制，并利用由提供的工具编写HTML、CSS以及JavaScript代码，考虑如何实现设计效果以及哪些潜在JavaScript库/框架可能会被包含于其中。
一旦选择被细化到这一层面，我们就能在网络上找到大量相关文章、论坛以及示例，并借此了解如何打造出更为出色的Web使用体验。然而无论有多少条道路可供选择，开发人员都有可能在自己的选项当中迷失方向。虽然其中有些错误与特定方案相关，但也有一些共同的挑战横亘在每一位Web开发人员面前。
因此通过一系列研究、经验与近期观察，我整理出了下面这份十大常见错误清单——目前确实有很多Web开发人员还在饱受其困扰，而我也给出了自己的解决意见。
以下这份清单不分先后顺序。
1. 编写陈旧的HTML代码
错误: 互联网在发展早期只提供有限的几种标记选项，而如今这类选项已经变得相当丰富。然而某些陈旧的陋习当下仍然存在，而且很多从业者在编写HTML代码时好像仍然活在上个世纪。具体实例包括使用<table>元素进行布局、在更适合使用其它语义标签时继续使用<span>或者<div>元素，还有使用诸如<center>或者<font>等不支持当前HTML标准的标签，甚至利用大量 将条目排布在页面当中。
影响: 编写上述带有浓郁上世纪风格的HTML代码可能导致标记复杂程度过高，进而在不同浏览器中出现彼此相异的运行效果。此外，我们也没有任何理由在微软Edge甚至是IE新版本（包括IE 9、10与11）当中使用此类复杂的标记方式。
如何避免: 不要再使用<table>元素处理内容布局了，另外严格限制其在显示表格数据时的使用频率。充分了解当前有哪些标记选项可供使用，具体可以点击此处查看whatwg.org中的汇总。使用HTML代码来描述页面内容，而非定义内容的显示方式。要正确显示设计内容，请优先使用CSS。
2. “在我的浏览器中明明没有问题……”
错误: 开发人员可能会偏爱某款特定浏览器或者极度鄙视另一款浏览器，而且会将这种带有偏见的观点带入网页测试工作当中。在某些情况下，我们甚至有可能将来自网络的示例代码直接纳入到项目当中，而并没有测试其能够在其它浏览器中正确得以渲染。再有，某些浏览器会在样式方面拥有不同的默认值设定。
影响: 编写一个只适用于特定浏览器的站点很可能会给使用其它浏览器的用户带来非常糟糕的访问体验。
如何避免: 在开发过程中针对每一款浏览器及其版本进行网页测试显然是不现实的。不过我们可以每隔特定一段时间就利用多种浏览器来检查自己的网站是否能够正常运作，这算是种比较理想的折衷办法。目前无论大家使用哪种首选开发平台，都有大量免费工具可以帮助各位实现测试工作，具体包括免费虚拟机或者站点扫描工具。Browsershots或者BrowserStack等网站还能够提供快照，帮助我们了解特定页面在不同浏览器/版本/平台上拥有怎样的渲染效果。而Visual Studio等工具也能够利用不同浏览器显示我们目前正在开发的单一页面。当利用CSS进行设计时，请记得对所有默认值进行“重新设定”。
如果大家的站点使用了任何面向单一浏览器所创建的特殊CSS功能，那么请留心处理各类提供程序前缀，包括-webkit-、moz-或者-ms-。作为行业趋势指南，我建议大家认真查阅下面提供的各参考站点（皆为英文原文）：
• 微软Edge开发博客: A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent…
• QuirksMode.org: CSS vendor prefixes considered harmful
• Bruce Lawson: On Internet Explorer supporting -webkit- vendor prefixes
虽然以上参考资料已经解释了我们该如何避免提供程序前缀及其相关理由，但大家也可以点击此处通过具体建议了解更多解决办法（英文原文）。
3. 注意调整格式
错误: 通过提示的方式向用户索取信息（特别是以输入文本字段的方式），并单纯假设该数据能够如预期般从用户处获得。
影响: 在默认信任用户输入信息时，我们有可能面临大量意料之外的麻烦。如果所要求的数据未能被正确获得，或者所获得的数据与底层数据格式不兼容，那么页面很可能发生错误。更为严重的是，某些针对网站数据库的故意违反行为甚至足以构成注入式攻击。
如何避免:第一条建议就是要确保用户能够清晰地了解到网站要求其输入哪种数据类型。就目前而言，单纯给出“请输入地址”的提示可能代表着用户需要输入公司地址、家庭住址甚至是电子邮箱地址！除了作出针对性说明之外，我们还应当充分发挥现代HTML当中所提供的数据有效性验证技术。无论数据在浏览器端是否被视为有效，我们务必要在服务器端同样对其进行验证。永远不要在未确认字段内容符合数据类型要求的情况下，允许用户所输入的多行索引T-SQL语句使用站点数据。
4. 反应速度太过缓慢
错误: 对于包含有大量高品质图像以及/或者图片的页面，我们应当利用<img>元素对其高度及宽度属性进行调整。而来自页面中的CSS以及JavaScript等文件链接往往也体积庞大。另外，源HTML标记的存在经常会带来不必要的复杂性与加载负担。
影响: 如何某个页面的完全渲染时间过长，那么一部分用户可能会放弃访问甚至不耐烦地重新加载整个页面。在某些情况下，如果页面的处理时耗太长，甚至可能引发其它未知错误。
如何避免: 不要以为互联网的传输速度越来越快就可以毫无顾忌地设计出臃肿的页面成果。相反，将往返于浏览器与站点之间的每一点流量都视为运营成本。图片可以说是页面臃肿问题的罪魁祸首，因此为了最大限度降低图片给页面带来的加载成本，请从以下三个角度进行考量：
- 问问自己：“页面中所包含的所有图片都是必要的吗？”如果答案是否定的，那么去掉那些不必要的图像。大家也可以点击此处对自己的网站进行扫描，从而获取建议以了解哪些图片可以进行压缩。
- 利用Shrink O’Matic或者RIOT这类工具来将自己的图片尺寸控制在最低水平。
- 采取图片预加载方案。这虽然不会降低初始下载的具体成本，但却能够让站点上其它使用相关图片的页面拥有更出色的载入速度。
另一种降低成本的方式则是压缩CSS与JavaScript链接文件的体积。目前我们可以选择大量工具来帮助自己完成这项评估工作，其中包括Minify CSS以及Minify JS。
在结束第四点错误之前，我们还得提一句，请在HTML当中使用<style>或者<script>标签之前做出准确的判断（同第一点）。
5. 编写出“应该能够起效”的代码
错误: 无论是JavaScript还是运行在服务器端的代码，作为开发人员我们都应当通过测试来验证其实际运行效果，从而保证其一定能够在部署之后发挥预期作用。大家的代码在执行时不应引发任何错误，因为在此之前我们已经对其进行了充分测试。
影响: 包含未经测试代码的站点很可能以极其糟糕的方式在供最终用户使用时产生各类错误。这不仅会严重影响到用户的实际感受，同时错误信息内容的具体类型也可能会向打算入侵站点的黑客透露那些本该受到严格保护的细节线索。
如何避免: 人是不可避免会犯错的，因此我们应当将这种哲学思维带入编程工作。在JavaScript当中，我们应当确保利用一切最佳技术手段来避免错误的发生，并在其实际出现后及时捕捉。另外一种有助于提高代码质量的办法就是针对未来可能出现的变更对代码进行单元测试。
服务器端的代码错误必须要在用户尚未察觉时即被发现并加以修复。只向用户显示必要的错误提示，而且请大家再用点心，把自己的HTTP 404错误页面设计得漂亮一点。
6. 编写fork代码
错误:出于支持所有浏览器及其各个版本的崇高理念，某些开发人员会创建不同的代码来对应每一种可能的运行场景。这些代码以if语句循环为基础，并针对各类实际方向提供对应的fork版本。
影响: 随着浏览器版本的不断更新，对fork代码文件的管理将变得非常复杂甚至无法实现。另外正如第一点中所言，这样做其实完全没有必要。
如何避免: 在代码内部进行功能检测，而非针对浏览器/版本着手。功能检测技术方案的出现显著降低了代码数量，而且也保证了代码更易于阅读并管理。大家可以考虑利用Modernizr等库来帮助自己在实现功能检测的同时，以自动化方式为那些已经无法适应HTML 5或者CSS 3的陈旧浏览器提供后备支持。
7. 采用非响应式设计
错误: 在进行站点开发工作时，假设用户拥有与开发人员/设计师相等同的显示器尺寸。
影响: 当在移动设备或者某些超大型屏幕上查看站点时，用户体验也会因此受到影响——例如无法查看到页面中的某些重要方面，甚至无法导航至其它页面。
如何避免: 将响应式设计纳入开发考量。在站点当中使用响应式设计，甚至以同样的方式进行图片尺寸调节，在这方面Bootstrap这款高人气库绝对能够帮上各位大忙。
8. 构建毫无意义的页面
错误: 在面向公众的页面当中包含有实用性内容及信息，但不提供任何与搜索引擎相关的关键字、标签及提示。不提供无障碍访问功能。
影响: 在这种情况下，用户将很难通过搜索引擎找到我们的页面，这将导致其难以甚至根本无法获得理想的访问量。另外页面内容需要经过精心设计，以保证不会在用户查看过程中操作其视力。
如何避免: 使用SEO（即搜索引擎优化）机制并支持HTML访问性。在SEO方面，请确保添加标签以提供包含关键字及相关描述的有意义页面内容。要实现更出色的可访问体验，大家可以检查每一条<img>或者<area>标签之下的alt="your image description"属性。当然，单纯做到这些还远远不够，大家可以点击此处访问了解页面是否与Section 508相兼容。
9. 开发出的页面中包含太多刷新操作
错误: 创建的站点在每项操作当中包含太多页面刷新步骤。
影响: 与臃肿页面类似（见第四点），页面加载时间这一重要性能指标也会因此受到影响。如果刷新过多，用户体验将缺乏流畅性，而每次内容更新都可能造成页面的短时（或者长时）重置。
如何避免: 解决这一问题的便捷方式之一在于检查各项操作是否真有必要与服务器端取得联系。举例来说，如果无需依赖服务器端资源进行处理，那么我们可以利用客户端自身的脚本提供即时性结果。当然，大家也可以使用AJAX技术或者更进一步，选择单页面应用SPA方案。目前各类高人气JavaScript库/框架都提供众多能够简化这方面难题的办法，例如JQuery、KnockoutJS以及AngularJS。
10. 工作强度太大
错误: 开发人员可能会投入太多时间来创建Web内容。这些时间可能被用于进行重复劳动，或者简单地输入大量文本内容。
影响: 在网站刚刚上线或者进行后续更新时，开发人员投入其中的时间往往太过夸张。而当有其他开发者能够用更短时间及更少精力实现同样的效果时，我们投入的时间成本将得不到理想的回报。这种简单重复的体力劳动会导致错误的出现，而诊断错误往往比开发项目更耗费时间。
如何避免: 自行寻找解决办法。我们可以考虑使用新型工具或者新的工作流程技术来搞定开发中的每个阶段。举例来说，大家当前正在使用的代码编辑器与Sublime Text或者Visual Studio相比孰优孰劣？无论大家所使用的是哪一款代码编辑器，您有没有深入挖掘过其中的功能设定？也许只需要花点零散时间认真阅读说明文档，我们就能找到足以在未来帮自己节约下数小时甚至更长时间的新用法。
另外不要错过互联网上任何可能帮得上忙的现成工具！举例来说，在dev.modern.ie网站上搜索那些能够简化测试（涵盖多种平台及设备）及故障排查工作的工具。
大家也可以通过自动化流程降低时间要求与出错机率。例如，我们可以使用Grunt等工具来自动完成文件体积压缩等任务。另外，Bower则可以帮助大家更为高效地管理库与框架。
那么Web服务器本身又存不存在优化空间？我们可以选择微软Azure Web Apps，并借此快速创建出一个几乎适用于任何开发场景的站点，这对于扩展业务绝对可算理想方案！
总结陈词