不情愿的守门人:关于全栈开发者的迷思

栏目: CSS · 发布时间: 5年前

内容简介:关于全栈开发者,人们存在一些迷思。人们可能会认为全栈开发者是非常厉害的人,他们无所不知,既懂后端又懂前端,一个人可以包揽所有的编码工作。但事实是这样的吗?作者从企业招人的角度和自己作为一名前端开发者的角度剖析了全栈开发者这种角色,观点非常新颖。以下内容翻译自作者的博文。作为一名 Web 设计师,在我的大部分职业生涯中,我都非常愉快地与程序员、工程师和拥有计算机科学学位的人共事。在这种共生关系中,每一方都有一个安全且明确的工作角色,并且能够从事他们最擅长的事情,享受他们的工作。计算机科学家们并不会把全部时间

关于全栈开发者,人们存在一些迷思。人们可能会认为全栈开发者是非常厉害的人,他们无所不知,既懂后端又懂前端,一个人可以包揽所有的编码工作。但事实是这样的吗?作者从企业招人的角度和自己作为一名前端开发者的角度剖析了全栈开发者这种角色,观点非常新颖。以下内容翻译自作者的博文。

作为一名 Web 设计师,在我的大部分职业生涯中,我都非常愉快地与 程序员 、工程师和拥有计算机科学学位的人共事。在这种共生关系中,每一方都有一个安全且明确的工作角色,并且能够从事他们最擅长的事情,享受他们的工作。

计算机科学家们并不会把全部时间花在写代码上,他们做架构,我负责完成通信、表单和互动方面的事情。我们都需要写代码,因为我们是在做 Web 开发,但我们以不同的方式编写代码,以实现不同的和互补的东西。

但对于那些根本不写代码的人来说,事情就没有那么明显:他们很容易认为写代码的人会包揽所有的代码——因为对于代码门外汉来说,所有代码都是一样的。

这种误解造成了糟糕的后果,而非编码人员通常是招聘技术人员的人,这反过来加剧了这种后果。万恶的资本主义总是从最少的资源中榨取最多的价值,因为这是他们赚取利润的方式。如果他们能找到愿意包揽所有编码工作的人,那么就可以极大地减少最重要的开销:人。

因此,市场上就出现了全栈开发者,就像从肮脏的胎盘中破茧而出的强兽人:更强大、更好,同时问题也更多。

为什么会有问题?HTML、CSS、JavaScript、 Python 、C# 和 SQL 都是代码,但它们实际上是完全不同的代码,适合不同类型的人。以前端技术为例:HTML 是一种元语言,与语言、叙事和意义密切相关,属于作家的领域。CSS 属于印刷师和图形艺术家的范畴,而 JavaScript(在这里通常指客户端,但它其实是计算机科学家使用的真正的编程语言)用于处理数据传输和事件。

也就是说,如果你让某人负责所有这些事情(包括 API 和关系数据库设计等等),那么他们在某些领域很可能会比在其他领域要薄弱得多。更糟糕的是,他们往往没有兴趣去改善他们没有意识到的领域或者他们没有获得成就感的领域。根据我的经验,男性更擅长于 JavaScript 或 Python,并通常会从中获得更多的赞誉,但却很少能够从 CSS 技能中获得这些。CSS 让页面看起来更“漂亮”,偏向于“女性化”一些。

一个全栈开发者(实际上是一位同时编写 HTML 和 CSS 的计算机科学家)需要对所有代码负责,尽管这些代码的语法和目的存在根本差异,并成为某些类型代码(一些人根本不关心写得好不好)的守门人。这有两个不利的影响:

糟糕的代码质量;

一群能够(并且喜欢)写出好代码的人却失业了,只能在一旁嘀咕“WTF”。

让人们成为这种守门人的最明显的问题之一是糟糕的 HTML 输出质量。大多数全栈开发人员来自计算机科学背景,他们在学习程序控制结构同时并没有学习 HTML 的文档结构。他们并不擅长这些,但我们却他们也承担了这些工作。

对于“经典”的计算机科学家来说,CSS 可能非常难以捉摸。像级联这样的功能可能让他们摸不着头脑。为了让 CSS 更容易编写和管理,他们用他们更熟悉的东西把 CSS“吃”掉了,于是出现了 CSS-in-JS。

从技术角度讲,CSS-in-JS 通常被定义为一种解决方案(从业者的定义)或者一种问题(反对者的定义)。我认为它不会让 CSS 变得更好或更糟——它只是一种不同的编码方式。但这并不是说它不造成严重的文化问题:

将 CSS 放入 JS 中,那么任何想要编写 CSS 的人都必须学习 JavaScript。而且不仅仅是 JavaScript,还很有可能是 JavaScript 的另一个特定的“风味”,比如 React。更糟糕的是,JavaScript 爱好者不希望在他们的地盘上使用 CSS。

我最近在一家公司工作,这家公司里有数十个全栈开发人员,却没有前端开发人员。我们要开发一个网站,但没有人懂 Flexbox,除了我。当然,我很乐意提供帮助,但我必须学习 React 才能完成手头的工作。所运的是,我很快就学会了,但换了另一个 CSS 专家可能就没有那么幸运。CSS 专家能给你带来的价值是他们的 CSS 技能,而不是他们的 JavaScript 技能,所以将 JavaScript 作为对他们的一项要求是荒谬的。

总之,我认为我们需要解决以下几个问题:

我们需要意识到这是一种剥削。虽然有一些干得很愉快的全栈开发人员,但他们承担了太多的责任,而且他们其实不愿意或应当为所有事情负起责任。

我们需要解决 HTML 和 CSS 被低估的问题:性别偏见。如果没有那些为计算机科学做出创举的女性,我们也就不会有计算机科学,但现在男性却“反客为主”。任何算不上“真正的编程”的东西现都被认为是微不足道的、愚蠢的,更适合女性做。对于抱有这种想法的人,应该狠狠地揍他们一顿。

我们需要重新审视关注点分离原则。为了完成某些事情,却要花大力气掌握所有的东西,这对人们来说是个沉重的负担。我们现在用自包含组件来概念化设计,这是件好事,但它应该是一种心理模型,不能造成技术方面的抢夺。

最重要的是,我们需要教育那些根本不写代码的人,不同类型的代码可以用来完成不同的事情,以及每个人的对代码的理解和写代码的方式存在差异。希望通过这种方式能够让更多的人编写适合自己的代码,而不是花时间在焦虑上,比如不知道自己在做什么,或者承担了太多的责任。当然,这并不是说如果你愿意承担编写 JS、CSS、HTML、SQL 和 C# 代码的任务或者有足够的时间也不应该去写这些代码!

英文原文: https://medium.com/@Heydon/reluctant-gatekeeping-the-problem-with-full-stack-e9ad836570f6


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

反应式设计模式

反应式设计模式

Roland Kuhn、Brian Hanafee、Jamie Allen / 何品、邱嘉和、王石冲、林炜翔审校 / 清华大学出版社 / 2019-1-1 / 98.00 元

《反应式设计模式》介绍反应式应用程序设计的原则、模式和经典实践,讲述如何用断路器模式将运行缓慢的组件与其他组件隔开、如何用事务序列(Saga)模式实现多阶段事务以及如何通过分片模式来划分数据集,分析如何保持源代码的可读性以及系统的可测试性(即使在存在许多潜在交互和失败点的情况下)。 主要内容 ? “反应式宣言”指南 ? 流量控制、有界一致性、容错等模式 ? 得之不易的关于“什么行不通”的经验 ? ......一起来看看 《反应式设计模式》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具