如果我的团队技能低下，我应该降低代码的技能吗？[关闭]

例如，在JS中有一个通用代码段可以获取默认值：

function f(x) {
    x = x || 'default_value';
}

我的团队的所有成员都不容易理解这种代码片段，因为他们的JS等级很低。

那我不应该使用这个把戏吗？根据任何JS开发人员的说法，它使代码更不易被同级人员读取，但比以下代码更具可读性：

function f(x) {
    if (!x) {
        x = 'default_value';
    }
}

当然，如果我使用这个技巧并且同事看到了它，那么他们可以学习一些东西。但是通常情况是，他们认为这是“试图变得聪明”。

那么，如果我的队友的级别低于我，我应该降低代码级别吗？

好的，我来谈谈这个大而复杂的话题。

保持您的编码风格的优点：

• 诸如此类x = x || 10的事情 在JavaScript开发中是惯用的，它们在您的代码和您使用的外部资源的代码之间提供了一种形式的一致性。
• 更高级别的代码通常更具表达力，您知道自己能得到什么，并且在训练有素的专业人员中更容易阅读。
• 您会更加享受工作。我个人很重视创建漂亮的代码。我认为这给我的工作带来了很多满足感。
• 通常，它创建更具可读性的样式。坚持使用语言的习语可能会非常有价值-出于某种原因，它们经常是习语。

保持编码风格的缺点：

• 对于较低级别的程序员而言，要保持这种状态将更加困难。这些人通常是维护您的代码的人，而实际上必须阅读您编写的内容的人。
• 代码的维护者，通常JavaScript代码来自其他语言。您的程序员可能会熟练使用Java或C＃，但不了解JavaScript的方式和时间完全不同。这些要点通常是惯用的- 立即调用的函数表达式（IIFE）是此类构造的一个示例。

我个人的意见

您不应该降低代码的技巧。您应该渴望编写具有表现力，清晰简洁的代码。如果您对团队水平有任何疑问，请对他们进行培训。人们比您想像的更愿意学习，并且在确信新的构造更好时愿意改变新的构造。

如果他们认为您“很聪明”，请尝试提出您的观点。愿意承认有时您错了，无论如何，请尝试在整个工作环境中保持样式的一致性。这样做将有助于避免敌意。

最重要的是保持一致。

团队的代码应像一个人一样编写。您绝对必须在编码准则上达成共识。您应该遵守那些准则。如果编码指南规定应以“不太聪明”的方式读取可选参数，那么就是这样。

好评论

您是否应该降低代码技巧？不一定，但是您绝对应该提高注释的技巧。确保在代码中包含良好的注释，尤其是在您认为可能更复杂的部分周围。不要使用太多注释，以免导致代码难以理解，但请务必使每个部分的目的明确。

现实情况是，对于某些技术水平较低的团队成员而言，稍微冗长些的评论可能会有所帮助，但对于技能最低的团队成员，则可以忽略它们，尤其是如果人数过多，请不要过分使用。

风格问题？

您提供的示例有些基础，但也颇具风格。围绕每个变量默认值的注释将非常难以维护和阅读。相反，应将样式或重复的快捷方式或代码模式确定为标准。如果您认为这种形式的参数默认值应该为所有人所理解，并且每次都应使用，请将这些想法写下来，并带给您的团队负责人。可能只有一次简单的会议可以教会您的队友，在会议上讨论您提议的标准。

正如已经回答的另一个答案，保持一致。

教人钓鱼...

教队友可能是您可以帮助每个参与人员的最好方法。明确指出，如果有人对某个代码段有疑问，并在提交日志或时间戳中使用您的姓名，那么他们应该随时向您询问。如果您的团队进行了代码审查，那么这是一个很好的机会，可以向您的队友解释任何可能引起混淆的（糟糕的）经过注释的代码。如果您的团队没有代码审查，为什么不呢？来吧！

但是，您需要小心。您可能并不总是在教人，甚至可能忘记了在给定的代码部分中最初想要做什么。

“聪明”的把戏

牢记队友的能力绝对重要，但是编写可维护的代码通常意味着不使用奥秘的捷径来解决可能具有更常见解决方案的问题。即使您的队友很聪明，这也很重要。您不希望使代码花太长时间来掌握或产生可能遗漏的细微但重要的副作用。通常，最好在有合适的替代方法时避免“聪明”的把戏。您永远都不知道谁可能必须一直维护代码-很多时候我们自己的旧版本不记得这些技巧的细节或原因。

如果您发现必须实施巧妙的技巧，请至少遵循下一条建议...

吻

如有疑问，请保持简单。代码是否简单，不一定像您想的那样对应于程序员的技能。实际上，一些最出色的解决方案是最简单的解决方案，而某些更复杂的解决方案最终出现在TheDailyWTF上。使您的代码简单明了可以使一些更明智但可能违反直觉的决策更易于掌握。

在JS中创建函数似乎有很大的反感。这种厌恶情绪导致人们试图变得聪明，并使用荒谬的把戏来使内容保持一致，就像函数调用一样。当然，调用中的函数名称也充当额外的文档。我们不能在棘手的表达式上附加注释，因为那样会破坏注释的意义，因此我们将其称为“ js惯用语”，突然间它是可以理解的。

JavaScript非常易于访问，大多数人不像我们一样吃早餐的规格。因此，他们将永远无法理解成语的隐藏假设和边缘情况。

x = x || 'default_value';

普通的joe可能不理解这一点，或者已经记住这是默认值的惯用法。两者都是有害的，实际上后者更为有害。他将在这里不了解假设和极端情况。他将不关心阅读规范并永远理解它。

当我看着代码，我看“，如果是null或undefined，然后将其设置到这个默认值。虽然它也可以隐式处理+0，-0，NaN，false，和""不适合的值。我要记住，从现在是3个月的时候，需要改变。我可能会忘记它。”

隐含的假设极有可能在将来引起错误，并且当您的代码库中充斥着这样的技巧时，那么当您考虑修改会影响什么时，就没有机会将它们全都牢记在心了。这是针对“ JS专业版”的，即使要求从一开始就接受虚假的值，一般的乔也会编写该错误。

您的新代码段具有更熟悉的语法，但仍然存在上述问题。

您可以选择：

function f(x) {
    x = valueOrDefault(x, "default_value");
}

现在，您可以使用非常复杂的逻辑来处理极端情况，并且客户端代码仍然看起来漂亮且可读。

现在，您如何区分高级语言功能（如将函数作为参数传递）或巧妙的技巧（如）|| "default"？

巧妙的技巧总是在一些隐藏的假设下起作用，这些假设在最初创建代码时会被忽略。我将永远不必将IIFE修改为其他内容，因为需求已更改，它将始终存在。也许在2020年，我可以使用实际模块了，是的。

| 0或~~num用于地板的货物崇拜版本假定为正数和32位有符号整数边界。

|| "default" 假设所有伪造的值都等于根本不传递参数。

等等。

您不应该降低编程技能，但是可能需要调整编写代码的方式。几乎最重要的目的是使您的代码对必须阅读和维护它的人员明确。

不幸的是，对于任何特定样式是“灵巧”还是仅仅是高级用法，可能需要一些判断。问题中的代码就是一个很好的例子-您的解决方案不一定比另一个更好。有人会说是，有些人会不同意。由于这两种解决方案实际上都具有相等的运行时性能（请阅读：用户永远不会知道两者之间的区别），因此请选择整个团队最满意的样式。

在某些情况下，您需要教给他们更好的编码方法，但在其他时候，为了清晰起见，您需要妥协。

这可能已经在另一个答案中说过了，但是我想以我自己的命令回答这个问题。

一般准则

在团队中工作时，您不是代码片段的目标读者。您的听众是您团队的开发人员。不要编写没有充分理由就无法理解的代码。

1. 除非有特定的缺点，否则所有代码均应遵循特定的模式或指南编写，以使将要维护它的开发人员可以轻松地对其进行维护。（一个警告：仅仅因为它们当前在代码库中而遵循错误的模式是可怕的做法。）
2. 如果您找到使用目标受众不易理解的语言特定用法的充分理由，请添加注释。如果发现需要在每行中添加一条注释，则可能需要重写代码以使读者更容易理解。我认为为了惯用而惯用没有什么价值。

具体例子

我们的代码库中有大量的perl脚本。通常，我们仅将perl用于非常简单的操作，并且绝大多数代码是由Java开发人员编写的，因此其样式非常类似于java。我们有一套perl脚本和一个由“ perl专家”编写的框架，此框架后来离开了我们公司。该代码包含许多更晦涩的perl惯用语，而且包括我在内的所有开发人员都无法毫不费力地阅读此perl代码。我们经常为此诅咒他。:)

如果您编写了不错的代码，但您认为现在或将来的同事可能会很难遵循该代码，则应添加简短注释以对其进行解释。

这样，您可以教他们一些东西而不会侮辱他们的个人智慧或在小组讨论中使任何人尴尬。

我不会将您的示例称为技巧，而只是习惯用法。是否应该使用它，恕我直言不取决于您团队的当前水平，而是如果（至少有一些）您的队友愿意学习一些新习语。当然，您应该与他们讨论此主题，而不要对他们实施这种样式。而且，您不应该要求他们每天学习5项新事物或“技巧”。但老实说，如果您只有队友不愿意学习新的东西，即使它比这个惯用语那么简单和小，您也应该考虑改用其他团队。

阅读此问题以及随后的答案和讨论似乎有两点。第一个：可以使用高级语言功能吗？第二个：如何做到这一点而又不像我在“炫耀”？

在第一种情况下，使用改进和高级功能是有意义的。例如：在C＃中，您不必使用Linq或Lambda表达式，但是大多数人会这样做，因为一旦您真正知道它在做什么，它就会使代码更加整洁和易于理解。起初它看起来很奇怪。

人们习惯了模式，在许多情况下，人们只是采用固定的工作方式来完成工作。我和下一个男人一样感到内。我们都有截止日期。在某些方面，您有引入新思想和新思维方式的罪恶感！这是第二点，这可能是您可能遇到最大阻力的地方。

对于使用该网站的人，他们不在乎使用哪种样式，他们所关心的只是起作用了吗？快吗 因此，如果您的方式没有性能优势，那么在给出的示例中就没有正确或错误的方法。您的方式是否使代码更具可读性？一旦您的同事习惯了，它可能会起作用。

那么，您如何引入这些变化？尝试按照以下方式与您的同事进行讨论：您是否知道可以用这种方式编写此功能？代码审查和结对编程可能是允许想法“异花授粉”的好时机。由于不知道您所处的环境，我很难规定要做什么。我发现有些程序员可能非常防御并且抵制更改。我再次对此感到内gui。与这类程序员一起工作的最佳方法是花一些时间来学习使他们产生兴趣的东西，了解他们的背景，然后将自己的风格和经验与他们进行比较。这需要时间，但要花费很多时间。如果可能，请鼓励他们。

那就不要去皇家McBee计算机公司工作，因为谁能说您不是没有经验的程序员。

当然，编写简洁明了的代码非常好，并且在javascript环境中可能很有用（嗯，直到有人生产js编译器以下载到浏览器，但这是另一回事了）。

但是，重要的是，您的代码能够存活超过编写代码所花的几分钟时间。当然，它既快速又容易，您可以将其分块然后继续前进，但是如果您不得不在数年后重新使用它，那您可能会想到“哪个木偶写了这个”，而意识到是您！（我这样做了，可以肯定大多数人也有。。老实说，我怪罪过分激进的最后期限）。

这是唯一要记住的重要事情，因此，我要说的是-如果该特定操作符有效且明确，请与该特定运算符一起使用，并且您的“经验不足”的开发人员（尽管这对他们是贬义的，我知道很多缺乏经验的开发人员在记住各种网页教程和参考资料后就知道所有操作员和技巧，即使他们知道每一个小技巧，他们也会编写最糟糕的代码……这可能不仅仅是巧合了）

无论如何，如果您能读懂Mel的故事，即使Mel是一阶真正的程序员，您也会意识到这些技巧并不是最好的方法。有人说自己可以编写出色的代码，而其他所有人都需要学习更多以跟上发展的步伐，这是无可厚非的。

好吧，对于我来说，入门者看起来像基本的JS。

但是总的来说，您不应该使用聪明的技巧来解释“调试的难度是编程的两倍。如果您编写的代码尽可能聪明，那么根据定义，您将无法对其进行调试”。

这并不意味着您应该仅仅因为别人不理解而避免编写代码，而是应该以尽可能清晰和一致的方式编写代码。但是您的明确判断标准应该是“我一年会读一遍就能理解吗”，而不是“任何人都可以理解”。

用清晰的方式写出来，您不会有困难的理解，可以让其他人继续提高自己的技能-不要为了节省别人的假设麻烦而妨碍自己。

我将与我的队友讨论我们想要什么样的编码标准，因为这主要是关于如何以多种方式完成代码库的工作。如果达成共识，那将是我最初的答案。

如果没有，那么我可能会考虑哪种拟议的标准有意义，并且在与管理层和一些团队确认后，便开始将其付诸实践。这里的想法是确保管理层对此想法表示满意，并且我不仅要自己做自己的事情，然后强迫其他所有人接受。

我看这更像是您的团队拥有什么样的标准和实践的问题，而不仅仅是技能水平，因为有很多评估代码的方法。这些标准之一就是其他人能否保持这种状态。

问题在于您希望源代码具有良好的可读性，但是可读性在旁观者的眼中。

我建议我们需要更好的工具来解决此问题。没关系，请注意，我们已经拥有超过50年的技术来​​做到这一点。在编辑器中包括一个解析器，并让编辑器以sexps的形式保存源代码（是的，就像lisp一样）。然后读取源，编辑器将其解析为用户喜欢的语法和印刷（您知道，空格，制表符，逗号）。

这样，您可以打字和阅读x = x || 10，其他程序员会将其读为

if (0 == x) { x = 10;}

emacs具有轻松完成此任务的所有步骤。

为什么不提高代码质量，而不是降低代码质量呢？培训，指导，教育和改进的雇用实践可以对确保持续改进起到很大作用。
国家主义，代码腐烂，拒绝改进和创新是因为某人不想从事自我改进，只会给整个过程带来麻烦，而不是早晚。

当然，在您展示的特定情况下，您只是试图变得聪明而刻意编写模糊的代码，这绝不是一个好主意。代码首先应该是易读的，易于理解的，而不是为了表明您在尽可能少的语句中创建某些东西的聪明程度而编写的（特殊情况除外，如更多的语句会导致不可接受的性能下降，在这种情况下，称为大量注释对于）。