将前端与后端分开是一种反模式

我们软件开发人员历来使用术语“前端”和“后端”来分别描述客户端(例如，浏览器)和服务器端应用程序的工作。这种概念上的分裂已经演变成为每个人创建专门的开发人员角色，这仍然是整个行业的规范。在实践中，这是一种武断的分裂，经常被用来避免我们不想做的工作。它创造了团队活力，使得集成客户端和服务器端功能以及交付高质量软件变得不必要地困难。这在面临日益复杂的客户端工作的现代团队中尤其有害。然而，我经常会遇到前端/后端的思维模式，即使是在技术最进步的公司也是如此。在我的上一个项目中花了一年时间引入现代JavaScript后，我被告知不要再关注前端了，因为“我们是应用程序开发人员”。我见过的每个在客户端工作中拥有非凡能力的开发人员都有类似的故事要讲。这种不屑一顾的态度既说明了我们未能理解JavaScript和整个前端生态系统在最近几年发展了多少，也说明了我们的团队思想狭隘，这使得我们的团队很难根据现代市场的期望调整和交付软件。将前端与后端分开是一种反模式。如果你仍然认为这些角色之间有很大的区别，那么这篇文章就是为你准备的。前台开发人员到底做了什么与后端开发人员如此不同的工作呢？人们的感觉似乎是，从历史上看，后端开发人员做的是更严肃的编程，他们考虑的是一些有意义的问题，如可测试性、可维护性、持久性、异步性、状态管理和API设计，而他们的前端同事则在让事情看起来更漂亮方面手忙脚乱。如果前端开发人员做过任何严肃的编码，那很可能是一些粗俗的、不太了解的jQuery，是从各种Stack Overflow帖子拼凑而成的。许多人仍在沿着这些思路思考。现实是这样的：JavaScript在过去几年里绝对是爆炸性的。如今，随着越来越复杂的客户端应用程序的出现(想象一下响应迅速、身临其境、支持脱机的体验)，大量功能正从后端转移到前端。我们现在在思考前面和后面同样的问题。我前面列出的问题(可测试性、可维护性、持久性、异步性、状态、API设计)现在是客户端开发人员的日常工作。但我们不只是共享相同的问题-我们也以相似的方式解决它们。功能抽象正在成为普遍有用的概念，因此我们经常可以在客户端和服务器中使用相同的概念和语法。只要看看ReactiveX就知道了，它现在实现了如此之多的语言，以至于您可以很容易地在前后相同的反应性抽象上构建一个项目。然后是声明性呈现的革命，它使视图层更具可测试性和稳定性。在架构方面，微前端已经变得如此流行，以至于我们将它们与其后端对应的微服务一起添加到了ThoughtWorks技术雷达中。当我们都在做类似的工作时，保持前端和后端开发之间的区别是没有意义的。客户端工程是一项严重的业务需求。JavaScript正在接管世界，我们负担不起优秀而有经验的开发人员将用户界面(UI)和用户体验(UX)工作视为他们关注的领域之外的工作。在ThoughtWorks，我们看到越来越多的项目涉及修改或完全重写我们客户的浏览器和移动应用程序，以符合现代消费者的需求。换句话说，积极构建和维护客户端能力对于在今天的市场中生存至关重要--更不用说明天的市场了。你可能会认为，正确的解决方案是简单地雇佣更多的工程师担任传统的UI开发人员角色。但事实并非如此，原因有两个。首先，在科技行业，招聘和留住专家是出了名的挑战。因此，我们的重点应该改为支持我们现有的劳动力进行前端开发-特别是考虑到现代前端和后端工作的相似性。其次，拥有专门的UI开发人员会促进有问题的团队活力。我们中有多少人所在的团队中，所有或大部分前端架构和开发都被降级到“JavaScript人员”手中？这可能会导致信息孤岛、不那么可靠的测试和代码质量的整体降低，进而构成严重的业务风险。特别是敏捷团队，需要开放的思维和愿意戴上不同的帽子才能有效。

归根结底，我们中的许多人只是不喜欢造型和其他与设计非常接近的前端领域。去年我听到一个告白