Web 开发人员应避免的 5 个错误

本文最初发表于 DEV 网站，经原作者 Liviu Lupei 授权，InfoQ 中文站翻译并分享。

我们都有自己的做事方式，但是总有一些可以避免的错误。

下面是一些我最常遇到的问题：

1 使用过于复杂的技术栈

你可以使用一个简单的技术栈来构建能够处理数百万用户的应用程序。

下面让我们来看看HEY使用了哪些技术栈：

• 后端为 Vanilla Ruby on Rails，运行在 edge 上。

• 前端为 Stimulus、Turbolinks、Trix + NEW MAGIC。

• 数据库为 MySQL（用 Vitess 进行数据分片）。

• Redis 用于短期数据 + 缓存。

• ElasticSearch 用于索引。

• AWS/K8S

这条推文是 David Heinemeier Hansson 发布的，他是 Ruby on Rails 的创始人，也是 Basecamp 和 HEY 的创始人。

就像你预料的那样，评论中有很多观点：

Nedim F：

我觉得我遗漏了什么。对于这么多数据来说，Mongo 是完美的选择。另外，为什么这种高端产品没有使用 Go 或 Ruby 编程语言呢？

Popa Adrian Marius：

尽管 HEY 用到的栈枯燥乏味，但却非常有效。现在，我会选择 TypeScript 和 React，而不是 Ruby on Rails 和 MySQL。

如果你对 MySQL 持怀疑态度，你应该知道Uber 在 2016 年就从 Postgres 转而使用 MySQL吧？

有时候，使用普通的 JavaScript 也是完全没有问题的。

诸如 React 和 Angular 这样的技术背后的想法是，将其用于大型 Web 应用程序，在这些应用程序中，你需要在许多不同的用户界面元素之间同步状态。

在许多情况下，轻量级的东西可能更适合。

如果你不是在开发一个被数百万人使用的应用程序的话，你可能还不应该将重点放在将应用程序分离成微服务上。

当你的应用程序开始拥有数百万的用户时，你可以稍后再处理这个问题。

出人意料的是，如果你对单体架构进行适当的扩展和优化，它仍然能够处理 600~800 万用户。

2 忽略可访问性

我们应该开发一个包容性强、人人都可以访问的网站。

残疾有六个主要的方面：

• 视力残疾

• 听力残疾

• 肢体残疾

• 精神残疾

• 语言残疾

• 多重残疾

从 Addy Osmani 写的这篇文章《Web 开发者的可访问性贴士》（Accessibility Tips for Web Developers）中，我了解到了很多关于可访问性方面的知识。

关于网站的可访问性的立法仍处于灰色地带，但这一状况可能在不久的将来会有所改变，不遵守规定的公司可能会面临类似于 GDPR 的巨额罚款。

3 忽略跨浏览器兼容性

下面让我们来看看这张来自 Star Counter 网站的图表：

Google Chrome 占据了 63.6% 的市场份额。如果你的网站只兼容 Chrome，就意味着你将失去 36.4% 的用户。

虽说新版本的 Microsoft Edge 使用的是 Chromium 内核，但这并不意味着你的网站在 Chrome 和 Microsoft Edge 的表现会完全一样。

Safari 拥有 17.7% 的市场份额，它使用 WebKit 作为渲染引擎。

IE 仍然还有人使用。英国政府的服务手册仍然要求用户 2021 年使用 IE 11 进行应用测试。

你仍然需要测试跨浏览器的兼容性，没有什么灵丹妙药或神奇的解决方案。

有些测试工具从一开始就可能会影响跨浏览器测试工作。举例来说，Cypress 不支持 Safari 和 IE，并且也没有迹象表明它将支持这两种浏览器。

由于我在Endtest工作，因此对跨浏览器测试非常熟悉，因为我们的平台有成千上万的开发人员用来构建和执行自动化测试。

我所知道的最优秀的 Web 开发人员总是会确保他们的应用程序可以在所有主流浏览器上运行。

4 利用“气泡”进行开发

开发人员可以为金融行业开发应用程序，无需了解或熟悉任何特定领域。要做到这一点很容易，因为所有事情都被分解成小任务，并且业务逻辑是由产品团队处理的。

花点时间更多地了解这个领域和用户，能帮助你为他们提供更好的体验。首先和产品和销售团队进行更多的讨论，你可以从中学到很多东西。

5 盲目信任开源

开源是软件行业迄今为止发生的最好的事情。但现在的问题是，有些公司将“开源”这个词当作一种营销手段。

一些公司注意到，开发人员对专有解决方案的容忍度很低，因此他们用“开源”将自己重新包装。

这往往给了他们在开源社区推广自己品牌的自由通行证，避免进行安全评估，也避免引起开发人员的注意，而开发人员可能还没有意识到这个解决方案背后有一家营利性公司。

你最喜欢的一些开源解决方案，实际上是由营利性公司所拥有的，如下：

1. npm 公司是 npm 背后的营利性公司。他们筹集的资金超过 1000 万美元，并于 2020 年被 GitHub 收购。

2. Nginx Software 公司是 Nginx 背后的营利性公司。他们筹集的资金超过 8400 万美元。

3. Gatsby 公司是 GatsbyJS 背后的营利性公司。他们筹集的资金超过 4600 万美元。

事实上，太多的开源解决方案都是由员工开发和维护的，并没有活跃的社区支持。而且有些营利性公司也会不遗余力地给人留下这样一种印象：他们的解决方案背后有一个活跃的社区。还记得《小鬼当家》（Home Alone）电影里 Kevin 吗？由于他独自一人在家，为了吓跑窃贼，他制造出假象，让窃贼以为屋子里有人而不敢下手。

在这个领域中有很多不道德的做法，比如，雇人在 Slack 和 Gitter 的公共频道上为这个解决方案辩护，并驳回其他解决方案；或通过个人们发红包，让他们在 Twitter 上发布关于这一开源解决方案的推文。

多许可并不是问题所在，这是一种可靠的、合乎道德的商业模式。真正的问题是误导用户，让他们认为开源解决方案是由社区构建的，它的受欢迎程度并没有被人为扩大。

在使用开源解决方案之前对其进行调查总是一个不错的主意，因为大多数炒作可能都是下作的营销预算造成的。

作者介绍：

Liviu Lupei，专注于自动化测试。

原文链接：

https://dev.to/liviufromendtest/5-mistakes-web-developers-should-avoid-4hpe