原文:Elasticsearch Team Development Constitution

译者:neal1991

welcome to star my articles-translator , providing you advanced articles translation. Any suggestion, please issue or contact me

LICENSE: MIT

前言

我们作为 Elasticsearch 核心开发人员团队希望尽可能快地向可靠,健壮,安全,可扩展且易于使用的系统迁移。我们希望为创新而努力,取代传统的构造和功能,删除脆弱的代码,并致力于改善用户体验,同时在我们快速变化的同时保持用户增长。

对于我们来说,拥有一个团队的前进方向的共识是非常重要的,甚至更重要的是团队为什么要走上一条特定的路。当 Elasticsearch 创立之初时,它具有无尽的灵活性,易用性和丰富的 API。我们这帮年轻的团队成立了一家公司,并且突然用户数井喷式发展。支持组织几乎无法满足越来越多的客户,这是幸福的烦恼。然而,随着用户数量的增长,事情发生的可能性也越来越大,不幸的是,这比我们聘用支持工程师的速度要快得多。我们了解到,大多数灵活性来自宽松处理,从大多数情况下可行的功能,但不是全部。例如,用户可以使用请求发送的脚本基本上是一个远程代码执行引擎,如果出错,它是致命的。即使最基本的功能,比如设置,也非常灵活,但非常脆弱。在没有单位的情况下指定一个数字是很好的,除非许多用户不知道默认单位是什么。我们只是试图做正确的事情,结果证明并不是总是对的。

现在我们处于不同的位置。我们的用户基数比 2013 年的用户基数大得多,但我们的支持机构并没有以同样的速度增长。是的,我们处理比 2013 年更多的支持案例,但这在我们当时的系统中是不可能的。现在我们已经从一个脆弱而灵活的系统转向了范围较窄的软件。我们定义了更多的边界:更严格的输入验证,允许我们对权限进行细粒度控制的安全模型,甚至还有一个插件模型,可以以极大的灵活性来添加风险更高的功能。

但等等,我们还差得远呢!仍然有无穷无尽的问题会造成致命的后果。聚合可以通过一个请求来撑爆服务器。用户感觉需要运行 30+GB 堆的 Elasticsearch。我们仍然提供了 27 种指定布尔值的不同方式。这份清单还有其它内容…

我们对我们的用户,支持组织,云托管团队和第三方提供商负有巨大责任,提供可靠,稳健,安全且易于使用的系统。出于这个原因,我们都应该努力创新,取代传统的构造和功能,删除脆弱的代码,并改善用户体验。我们与其他公司相比的优势是我们的创新,创新需要速度。我们必须在留住用户的同时下采取行动并接受变革创新。

以下章节是用于设计,重构或从 Elasticsearch 代码库中删除代码的原则和指导原则的集合。这些点是无序的,大部分是未分类的,应该被看作是 Elasticsearch 团队内软件开发的一个组成部分。

设计特性

作为一个简单的练习,假设一个函数,它的参数总是被所有调用者传递为零。人们可以保留这个参数,以防万一有人最终需要使用它提供的额外的灵活性。但是那个时候,代码从来没有注意到的机会是好的 - 因为它从未被使用过。或者当需要额外的灵活性时,它不会以符合程序员早期预期的方式进行。我们应该定期提交补丁以删除未使用的参数; 一般而言,他们不应该添加在首位。(来源于 https://www.kernel.org/doc/Documentation/development-process/4.Coding)

当有人批评代码时,他们不是批评你,所以对事不对人。帮助他们理解你为什么这样写。当有人重写你写的代码时,并不是不认可你的想法。有一次,Mike 向 Lucene 提交了一个变化,Adrien 在两天后就将它废弃了!当其他人对你写的代码感兴趣时,这很好,这意味着代码是活的。随着代码成为一个日益增长,蓬勃发展的存在,可以持续看到代码的改进。

不要害怕犯错,更重要的是,不要让恐惧使你无法添加一些不完全正确的东西。将错误和失败视为*反馈*,*发现*和*知识*可以使我们的产品更好。

和人们互动

来自于保持友善:

(意识到一些视频是反向教材: 如何像老板一样指派任务)

用明智的话来解释你的反对意见。你的否决权必须出于技术原因。准备好讨论和解释。被否决的改变被提议者认为是好的,他们值得讨论。 当然,他们也应该有机会用他们的理由来说服你。在过去,这种健康的讨论实际上以撤销否决权而告终。

受启发于:

Zen of Python

Contributor Covenant

Amazon’s Leadership Principles

Rust’s Code of Conduct, Rust video on Conduct