Coding style "；对于初级开发人员来说应该很容易理解；论点

有人真的认为这是一个很好的理由来“沉默”你的代码吗？

---

当一位经理要求您简化代码（就理解代码所需的技术技能而言）而代价是代码更加繁杂时，您应该怎么做？

是的。这是一个非常合理的理由，可以把它降低一个档次。现实情况是，大量的开发人员（和大多数人一样）处于初级阶段

至于你应该做什么。。。说“是的，先生”或“是的，女士”，然后去做。这种关系中只有一个老板

更新： 有些人似乎认为，让jr开发人员一边学习高级主题，一边费力地阅读模糊的代码，我想在这里再介绍一件事

当任何开发人员（jr或其他人）遇到他们不理解的代码时，他们的第一种方法是将其重构成可以理解的东西。这就是所谓的“哇，代码是垃圾，我必须重写它！”综合症。我敢打赌这个董事会上的每个人都经历过。所以，作为一个企业主，我是想在每次有新人来访时为开发的代码付费，还是想为添加的新功能付费

---

猜猜我会和哪个人呆得更久。

我非常不同意。初级开发人员最终将成为高级开发人员。怎么用？遇到学校没有教过的高级话题

我的代码库现在大量使用控制反转容器。我将永远不会将我的代码恢复到原来的方式，因为初级开发人员在摸索IoC时遇到了问题。相反，我会在下班后带他们出去喝杯啤酒，然后讨论这个问题。初级开发人员学习得越多，需要做的握手动作就越少

---

这里有一个讨论这个话题的例子。

不。过去，我从经验丰富的开发人员那里学到了很多技巧。我宁愿有机会从他们那里学到新东西，也不愿意让他们为我说些傻话。

好吧，如果你想永远维护你的代码，永远不要换工作，永远不要急于做新的事情，并且可以向所有人保证你永远不会被卡车撞到，然后，确保没有必要让那些困惑的代码哑口无言。

如果你一直在让你的代码或设计哑口无言，这是确保你的初级开发人员保持哑口无言的一个很好的方法。挑战他们，并将其作为指导机会。当然，有些人永远也学不到，但在这一点上你会遇到更大的问题

也不仅仅是头发尖的老板。作为一名高级开发人员，通常很难抵制吸引初级开发人员的冲动。“哦，我只会做这部分，因为这对他们来说太难了”，否则他们会花太长时间，或者他们会在杂草中消失

---

最后，确保在使用语言全部功能的惯用代码和滥用语言功能的惯用代码之间取得平衡。没有理由只为了在两个单独的线程中运行其参数而重写| |运算符。至少为你的年长、愚蠢、未来的自己将代码简化一点。

是的，在我看来，可读性和易于理解代码是可维护性的一大组成部分。

拼图代码和复杂代码之间有区别

---

我发现一个最大的问题是“通过阅读容易理解”和“考虑因素充分”之间存在很大的差异，而且这两个目标往往直接相互矛盾。在结构良好的代码中，类之间的跳跃和虚拟调度要多得多，因此代码的路径是非常非线性的。

我不同意管理者的观点：需要简单的是代码，而不是用来编写代码的技术

然而，我将提出一项密切相关的要求：

• 内部文档清楚地说明了理解此代码需要哪些技术，并提供了可以学习这些技术的地方的参考

---

例如，即使作为一名高级开发人员，我发现所有矩阵代码都令人困惑。但是，如果有人给我一个正确部分的参考，我可以猜出细节。

如果你把你的代码弄哑了，你将被困在与那些永远不会熟悉高级编码技术的低级程序员的工作中。如果有任何冗长的代码试图表达您编写的固有的复杂过程，那么前面提到的初级开发人员可能无论如何都看不到森林。如果他们必须表达一个复杂的概念，如果他们只知道基本的原始结构，那么他们可能会搞砸，而如果他们知道如何简洁优雅地表达他们的意思，那么代码就更有可能是正确的。

我建议将代码保持在“极客级别”并对其进行良好的注释，以便年轻人能够理解代码背后的意图，同时学习更好的编码方法（或正确的编码方法），这样我们就可以两全其美。

这取决于代码。您的旗舰产品中是否有需要使用经理出于性能原因希望您删除的功能的产品？如果答案是肯定的，我会让你的经理让你保留代码，然后写一份文档详细解释代码中难以理解的部分。如果它是一个内部应用程序，需要由许多不同的人维护，并且复杂的功能可以在不影响程序的情况下删除，请删除它们并选择更重要的战斗。

这是一种平衡行为…
如果你的团队中有三个人可以“阅读”你的代码并知道它在做什么。。。不需要改变。然而，如果你是唯一能理解你的代码的人（不管你认为它有多聪明）。。也许你应该把它降低几级

另一个有用的指导方针是“尝试最简单的方法”