Python编码标准与生产力

我为一个大型人道主义组织工作，开发了一个项目构建软件，该软件可以通过加快食品分配来在紧急情况下挽救生命。许多NGO迫切需要我们的软件，而我们比原计划晚了几周。

在这个项目中让我担心的一件事是，我认为过分注重编码标准。我们使用python / django编写并使用PEP0008版本，并进行了各种修改，例如，行长最多可以达到160个字符，并且如果可能的话，所有行都应该走那么长，导入之间没有空行，仅适用于某些种类的换行规则类，我们必须使用很多模板，即使它们不是解决问题的最佳方法等。

一位核心开发人员花了一周的时间重写系统的主要部分以满足当时的新编码标准，并丢弃了过程中的几套测试，因为重写意味着它们“无效”。我们花了两个星期来重写所有丢失的功能，并修复错误。他是首席开发人员，他的话语具有影响力，因此他说服了项目经理这些标准是必要的。初级开发人员按照他们的指示做。我觉得项目经理对所有这些都有强烈的认知失调感，但是尽管他不确定要做什么，但还是非常赞同。

今天，我遇到了严重的麻烦，因为我忘记在关键字参数中的逗号后加上一些空格。在Skype通话期间，我确实被其他两个开发人员和项目经理大喊大叫。就我个人而言，我认为编码标准很重要，但同时我们也认为我们浪费了大量时间来沉迷于它们，当我口头表达这时，它引起了人们的愤怒。我被视为团队的麻烦制造者，一个正在寻找失败者的替罪羊。自从引入编码标准以来，团队的生产力已显着下降，但这只会加剧这种痴迷，即首席开发人员只是将我们不遵守标准归咎于缺乏进步。他认为，如果我们不遵守约定，我们将无法阅读彼此的代码。

这开始变得粘滞。现在，我正在尝试修改各种脚本（autopep8，pep8ify和PythonTidy）以尝试匹配约定。我们还对源代码运行pep8，但是对我们的标准有很多隐式修改，以至于很难跟踪它们。首席开发人员简单地挑出了pep8脚本没有拾取的错误，并在下一次站立会议中向我们大喊。每周都有新的编码标准增加，迫使我们重写现有的，有效的，经过测试的代码。谢天谢地，我们仍然有测试，（我还原了一些提交，并修复了一堆他删除的提交）。

一直以来，满足截止日期的压力越来越大。

我认为一个基本问题是，首席开发人员和另一个核心开发人员拒绝信任其他开发人员来完成工作。但是如何处理呢？我们无法完成工作，因为我们正忙于重写所有内容。

在软件工程团队中，我从未遇到过这种动态。我对他们是否遵守编码标准提出质疑吗？是否还有其他人遇到过类似情况，他们如何成功处理？（我不是在讨论人们只是找到实际解决方案的讨论）

编码标准不是问题。问题是管理层无法弄清楚问题是什么。这导致“做某事……任何事情！” 模式。您正在寻找一个合理的解决方案，但这是一个非理性的问题。您能做的最好的事情是：

• 对他们的想法进行建设性的批评，但是一旦做出决定，就不要继续抱怨。
• 尽一切可能使重写更容易。
• 别再强调了。错过最后期限是管理层的问题，而不是您的问题。尽力而为，但不要为他们的错误决定承担责任。
• 如果您知道可能有帮助的内容，请告诉他们。您提到的站立姿势听起来像是您在尝试敏捷，但是其余的听起来并不敏捷。看看您是否可以尽早提供有限的功能，而不是尝试在所有任务上都花一个大的期限。为重写创建用户案例，以便清楚它们如何影响积压。
• 开始寻找另一份工作。说真的 处于这种状态的公司离解雇员工不远。
• 得到一些“告诉你”的T恤：-)

真正需要优先考虑的是确定运输还是奴役遵守编码标准。我知道我的喜好。如果它通过了单元测试和验收测试，我说是船。发货后，公司可以决定是否花费时间和金钱来解决技术债务。

使用代码整理工具可以轻松解决逗号后的空格问题。查找一个可实施所有编码约定的工具，并在构建和测试之前在所有修改后的代码上运行该工具。在编写代码时，不错的IDE已经做到了。

我对他们是否遵守编码标准提出质疑吗？

这取决于组。我个人认为一切都应该受到质疑。有些人认为这个质疑是侮辱。我不信任他们

是否还有其他人遇到过类似情况，他们如何成功处理？

我问这些标准如何提高生产力。我测量了花在修改标准和“完成工作”上的时间。最后，决定遵循标准的权力。它发生了。我抱怨它们比平时响亮，这是因为它们导致我无法完成工作，而是专注于完成工作。不断地争斗也不利于生产力...

就像您说的那样，如果由于标准而导致事情恶化到可衡量的程度，那么遵守标准将使潜在客户的论点无效，而由您自己决定。如果人们看不到标准的实施与生产率下降之间的（大部分）客观关联，那么您将无能为力。学会处理它，如果不能的话，找一个不太官僚的地方。

标准是不应在临近期限的后期项目中制定的。这应该在项目初期或在项目进度表中（最好是在首次交付之后）留出时间来（可能）进行大范围违规代码重构时就应该使用的东西。

如果实际上是在项目后期提出的，那么这是您的主管（IMHO）犯的错误。

但是，这并不意味着如果您不同意线索，就应该对叛变进行收费。这是你的工作。你作为一个团队工作。你有领导。团队中肯定应该有一定程度的民主，但最终领导者是独裁者。如果他说要做某事，那就去做。

最后，在遵守他的要求和标准时，您不能为错过截止日期提供一个轻松的替罪羊。

另外，我是编码标准的大力拥护者（尤其是随着团队规模的增长），但是应该在有意义的时候实施它们。

您的问题是“我是否对他们遵守编码标准表示怀疑？”。 http://c0x.coding-guidelines.com/Introduction.pdf（适用于C编程语言）对编码准则的价值进行了一些参考研究。请参阅从第39页开始的第9节。

实施编码标准是有原因的。原始问题似乎缺少的一件事是对特定项目（或特定组织）中这些特定标准的原因的理解。在现有代码上实现它们的决定是基于某种逻辑的。在不知道其逻辑的情况下，很难对这一决定的“好”进行评论。

我将第二个人说的是，标准是为“长期生产力”而实施的，例如代码的可维护性。也许由于混乱和误解，发生了一些事件使该项目严重退缩。

听起来双方都有很多情感-尝试进行理性的讨论。

正如您可能从其他答案和评论中看到的那样，您的项目存在很大的问题，因此我要提出的建议成功的机会并不大，但是您可以尝试这样做，而这样做不会带来太大的风险你自己的皮肤。

要求与您的首席开发人员见面。假设您有兴趣彻底了解严格遵守编码标准的好处以及为什么在引入它们之前代码库的状态如此糟糕。在讨论过程中，保持开放态度和“我正在尝试学习”的态度非常重要。您的首席开发人员可能已经比您或团队中的任何其他人承受更大的压力，并且一旦嗅到一些批评就可能会非常防御。

尝试将讨论推向试图找出实现共同目标的方式的方向；及时交付可维护的软件。

例如，有些低落的果实就是不要在编码指南中添加更多内容。每次发生这种情况时，以前遵循准则的代码都不再起作用，这导致您需要重写代码块。希望您的首席开发人员可以看到，即使添加的规则增加了价值（从他的观点来看），在已经很晚的项目的此阶段，它可能不如激励重写。

如果这行得通，您可以尝试让他删除一些无法使用某些工具自动格式化的规则。

编码标准是好的。更改编码标准是很昂贵的（嗯，如果您不让它们放任自流，那就很昂贵；如果对标准的更改使所有现有代码仍然合规，那就不成问题），因此仅在绝对需要时才进行。

可能要做的一件事是，在提交/合并/执行任何操作之前先检查所有代码，以确保它符合标准，因为显然现有的工具链似乎无法自动检查它。

可以通过加快食品分配来帮助在紧急情况下挽救生命的软件

我相信良好的编码标准，但我也相信挽救生命至关重要。

您的首要任务必须是挽救人们的生命。想象一下，如果该软件正在向您的家人或您的团队分发食物。接下来还有其他任何事情。

好消息：您进行了测试。测试将帮助您遵守编码标准而不会破坏功能，但这应该在发货后而不是之前进行。