10 大常见的web开发错误

自从1990年有了www互联网这个概念后，web应用程序经历了从提供静态HTML页面到完全动态的复杂的业务应用的改变。

　　今天我们有各种各样的电子资源或图书来告诉我们如何开发各种各样的应用程序。现在的开发环境也足够智能，可以帮我们发现并修复很多错误。甚至有很多不同的开发平台提供方便的将静态页面转换为高度可交互的应用的功能。

　　所有的这些开发模式、时间和平台都有共同点，并且容易犯相似的错误因为web应用的本质。

　　本文意在揭示一些在Web开发过程的不同阶段作出的常见错误，并帮你减少这些错误。我涉及了一些几乎所有的web开发者都熟悉的话题，想验证、安全、扩展性和SEO等。当然你不应该被我所描述的具体情况限制住，列出这些只是为了在你遇到潜在的问题的时候有一些启发。

　常见错误 #1: 不完整的输入验证

　　客户端和服务器端的用户输入验证是一个简单但是必须要做的！。我们都知道“不要相信用户的输入”这句真理，但是源于验证的错误还是频繁发生。

　　验证错误的最常发生的结果就是 SQL Injection ，这是OWASP Top 10 中的一个。

　　一定要记住大多数的前端开发框架提供的挤开即用的验证规则都太简单。而且，大多数的后端开发平台都使用简单的注解来确保提交的数据是规则期望的。实现验证可能比较费时，但是这应该是你的编码习惯的一部分，而不应该放在一边不管。

　常见错误 #2: 认证没有合适的授权

　　在我们继续之前，请确保达成两个概念的意志。这是 10 Most Common Web Security Vulnerabilities所说的:

　　Authentication（认证）:校验一个人（或至少看起来）是某个用户，在他正确地提供哦你了他的安全证书后（密码，安全问题，指纹扫描等）

　　Authorization（授权）:确认某个用户是否有权获取某个资源，或执行某个行为。

　　用另一种方式说，认证是知道这个人是谁，授权是知道这个人能做什么。

　　让我们用一个例子来阐述这个错误。

　　想想看，你的浏览器拥有一个已登录的用户的信息，大概是这样的一个对象

1 2 3

{    username: 'elvis' ,      role: 'singer' ,      token: '123456789' }

　　当做一个更换密码的操作时，你的应用接到post请求

1	POST /changepassword/:username/:newpassword

　　在你的/changepassword方法, 你检验到这个用户已经登录了并且  token没有过期. 然后用username参数找到这个用户的信息, 并改变用户的密码。

　　那么，你验证了这个用户是已经登录的，然后你执行力他的请求也就是改变了他的密码。看来进展正确，对吗？不幸的是，并不是这样的。

　　关键点是校验改变执行这个操作的用户和要改变的密码的用户同一个。浏览器上存储的任何信息都可以被篡改，并且任何一个高级点的用户只适用浏览器自带的工具都可以轻易地把username:'elveis'改成username:’Administrator'.Administrator'.

　　在这种情况下，我们仅仅关心了认证。我们甚至可以把/changepassword方法改成只有认证的用户才能执行。但是，这还不能在很多恶毒的请求面前保护你的用户们。

　　你需要在你的 /changepassword 方法里验证实际的请求者和请求的内容，并且实现用户只能修改他自己的数据这样的授权。

　　认证和授权是同一枚硬币的两面，永远不要把他们分开对待。

　常见错误#3: 没有准备好扩展

　　现在的世界主流是快速发展高速启动的,并且伟大的想法迅速覆盖全球, 将 MVP (最小可行产品)尽快推出到市场上是很多公司的共同目标

　　然而, 时间压力导致开发团队经常忽略了某些问题. 扩展性是团队们理应考虑到的。 MVP的概念很伟大, 但是不久之后,你会遇到一系列的问题. 不幸的是, 选择可扩展的数据库和web服务器并把不同的应用层放到独立的可扩展的服务器上还不够. 你还有很多需要考虑的细节来避免在以后大改自己的应用。

　　例如，假设你选择直接在web服务器上存储用户的上传照片。这是一个完美的可行的方案--应用可以快速的获取到这些文件，在每个开发平台都有处理文件的方法，并且你都可以把这些图片以静态内容的方式提供，这意味这着应用程序的最小负载。

　　但是当你的应用规模变大，你需要两个或更多的负载均衡器的web服务器的时候呢？即使你漂亮的扩展了你的数据库存储，session状态服务器和web服务器，你的应用还是因为资料图片这样的小事扩展失败了。这样，你需要实现多种文件同步服务（这样会有延迟并且会造成短暂的404错误）或其他的解决方法来确保这些文件能在你的web服务器间蔓延。

　　为避免这样的问题，你需要做的就是在一开始就使用共享的文件存储位置，数据库或其他任何的远程存储解决方案。这些可能会花费一些额外的工作时间，但是和以后可能会遇到的麻烦比起来还是值得的

　常见错误 #4: 错误SEO的或没有 SEO

　　web站点没有或者错误的搜索引擎优化的根本原因是"SEO专家"的误导。许多web开发者认为自己足够了解SEO并且认为它没有那么复杂，但事情并不是这样的。 掌握SEO 需要大量的时间来寻找最佳实践以及Google、Bing、雅虎等如何索引web的千变万化的规则一 除非你不停的实验并且准确地跟踪+分析, 你都不是一位SEO专家, 你也不应该说自己是.

　　此外,SEO经常被推迟到最后才做。这需要很大的代价. SEO不仅仅是关于设置良好的内容、标签、关键字、 meta-data,、图像的 alt 标签,、site map等等. 它还包括消除重复的内容、拥有可抓取的网站架构、高效的加载时间、智能的反向链接等等。

　　就像扩展性一样，你应该在开始构建web应用程序的时候就考虑到SEO，不然你可能会发现完成SEO实现工程意味着重写整个系统。

　常见错误 #5: 请求处理中的耗时动作

　　这个错误的最好的例子就是一个基础用户的动作发送邮件。开发者们经常认为在用户请求处理器上构造一个SMTP请求并发送一条邮件消息就可以了。

　　假设你创建了一个网上书店并且你期望每天要处理数百个订单。 作为你的订单处理的一部分, 每个用户提交订单post请求后你回去发送一封确认邮件。 最开始的时候可能没有问题，但是当你的系统级别变大，你突然收到数千个发送确认邮件的请求呢？ 你就会遇到SMTP连接超时、邮件配额不足、 or your application response time 或者你的应用程序因为要处理邮件而不是用户请求导致响应时间显著提升。

　　任何费时的动作都应该用另外一个线程来处理，从而尽快地释放掉http请求。这种情况下，你因该有一个外部的邮件服务来接收订单并发送通知。

　常见错误 #6: 没有优化带宽使用

　　大多数的开发和测试都是在本地网络环境下进行的。所以当你下载5个3MB大小的背景图片的时候，以你的1Gbit的开发环境连接可能不会有问题。但是当你的用户在他们的手机上用3G网开始加载你的15MB的首页的时候, 你就应该为自己准备一个投诉邮件列表了。

　　优化网络带宽使用可以带来极大的性能提升，并且你可能是需要一些小技巧来实现这样的提升。这有一些规范的团队默认做的事情，包括:

1. 缩小所有的JavaScript

2. 缩小所有的CSS

3. 压缩服务器端的HTTP

4. 图片尺寸和分辨率的优化

　常见错误 #7: 没有为不同大小的屏幕开发

　　自适应设计一直是近几年的一个大话题。带有不同大小的屏幕的智能手机的急剧增多带来了很多新的获取网上内容的方式。通过只能手机和平板电脑访问web的数量每天都在增加，并且这种趋势还在加速。

　　为了确保无缝的导航和浏览，你必须使用户能够用各种各样的设备来访问网站。

　　关于自适应web应用设计有很多模式和实践。各种开发平台都有自己的提示和技巧。但是也有一些开发框架是跨平台的。其中最有名的可能是 Twitter Bootstrap. 它是一个开源的 HTML, CSS, 和JavaScript框架,并且已经被各种各样的开发平台接纳。 在构造应用的时候只需要采用Bootstrap模式, 你就可以不费力的获得自响应web应用程序。

　常见错误 #8: 跨浏览器不兼容

　　大多数情况下，开发过程都是在巨大的时间压力下进行的。每个应用都需要尽早地发布，开发者常常关注于交付功能而不是设计。尽管大多数的开发者都安装了 Chrome，Firefox 和 IE，但是他们90%的时间只使用其中的一个。一个常见的例子就是在一个浏览器下开发并且只在应用快完成的时候用其他的浏览器来测试。这样十分有道理–假如你有很多时间来测试并修改这个阶段出现的问题的话。

　　然而，当你的应用到达跨浏览器测试阶段的时候还是有一些技巧来帮你显著地节省时间的:

1. 在开发的时候不需要在所有的浏览器下测试，这很费时间并且低效. 但是这不是说你就可以不经常切换浏览器了.每隔几天换一个浏览器, 在测试阶段之前你至少可以发现最主要的那些错误。

2. 不要用统计数据来为不支持某个浏览器辩解。有很多组织采纳新软件或升级很慢。可能有大量在那工作的用户要访问你的网站，但是他们因为内部安全或商业策略不能安装最新的免费浏览器。

3. 避免使用特定于浏览器的代码。在大多数情况下都有一个优雅的跨浏览器兼容解决方案。

　常见错误 9: 没有考虑可移植性

　　想当然是万错之源! 对于可移植性来说, 尤为如此.  你有见过几个人, 把文件路径, 数据库连接字符串直接写在代码中. 你又见过多少人事先假设服务器上已经安装这个库那个库的? 事先假设应用的最终运行环境, 跟你本地的开发环境一致, 本身就是个错误.

　　理想的应用安装配置要做到维护轻松简单:

1. 要确保你的应用具有可扩展性, 能在负载平衡的多服务器环境中运行.

2. 配置要简洁明了, 并且集中保存在一个配置文件中.

3. 当服务器配置不当, 导致错误出现时, 要能处理异常. 

　常见错误 10: 误用 RESTful

　　RESTful API 在 web 开发中占有一席之地. 无论是在系统内部使用, 还是集成到外部系统中, 几乎每个 web 应用都会用到 REST 服务. 尽管如此, 还是有很多人在使用 RESTful 时候, 存在这样那样的问题.

　　调用 RESTful API 常见的错误有:

1.  HTTP 动词没写对. 比如, 用 GET 提交数据. HTTP GET 旨在安全与幂等, 也就是说, 对于同一个资源, 无论你用 GET 调用多少次, 返回的结果都是一样的, 应用的状态也不会发生任何变化.

2. HTTP 状态编码没用对. 最常见的例子是, 明明有错误, 却返回编码 200.

   1 2 3

   HTTP 200 OK   {     message: '出错了'   }

　　返回 HTTP 200 OK 的前提是, 提交的请求没有导致服务器端出现错误. 否则, 就应该根据错误信息, 返回相应的错误编码, 如: 400, 401, 500 等等.

　　更多的 HTTP 状态编码请查看这里.

　总结

　　Web 开发涉及的领域很广, 包括网站, web service, 功能复杂的 web 应用等.

　　重点是在处理身份验证和授权的时候要细心, 扩展性要事先计划好.  总之凡事多想想, 人畜无害.