Web 开发人员最常犯的 10 个错误:开发人员教程
已发表: 2022-03-11自从万维网这个词在 1990 年被创造出来,Web 应用程序开发已经从提供静态 HTML 页面发展为完全动态的、复杂的业务应用程序。
今天,我们拥有数以千计的数字和印刷资源,提供有关开发各种不同 Web 应用程序的分步说明。 开发环境足够“智能”,可以捕捉和修复早期开发人员经常遇到的许多错误。 甚至有许多不同的开发平台可以轻松地将简单的静态 HTML 页面转换为高度交互的应用程序。
所有这些开发模式、实践和平台都有共同点,并且它们都容易出现由 Web 应用程序的本质引起的类似 Web 开发问题。
这些 Web 开发技巧的目的是阐明在 Web 开发过程的不同阶段所犯的一些常见错误,并帮助您成为更好的开发人员。 我已经谈到了几乎所有 Web 开发人员都共有的一些一般性主题,例如验证、安全性、可扩展性和 SEO。 当然,您不应受我在本指南中描述的特定示例的约束,因为它们只是为了让您了解可能遇到的潜在问题而列出的。
常见错误 1:输入验证不完整
在客户端和服务器端验证用户输入是必须要做的! 我们都知道“不要相信用户输入”的明智建议,但是,由于验证导致的错误经常发生。
这个错误最常见的后果之一是SQL 注入,它年复一年地进入 OWASP 前 10 名。
请记住,大多数前端开发框架都提供了开箱即用的验证规则,这些规则非常易于使用。 此外,大多数主要的后端开发平台都使用简单的注释来确保提交的数据符合预期的规则。 实施验证可能很耗时,但它应该成为您标准编码实践的一部分,并且永远不要搁置。
常见错误 2:未经适当授权的身份验证
在我们继续之前,让我们确保我们在这两个术语上保持一致。 正如 10 个最常见的 Web 安全漏洞中所述:
身份验证:验证一个人是(或至少看起来是)特定用户,因为他/她已正确提供了他们的安全凭证(密码、安全问题的答案、指纹扫描等)。
授权:确认特定用户有权访问特定资源或被授予执行特定操作的权限。
换句话说,身份验证是知道实体是谁,而授权是知道给定实体可以做什么。
让我用一个例子来说明这个问题:
考虑您的浏览器将当前记录的用户信息保存在类似于以下内容的对象中:
{ username:'elvis', role:'singer', token:'123456789' }
更改密码时,您的应用程序会发出 POST:
POST /changepassword/:username/:newpassword
在您的/changepassword
方法中,您验证用户是否已登录并且令牌尚未过期。 然后根据:username
参数找到用户配置文件,并更改用户密码。
因此,您验证了您的用户已正确登录,然后您执行了他的请求,从而更改了他的密码。 过程似乎没问题,对吧? 不幸的是,答案是否定的!
此时验证执行操作的用户和更改密码的用户是否相同很重要。 存储在浏览器上的任何信息都可能被篡改,任何高级用户都可以轻松地将username:'elvis'
更新为username:'Administrator'
,而无需使用内置浏览器工具以外的任何其他工具。
所以在这种情况下,我们只负责Authentication
以确保用户提供了安全凭证。 我们甚至可以添加验证/changepassword
方法只能由经过Authenticated
的用户执行。 但是,这仍然不足以保护您的用户免受恶意尝试。
您需要确保在/changepassword
方法中验证实际请求者和请求内容,并实施请求的正确Authorization
,确保用户只能更改她的数据。
Authentication
和Authorization
是同一枚硬币的两个方面。 切勿单独对待它们。
常见错误 3:未准备好扩展
在当今高速发展、创业加速器和伟大创意在全球范围内即时传播的世界中,尽快将您的 MVP(最小可行产品)推向市场是许多公司的共同目标。
然而,这种持续的时间压力导致即使是优秀的 Web 开发团队也经常忽略某些问题。 扩展通常是团队认为理所当然的事情之一。 MVP 的概念很棒,但太过分了,你会遇到严重的问题。 不幸的是,选择可扩展的数据库和 Web 服务器并在独立的可扩展服务器上分离所有应用程序层是不够的。 如果您希望避免以后重写应用程序的重要部分,则需要考虑许多细节——这将成为一个主要的 Web 开发问题。
例如,假设您选择将用户上传的个人资料图片直接存储在 Web 服务器上。 这是一个非常有效的解决方案——应用程序可以快速访问文件,每个开发平台都提供文件处理方法,您甚至可以将这些图像作为静态内容提供,这意味着应用程序的负载最小。
但是当您的应用程序增长时会发生什么,并且您需要在负载均衡器后面使用两个或更多 Web 服务器? 即使您很好地扩展了您的数据库存储、会话状态服务器和 Web 服务器,您的应用程序可扩展性也会因为个人资料图像之类的简单事情而失败。 因此,您需要实施某种文件同步服务(这将有延迟并会导致临时 404 错误)或其他解决方法,以确保文件分布在您的 Web 服务器上。
为了避免这个问题,您首先需要做的是使用共享文件存储位置、数据库或任何其他远程存储解决方案。 将其全部实施可能会花费几个额外的工作时间,但这是值得的。
常见错误 4:错误或缺少 SEO
网站上不正确或缺少 SEO 最佳实践的根本原因是误导了“SEO 专家”。 许多 Web 开发人员认为他们对 SEO 有足够的了解,而且它并不是特别复杂,但事实并非如此。 掌握 SEO 需要花费大量时间研究最佳实践以及关于 Google、Bing 和 Yahoo 如何索引 Web 的不断变化的规则。 除非您不断尝试并进行准确的跟踪+分析,否则您不是 SEO 专家,也不应该声称自己是一名 SEO 专家。

此外,搜索引擎优化经常被推迟,因为一些活动是在最后完成的。 这是以 Web 开发问题为代价的。 SEO不仅仅与设置好的内容、标签、关键字、元数据、图像alt标签、站点地图等有关。它还包括消除重复内容、具有可抓取的站点架构、高效的加载时间、智能反向链接等。
与可扩展性一样,您应该从开始构建 Web 应用程序的那一刻起就考虑 SEO,或者您可能会发现完成您的 SEO 实施项目意味着重写您的整个系统。
常见错误 5:请求处理程序中的时间或处理器消耗操作
此错误的最佳示例之一是根据用户操作发送电子邮件。 开发人员经常认为直接从用户请求处理程序进行 SMTP 调用和发送消息是解决方案。
假设您创建了一个在线书店,并且您希望从每天几百个订单开始。 作为订单接收过程的一部分,每次用户发布订单时,您都会发送确认电子邮件。 一开始这不会有问题,但是当您扩展系统时会发生什么,突然收到数千个发送确认电子邮件的请求? 您要么收到 SMTP 连接超时、超出配额,要么您的应用程序响应时间显着降低,因为它现在处理的是电子邮件而不是用户。
在您尽快释放 HTTP 请求时,任何耗时或消耗处理器的操作都应由外部进程处理。 在这种情况下,您应该有一个外部邮件服务来接收订单并发送通知。
常见错误 6:未优化带宽使用
大多数开发和测试都在本地网络环境中进行。 因此,当您下载 5 个背景图像,每个图像都为 3MB 或更大时,您可能无法识别开发环境中 1Gbit 连接速度的问题。 但是,当您的用户开始在智能手机上通过 3G 连接加载 15MB 的主页时,您应该为自己的投诉和问题做好准备。
优化带宽使用可以极大地提升性能,而要获得这种提升,您可能只需要几个技巧。 许多优秀的 Web 开发人员默认做的事情很少,包括:
- 缩小所有 JavaScript
- 缩小所有 CSS
- 服务器端 HTTP 压缩
- 优化图像尺寸和分辨率
常见错误 7:没有针对不同的屏幕尺寸进行开发
在过去的几年里,响应式设计一直是一个大话题。 具有不同屏幕分辨率的智能手机的扩展带来了许多访问在线内容的新方式,这也带来了许多 Web 开发问题。 来自智能手机和平板电脑的网站访问量每天都在增长,而且这一趋势正在加速。
为了确保无缝导航和访问网站内容,您必须使用户能够从所有类型的设备访问它。
构建响应式 Web 应用程序有许多模式和实践。 每个开发平台都有自己的技巧和窍门,但有些框架是平台独立的。 最受欢迎的可能是 Twitter Bootstrap。 它是一个开源且免费的 HTML、CSS 和 JavaScript 框架,已被各大开发平台采用。 只需在构建应用程序时遵循 Bootstrap 模式和实践,您就可以毫无问题地获得响应式 Web 应用程序。
常见错误八:跨浏览器不兼容
在大多数情况下,开发过程都承受着巨大的时间压力。 每个应用程序都需要尽快发布,即使是优秀的 Web 开发人员也经常专注于提供功能而不是设计。 尽管大多数开发人员都安装了 Chrome、Firefox、IE,但他们在 90% 的时间里只使用其中一种。 在开发过程中使用一个浏览器是常见的做法,当应用程序接近完成时,您将开始在其他浏览器中测试它。 这是完全合理的——假设您有大量时间来测试和修复现阶段出现的问题。
但是,当您的应用程序进入跨浏览器测试阶段时,有一些 Web 开发技巧可以为您节省大量时间:
- 开发过程中不需要在所有浏览器中进行测试; 这是耗时且无效的。 但是,这并不意味着您不能经常切换浏览器。 每隔几天使用不同的浏览器,您至少会在开发阶段的早期发现主要问题。
- 小心使用统计数据来证明不支持浏览器。 有许多组织在采用新软件或升级方面进展缓慢。 在那里工作的成千上万的用户可能仍需要访问您的应用程序,并且由于内部安全和业务政策,他们无法安装最新的免费浏览器。
- 避免浏览器特定的代码。 在大多数情况下,有一个优雅的解决方案是跨浏览器兼容的。
常见错误 9:没有为可移植性做规划
假设是所有问题的根源! 谈到便携性,这句话比以往任何时候都更加真实。 您在 Web 开发中遇到过多少次问题,例如硬编码文件路径、数据库连接字符串或某个库将在服务器上可用的假设? 假设生产环境将匹配您的本地开发计算机是完全错误的。
理想的应用程序设置应该是免维护的:
- 确保您的应用程序可以在负载平衡的多服务器环境中扩展和运行。
- 允许简单而清晰的配置——可能在单个配置文件中。
- 当 Web 服务器配置不符合预期时处理异常。
常见错误 10:RESTful 反模式
RESTful API 已在 Web 开发中占据一席之地,并将继续存在。 几乎每个 Web 应用程序都实现了某种 REST 服务,无论是供内部使用还是与外部系统集成。 但是我们仍然看到不符合预期实践的损坏的 RESTful 模式和服务。
编写 RESTful API 时最常犯的两个错误是:
- 使用错误的 HTTP 动词。 例如使用 GET 写入数据。 HTTP GET 被设计为幂等和安全的,这意味着无论您在同一资源上调用 GET 多少次,响应都应该始终相同,并且应用程序状态不会发生变化。
未发送正确的 HTTP 状态代码。 此错误的最佳示例是发送响应代码为 200 的错误消息。
HTTP 200 OK { message:'there was an error' }
当请求没有产生错误时,您应该只发送 HTTP 200 OK。 如果出现错误,您应该发送 400、401、500 或任何其他适合已发生错误的状态代码。
可以在此处找到标准 HTTP 状态代码的详细概述。
包起来
Web 开发是一个非常广泛的术语,可以合法地包含网站、Web 服务或复杂 Web 应用程序的开发。
本 Web 开发指南的主要内容是提醒您,您应该始终小心身份验证和授权,计划可扩展性,并且永远不要仓促假设任何事情 - 或准备好处理一长串 Web 开发问题!