我最近注意到了很多与不同抽象技术有关的问题，并回答说基本上这些技术都是“太聪明了”。我认为，作为程序员的一部分工作是为我们所要解决的问题确定最佳解决方案，而聪明有助于做到这一点。

所以我的问题是：那些认为某些抽象技术过于聪明而不是聪明本身的人，或者是否有其他理由提出反对？

编辑：此解析器组合器是我认为是聪明的代码的示例。我下载了此文件并查看了大约半小时。然后，我在纸上逐步进行了宏扩展并看到了光。现在我了解了，它似乎比Haskell解析器组合器更优雅。

简单的解决方案更适合长期维护。这并不总是与语言熟悉有关。即使您是给定语言的专家，一条复杂的线（或多条线）也需要花费时间才能弄清楚。您打开一个文件并开始阅读：“好，简单，简单，明白了，是的，WTF ？！” 您的大脑停止运转，现在您必须停止并解密一条复杂的线。除非有一个可测量的，具体的实施理由，否则它“太聪明了”。

随着复杂性从一个聪明的方法变成一个聪明的类再到一个聪明的模式，弄清正在发生的事情变得越来越困难。除了众所周知的方法外，您还必须弄清楚创建“聪明”解决方案所需要的思考过程，这可能非常困难。

就是说，我讨厌避免模式（在合理使用时），因为有人可能不理解它。作为开发人员，我们有责任继续学习，如果我们不了解某些内容，那就是学习它而不是避免它的原因。

吻原理

保持简单，愚蠢。聪明的解决方案很棒，但通常最简单的直接解决方案是最好的。

“调试的难度是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，就定义而言，您就不够聪明，无法对其进行调试。”

布赖恩·克尼根（Brian Kernighan）

愚人忽视复杂性；实用主义者遭受苦难；专家避免 天才将其删除。-艾伦·佩利斯（Alan Perlis）

最好的解决方案并不总是最聪明的解决方案。有时简单的解决方案同样好。

在软件中，您始终需要考虑可维护性。如果一段代码对于要维护它的人来说太聪明了，我会说聪明是不值得的。

引用Brian Kernighan的话：

“调试的难度是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，就定义而言，您就不够聪明，无法对其进行调试。”

聪明是一种工具；它本身无害。它只会在没有必要的情况下变得有害。

当应用于代码时，“聪明”几乎总是对“不必要复杂”的委婉说法。

读取良好，清晰，简单的代码已足够困难。读“聪明”的代码就像重新学习拉丁诗一样。

之所以产生这种混乱，是因为“聪明”作为一个人的属性具有完全不同的含义。这种情况也可以看作是为真实的人设计软件为何如此困难的一个示例：因为它们模棱两可。

并且由于某些程序员难以理解大多数人遵循的社交协议，从而禁止他们直接谴责代码“不必要的复杂”，因此他们可能很难区分“ 聪明 ”一词的两种含义。与某些人的想法相反，我认为最终更好的“人”（意味着：有同情心，内省和耐心的人）可以成为更好的开发人员。因为他们知道为谁写。

大多数人都从“代码需要太多的解密才能弄清楚它在做什么”这一方面以及随之而来的所有不好的方面来关注聪明。

1. 没有人能弄清楚它，更不用说对其进行维护/调试了。
2. 写作的人甚至都不知道它做什么。
3. 一开始可能实际上并不是那么出色
4. 等等....

所有的优点，但聪明还有另一个负面方面，那就是旧的自我问题。这会导致以下问题：

1. 太“聪明”的人无法使用其他人的解决方案。当您可以发明自己的给同一只猫剥皮的方式时，为什么还要寻找别人做过的事情？
2. 认为自己发明了最酷的解决方案的人通常会拒绝接受任何意见。
3. 即使有明显的问题或需要进行微小的更改，也不允许任何人修改“其”代码。
4. 相反，他们认为他们很聪明，需要使用“最新”技术来证明自己的聪明，但是在将其滚动到项目的关键部分之前，无论是在个人项目还是在非生产代码中都无法很好地掌握它。系统。

有时候我们都对自我感到内，但是当它阻碍了团队的发展时，这就是一个问题。

良好的聪明-聪明的代码行与非聪明的选择中的行之间的比率很高。20行代码使您无需编写20000，这是Extremely Good Clever。好聪明是关于节省自己的工作。

不好的聪明-编写的代码行与保存的代码行之间的比率较低。避免编写五行代码的聪明行之一就是Bad Clever。不好的聪明是关于“句法手淫”的。

请注意：Bad Clever几乎从未被称为“ Bad Clever”。它通常会以“美丽”，“优雅”，“简洁”或“简洁”的别名旅行。

我想知道每个人对聪明的定义。

就个人而言，当我解决一个棘手，复杂的问题并以非常简单和直接的方式实施它，同时又保持可接受的效率水平时，我感到自己很聪明。

tl;博士，我在代码审查期间说“哇，这比我想象的要容易得多”，而不是“这就是wtf”。

除了列出的理论答案之外，通常在其他所有人都太聪明的情况下使用它。

有时在顶级性能密集型团队和中级维护团队之间移动，以了解“太聪明”的实际生活差异。

撇开理论上的论点，太聪明通常是基于技能最差的团队成员可以合理地工作的，因此它与环境非常相关。

有时候我很聪明，以至于我错了。

性能，可维护，及时和廉价是我衡量解决方案的方式。我想聪明也可以成为解决方案的一部分，只要它不会对这些质量产生负面影响。

如果聪明的代码+使它成为可理解的代码<=简单代码所需的注释数量，那么我说去聪明的代码。每次。

我认为，当人们编写“聪明的代码”而故意不正确地评论它时，就会出现这个问题，因为只有一开始就无法理解它，以后的下一代才不得不花时间“欣赏”它的聪明之处。

我想起了我曾经看到的引述给许多不同人的引文，因为引号经常是好的。

释义：

任何有智慧的人都可以使简单复杂化，使复杂简单化需要天才。

采取一个复杂的想法并将其简化以使其易于理解，这说明了构造函数的聪明之处，但采取简单的想法并使之变得复杂则表明该构造函数希望被视为聪明的想法。

如果很难找到“聪明”的解决方案，那么就不应该使用它。例如，如果通过副作用您可以将复杂的计算压缩到一行，那么它就很聪明。但是，如果别人花一个小时弄清楚您所做的事情，那就太聪明了。

我认为，聪明本身并不是问题。通常，我们会混淆“聪明”（没有讽刺）和“ insightfull”代码。我看到的一个问题是，通常“聪明的”（带有讽刺意味的）代码包含隐式的不可见需求，这使得随着时间的推移调试和维护变得更加困难。

有几种已知的聪明算法。IMO是Quicksort之一。

“聪明的”（带有讽刺性的）代码通常会假设设置的变量和系统状态实际上与“聪明的”代码断开了连接（如先前打开的文件，网络连接，数据库等）。

为了正确维护“智能”代码，您必须加载到大脑上的数据量通常很大，以具有良好的成本效益比。

“聪明的代码”是程序员必须认真思考或使用一些高级技能编写的任何代码。这个问题忽略了布莱恩·W·科尼根（Brian W. Kernighan）最能表达的“聪明的余地”的需要：

“调试的难度是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，那么就定义而言，您就不足以调试它。”

因为什么样子的小聪明在创意一阵开发者可以简单地通过为混乱和公正是不可读的，不可维护的块不起眼的谜语他人。

不过，这是一个很好的，聪明的，表现良好的难题，但是，如果您有经验，就会经常意识到，要在中等水平上维护这些东西，您的业务（而不是开发人员）会付出更多的代价，或长期的。因此，您更希望在开发人员同居时平息他们的热情。

当然，除了有理由为聪明之外。而且，如果您刚刚编写的晦涩难懂的内容附带了一个很好的文档。您确实评论了这段聪明的代码，对吗？说明它的意图，为什么要像它，以及它的行为方式？

如果没有正当理由，那么可能只是过早的优化，过度设计或YAGNI之类的问题。如果需要15个级别的间接操作来完成简单的操作，那么您很有可能也属于先前的类别。如果没有记录，那就很麻烦。

出色的代码不应该要求维护人员一直都花100％的时间来理解它。好的代码很聪明。出色的代码几乎可以高效，但在许多其他方面却更好。出色的代码不需要具有15个视图的IDE即可遵循应用程序的设计。

注意：嘿，我写了一些我认为很聪明的东西，但这吸引了WTF？如果不是我的共同开发者的话，就是我经理的话。必须从他们的角度来看它。

我倾向于聪明，但我努力做到优雅。

现在开发代码，其他人将不再尝试并避免以后再使用。

根据我的经验和其他答案，这是我对问题的理解：

1. 巧妙地编写但可读且可维护的代码不被认为是有害的。但是，大多数开发人员不会将这种代码称为“聪明”。他们可能会使用其他术语，例如“优雅”。关于此类代码是否存在，可能存在或可能没有争论。
2. 即使是经验丰富的开发人员也需要花费大量时间和精力来理解它的生产代码是“聪明的”，并且每个人都认为这是有害的。
3. 某些经验不足的开发人员需要花费大量时间和精力的生产代码被认为是有害的。我看到过任何一种答案，并且我与开发人员合作，他们明确表示他们希望保留所有内容“最低的公分母”。

我认识一个人 他可能是我见过的最聪明的人。他绝对是一个令人难以置信的编码器，就纯粹的编程技巧而言，可能比我一生都要好。他就像在键入Word文档一样编写代码，并且可以像您不相信的那样反向链接列表。如果您想谈论编写一些非常复杂的代码，那么他就是您的助手，如果我遇到难以置信的难题，那么我总是向他求助。但是，与他一起在团队环境中进行项目工作实在令人发指。他无法直接针对业务问题，也无法提供合理，高效和简洁的解决方案。对他来说，列出1000行的代码比100行更好。他将使用自己的超级优化工具，而不是使用通过IDE或框架提供给他的工具。

我钦佩他做这些复杂事情的能力，但我需要的是可以解决问题并继续前进的人。不好说或接受，但是有时候在企业环境中，时间就是一切，您只需要解决问题并继续生活，您就可以稍后再回到问题上，并重构它来改善自己您的代码。聪明和屁股之间有一条细线。我对团队的座右铭始终是，在这种情况下可以解决的最简单的事情是什么，然后从那里开始。有时，简单并非总是答案，但它是一个很好的起点。

在本文中，“聪明”的意思是“对自己的利益太聪明”，即某种东西现在可以工作，但以后将成为理解和改变的噩梦。

特别是如果这是一种利用编程语言的晦涩特征的技巧，或者利用了怪异的副作用，或者是用目标语言解决问题的一种真正怪异的方式。

我更喜欢简单的解决方案，我真的很喜欢红宝石方式。例如，当您想要对列表中的前2个元素求和时。首先，剪切列表以使其具有size = 2，然后对其求和。

我记得曾经使用过1个列表而不是3个列表，并创建了一个很难维护/更改的大功能。

在当今世界，我们不必为了提高性能而牺牲代码的清晰度（除了c ++，他们不必这样做，但他们会这样做）。

通常，当您需要“聪明”时，可以解决代码中的问题。如果变通方法不是很简单，那么在假定某些条件（编写代码时可能100％正确）时，您会得到很多困惑的面孔或其他奇怪的副作用。

因此，聪明==令人困惑==不好:(但当我将它们用于有限问题的实际解决方案时，它也很棒。

重新报价以获得上下文和更容易理解的内容：

“调试的难度是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，那么就定义而言，您就不足以调试它。”

布莱恩·克尼根（Brian Kernighan）在这里写的显然是指卷积，他错误地使用了“聪明”一词。

“调试的难度是一开始编写代码的两倍。因此，如果您尽可能以[卷积]的方式编写代码，那么就定义而言，您就不足以调试它。

卷积：

A thing that is complex and difficult to follow.

聪明：

Showing intelligence or skill; ingenious

受过良好教育的程序员知道简单的代码是巧妙的。根据定义，尽可能聪明的代码应该很简单。受过良好教育的程序员也将避免使用和编写像瘟疫这样的复杂代码。只要有机会，他们还将把复杂的代码转换为聪明的代码。通常，代码是一开始就令人费解，并且随着经验和共享知识可以更好地理解编程领域中的知识和对人类认知能力的理解，从而变得更加聪明。

由于此行情的流行以及Brian Bernighan在行业中非常流行，因此对该词的误用会对社会产生负面影响，老实说，我很想看到这个人自己解决的问题。在撰写本文之前，我尝试查看是否可以简单地通过电子邮件向他发送电子邮件，但是我找不到我理解的任何电子邮件联系信息:(.。

我看到的负面社会影响是其他程序员排斥他们更聪明的同事，因为他们现在认为聪明是一个问题。真正的问题是愚蠢的同龄人，他们认为自己以一种新的，独特的方式做事很聪明，并且在没有优势的情况下不断发明新事物，而不是获得和理解更大的社区并尽可能多地重复使用聪明的想法。

我确实需要澄清一下，尽管经常要了解才能比发明自己的要困难。由于行业中普遍存在不现实的截止日期问题，因此为较小的利基问题发明自己的产品将节省时间。这是基于以下观察：有用的，可重复使用的事物通常以更大的利基为目标，或者为发明提供有用的抽象。这还基于这样一个事实，人们瞄准大型壁ches以赚取更多的钱，而这往往使该工具极难使用，因为要使某物可用于广泛的应用程序涉及到复杂性。

另一个负面的社会影响是，这阻碍了进步和理解的欲望，因为在我们的自我中心世界中，我们将立即否认自己缺乏理解，并写下被混淆的代码，即使一旦被理解，这个想法实际上就是相当聪明。

TODO我想引用一些参考，但我也希望缺少参考，以免妨碍我共享信息的能力，因此我将快速引用我所记得的信息来源，也许我会找到一些实际信息。一天（或者您可以为我找到它！:)

• 吉多·范·罗苏姆（Guido Van Rossum）谈及事件循环以及他如何理解事件循环
• 一名GitHub员工表示，他们避免在Y-Combinator上雇用聪明的人
• Python社区中正在进行许多讨论和学习。Python社区特别批评新想法，但不会拒绝他们无法理解的新想法，并且通常可以将最初被认为是令人费解的功能看作是核心语言功能/包。
• 基于我的10000英尺观察，我自己的经验和专业意见。我从那里一直看不到启发的具体细节:(希望您的经验和观察会告诉您同样的事情，并且其他人可以在下面发表评论以给这个答案一些好处。

随意添加自己的引用！另外，请随时在我的文本中添加逗号。我已经有相当一段时间没有刷新我对英语逗号用法的了解了...

因为人们常常不懂某种语言，习语和模式。他们可以拿一本书来学习，但事实并非如此。由于这些人，您应该编写简单的代码。

这不是一个聪明。这是一种知识。

我找不到任何地方提到在这里的话纪律，所以我会凑钱，我不希望发布的答案，但对此事有着不同的见解，也许一个，原来的问题没有考虑到有。

聪明的开发者是一件好事。

然而，在聪明之前，还有其他特征。您可能已经意识到，我将谈论纪律。对于系统的长期可维护性来说，一个聪明而不受纪律的开发人员可能会很不利。

假设出现错误或提出了新要求。一个聪明的开发人员可能很快就会意识到，几个本地修复程序将在2分钟内完成工作。如果该开发人员受到纪律处分，他将阻止将这些修补程序应用于源代码，而是将找到一种有意义的方式来将所需的行为组合到系统中。这样，下次需要修改特定代码段时，维护人员将有一个轻松的时间来理解代码并实现新的更改而不会破坏任何内容。如果没有，那你就知道了。