Web 编程中的三大分歧

《The Great Divide》
是 Chris Coyier 在 2019 年 2 月撰写的一篇文章。该文试图解释最近在前端社区发生的现象:一方面,有些开发者非常精通 JavaScript;另一方面,有些开发者非常精通 HTML、CSS、可访问性和 Web 设计。尽管他们都称自己是“前端”开发者,但他们并不拥有相同的兴趣和技能。Chris 称:“他们之间无话可说。”

然而,前端之外的软件世界还潜藏着其它的分歧。其中一些分歧已经存在了好几十年,而另一些则从 50 年前一些

创造了“软件工程”一词
后就一直存在。
本文将讨论 Web 开发中能够影响团队、社区和组织的重要分歧。让我们聊一聊那些比你在前端社区所看到的更久远且更根深蒂固的分歧吧。

一、前端 vs 后端

首要的分歧是 前端 vs 后端
。和“The Great Divide”类似,有许多能够创建大型网站的 Web 开发者。一方面,有些人精通浏览器是如何工作的,即“前端”开发者;另一方面,有些人精通服务器是如何工作的,即“后端”开发者。

在 Web 开发中,“前端”的概念出现得甚至比 jQuery
都早。那时候,我们习惯于在表格中创建网站,并想出创造性的 CSS 技巧来支持 IE 6。尽管这看起来已经是很久之前的事了,但是“前端”的实践是相当新的,不超过 20 年。
另一方面,“后端”则和计算机一样古老。如果你习惯于创建“后端”应用程序,你将学习用于软件开发的大量基础知识,这些基础知识是由聪明的编程人员几十年前发现的。而对于前端技术更感兴趣的开发者并不会参照这些实践。反过来也是如此。如果你习惯于构建“前端”应用程序,你将学习大量关于浏览器是如何工作的基础知识,而后端开发者也对此不感兴趣。

后端开发者不关心前端。
前端开发者不关心后端。
这种兴趣上的分离导致了双方巨大的知识隔阂。

对于技术社区来说,这阻碍了经验的分享,成为发挥巨大科技创新潜力的障碍。

例如,你参加一个“后端”语言讨论会。在会上,你很有可能只会遇到后端开发者。这种环境就不难创造出一种鄙视前端的 文化
。如果一些刚开始软件职业生涯的初级开发者听到鄙视言论并缺乏对前端的兴趣,他们也会在将来鄙视任何与前端有关的事情。这种分离创造了一种限制初级开发者视野的环境。

对于组织来说,这成为每个团队在前端和后端重复逻辑的诱因。
例如,你在后端有一个对工作流状态的切换:“PENDING“和“CANCELLED”。假如前端开发者独自开发,你很可能会在前端看到相同的代码逻辑。稍后,如果你想为工作流创建一个新状态,你就需要同时修改前端和后端代码,而不只是修改单独一处代码。
如果你是一名前端开发者,你将创建重客户端 JavaScript 代码并轻服务器端代码的系统。如果你是一名后端开发者,你将创建重后端代码并轻客户端 JavaScript 代码的系统。

我已经 在一篇文章
中部分地描述了这种分歧,展示了后端和前端的分离如何驱使你创建无用的代码。你可以通过 《前后端分离和对花括号的非理性喜爱》
看到更多例子。
前端与后端的分离导致开发者孤立地工作,重复逻辑,所开发的内容要么全是浏览器端的,要么全是服务器端的。

二、基础设施运营 vs 产品开发

另一个分歧在于 基础设施运营
产品开发
。一方面,有些人精通网络协议和硬件如何工作;另一方面,有些人精通软件架构和设计。

如果你对于基础设施运营更感兴趣,你将降低学习与快速可持续产品开发有关的软件设计原则的优先级。你将专注于计算机和关于如何保持它们运行的 高可用性
的技术挑战。
对于保持计算机运行的兴趣将帮助你学习如何设计可靠的软件,并为硬件构建可监测性。然而,这并不能帮助你学习如何设计从用户角度能够提供可用性的系统。如果用户必须等待一个小时才能得到他们想要的,那么服务器的正常运行是没有意义的。从用户角度来说,这是一个中断。

作为一名基础设施运营开发者,你的日常编码准则可能是编写小型的自包含的 Bash 脚本或者基础设施代码,如 Terraform
。因此,学习自动化测试技术,例如 TDD
,也就没有任何意义;学习如何使你的设计变得更可测试也没有意义。

如果你对产品开发更感兴趣,你将错过物理硬件相关的基础知识。你很容易陷入 分布式计算的8 个误区
。你将为能够增加可维护性并降低编程成本而优化设计和编程原则( SOLID
XP
Connascence
Cohession
)。然而,你也会错过了解真实世界的机会。正如人们所说:“没有所谓的云,这只是其他人的计算机”,而且这个计算机实际上就位于现实世界的某个地方。
基础设施运营与产品开发的分歧导致开发者不去了解硬件的物理挑战,导致运维人员不去理解软件的经济成本。

三、用户体验 vs 前端开发

我们不要忘记通常发生在大公司的另一个显著的分歧: 用户体验
前端开发
。一方面,有些人精通创建用户体验和系统的可视化设计;另一方面,一些人精通如何使用 HTML、CSS 和 JavaScript 创建用于生产的在线网站。

从设计者的角度来看,他们构建了一个基于用户反馈的用户流程以及与公司品牌匹配的视觉组件。然而,当他们将这些转交给前端开发者,开发者总是抱怨最终结果与他们的内部组件库是如何不搭。另外,他们抱怨设计人员预期流程中的元素是如何地困难,以及开发成本是如何地高。结果与设计者设想的大不相同。

从开发者的角度来看,他们收到了一个好看的流程和设计。然而,这个设计对开发成本并没有一定的理解。一些组件是可复用的,但是设计中并没有使用这些组件。开发团队可以改变 UI 中的一些部分,但是其它部分他们不能碰。例如,设计可以创建一个横跨所有页面组件的横屏滚动体验。然而,设计者不知道团队只拥有主网站下的某个 iframe。技术原理上,如果不重写整个系统,是不可能实现横跨所有组件的横屏滚动体验的。
用户体验和前端的分歧造成了一种情况:开发者抱怨设计者,而设计者抱怨开发者。

这些分歧的产生有许多原因。主要的一点是公司和软件社区 基于技术

划分他们的角色

  • 前端 JavaScript 开发者
  • 前端 HTML/CSS 开发者
  • DevOps 工程师
  • 后端开发者
  • 用户体验设计师

他们不是基于业务能力来划分他们的角色:

  • 网络销售
  • 客户关系部
  • 自动计费
  • 员工体验
  • 网络营销

每个人都相信一个人学习所有软件开发技术的成本太高。因此,市场鼓励人们走捷径,通过专业化来快速获得职位。
进入市场的最佳捷径是专业化。
总之,除了 Web 领域的 JavaScript 和 HTML,在软件开发中还存在许多技术分歧:

  • “后端”和“前端”
  • “运维”和“产品开发”
  • “用户体验设计”和“前端开发”

作为一名编程人员,理解软件开发背后的基础知识是首要的,而不是仅仅关注某一个技术栈。那会让你看到所有可能和不可能的边界,理解一种技术方案相较于另一种技术方案在特定商业背景下的取舍。

为了 尝试解决问题
而写的代码都是有目的的。这个目的是为了创造价值,而不仅仅是写代码。 这就是编程。

作为一家公司,建立协作文化是至关重要的。如果一件重要的工作需要多个角色,那么试着把他们放到同一个房间,同时在同一台计算机上工作,使他们更紧密地协作。建立代码审查、 结对编程
Mob 编程
文化。
作为一名编程人员,学习基础知识;作为一家公司,协作。
除此之外,还有一个本不应存在,但发生在每一个大型组织的重大分歧。那就是软件开发者与软件使用者之间的分歧。开发者与客户之间分歧。那是另一篇文章的主题,敬请关注!

作者介绍:
Fagner Brack 是 js-cookie 的作者、Impress.js 的贡献者,软件工程师和博主。他相信思想应该是自由开放的,因此会分享一些别处看不到的基础知识。