“最糟糕的程序员”

【编者按】本文主要讲述了一个软件开发项目因两位优秀的程序员使用复杂的前后端框架，导致其他团队成员无法直接处理业务需求，最终项目勉强交付但质量堪忧的故事。

作者认为这些优秀的程序员却是最差劲的。

原文链接：http://mikhailian.mova.org/node/284

本文借助 AI 工具进行翻译整理。

作者｜Alexander Mikhailian    责编 ｜梦依丹

出品 | CSDN云计算（ID：csdnCloud）

工作 25 年后，我发现有一类程序员是行业众多问题的始作俑者。有个项目差点就被这样的两个程序员搞砸了。一个负责前端开发，另一个负责后端。其他团队成员都在磨洋工，因为业务需求还在制定中，而这两位老兄却在拼命工作。

负责前端的那位用 NX、Rx 和其他当时流行的技术搭建了一个 Angular 单体存储库。公司的环境不太适合 NX，但他还是努力与领域专家合作，解决或规避基础设施问题。他创建的工作流程虽然以 Angular 为基础框架，但和官方的 Angular 教程却大相径庭。

后端的负责人也不甘示弱，按照公司的要求创建了 Spring Boot 项目，还加入了一些自己的特色，比如用 Vavr 库，以及有多层继承、判别器和生成器的复杂 JPA 实体层次结构。接着，他又基于 Spring Bean 验证和第三方验证框架，加了个验证器层次结构，再用个流行的测试框架润色了一下。

其他团队成员都在一旁羡慕地看着他们。

几个月过去了，业务部门还在竭尽全力地提出各种需求。然而，由于前后端框架过于复杂，团队其他成员已经无法直接处理业务需求，所以两位开发负责人努力将业务需求分解成更易管理的技术任务，并承担了大部分繁琐的工作。

他们比团队里其他人都要努力。当初级成员要求分配任务时，他们得到的都是些诸如 API 设计或测试之类的“不重要工作”。

突然，前端负责人寻找到了更好的工作机会离职了。

公司找来了一位专业的前端开发人员，他在一段时间内能够持续交付项目，然后又来了另一位稍微待得时间更长一些的开发人员。初级开发人员则一直没有得到充分的利用。

后端负责人的工作负担越来越重。他花费了漫长的工作日，甚至加班到深夜，来完成看似简单的 CRUD 界面开发。然而，界面的内部却异常复杂，几乎无法减轻他的工作量。几个月后，后端负责也离职了。

公司在业务方的不断施压之下，以极其缓慢的速度继续着，并竭力保证项目能在在截止之前完成。

然而，代码质量下降到令人堪忧的地步，甚至出现了使用 Vavr 对象进行空值比较，以及 Angular 、TypeScript 与纯 JS 代码随意混合的情况。最终，公司勉强交付了一个充斥着漏洞的产品。公司前景看起来也十分黯淡。没人有能力重写最初主导这个项目开发人员所产生的数千行代码。员工离职率居高不下，成本也飞涨。

上面这个软件开发项目描述是不是很耳熟？

我在好多不同的行业都见过类似的项目，少说也有十几个，像在线媒体、公共服务这些行业的程序员一般是被认为最厉害的，可我却觉得他们是最差劲的程序员。

下面是我总结的这些人特点，给大家提个醒：

能够从解决抽象问题中找到乐趣

数学能力强，LeetCode 成绩好，擅长解纵横字谜、创作谜题，说明这个人能处理没有实际用处的问题。他们更关注过程，不太在意结果。

能够投入大量的工作时间

要身体好，有大量能用来工作的时间。有家庭、孩子或患有腕管综合征的人，可能做不到这一点。

对软件工程有热情

聪明、积极的程序员，总能在自己负责的项目中加入喜欢的技术。业务无聊，编码简单，何不引入大家都感兴趣的新技术，让工作更有趣呢？这样还能给简历增添一项流行元素。

自恋且自信

这可能和邓宁-克鲁格效应有关，这类人通常比较年轻，二十八九岁或三十出头，很聪明。他们总被夸很优秀，很少受到批评。

如何避免与此类人群打交道

在商业环境中，管理层通常不懂技术，而这些最差的人却是表现最好的，所以你最好不要向管理层抱怨他们。他们的工作表现可以量化，但团队精神却不行。

你直接跟最差的这类人沟通基本也没用，因为他们只听得进去项目上的建议，而关于团队合作，他们压根不听。

我们能做些什么呢？

解决问题的第一步是认识到问题所在，第二步是要弄清楚：大多数软件都是由团队构建，它必须能让每个团队成员使用。第三步是寻找现有解决问题方法。令人惊讶的是，许多现代软件工程的理念都可以被视为解决我们中最优秀的人的问题的方法：

1. Golang、Lua 等简单的编程语言

Golang 被普遍认为是一种非常简单的语言。它与 Rust 不同，Rust 是实现目标的手段，而不是讨论的主题。Golang 团队努力工作，而 Rust 团队则......变得生锈，因为这种语言鼓励人们专注于它本身，而不是工程项目的结果。

2. Scrum

Scrum 一个不太被重视的方面是团队成员的可互换性。虽然可能有专业分工，但团队成员需要处理冲刺中的任何任务。这应该会导致简单的工程解决方案，这些解决方案是所有团队成员都可以使用的，而不仅仅是最复杂的解决方案。

3. DevOps

老练的程序员通常在特定的环境中工作成为一名老练的 Spring Boot 程序员或  C++ 程序员相对容易。DevOps 则将每个人都变成了多面手：配置服务器或云环境、监控、部署、设置管道以及编写微服务代码。所需技能的数量之多，甚至让我们中最优秀的人在某些时候也变成了新手，从而培养了对技能较低的团队成员的同情心。

最后

我们中最优秀的人可能是最糟糕的。