最佳做法和常识之间的区别？

关于软件开发中的最佳实践¹的讨论很多。我已经看到至少有3个主要观点在SE和其他地方引起了很多讨论：

• 什么是最佳实践，为什么？
• 可以断言没有最佳实践是“最佳”实践，因此最佳实践甚至在一开始就值得讨论吗？
• 您什么时候应该放弃最佳做法-或也许是大多数最佳做法-是因为它似乎不适用，还是由于外部限制（时间，金钱等）使权衡取舍变得不切实际？

似乎很少出现的事情，但比以往任何时候都多，这是软件开发中的常识概念。最近的经验再次使这个想法浮现在我的脑海。

我的最初印象是，与最佳实践不同的是讨论，但可能存在交叉授粉。

当我想到一般意义上的常识时，我想到的是您已经掌握或接受的一组规则，这些规则为您提供推理和做出决定的基线。遵循常识是避免您射出整条腿的好方法。但是，除了较低的基准线外，常识可以让人们做出有根据的决定，而当证据看起来足够有说服力时，有根据的决定甚至可以超越常识。我可能对这里的定义有些松懈，但我认为它已经足够接近我的榜样了。

当我想到软件开发中的常识时，我想到了所有基本卫生规则，以防止代码库迅速腐烂成无法理解的混乱。例如，不使用单个全局结构来维护和传递非平凡程序中的状态；不使用只是乱码的变量/方法/类名；这些可能非常类似于我们称之为反模式的东西。在将最佳实践应用于学习模式的实践模拟中，将常识视为学习反模式的实践模拟。

考虑到这一点，我想提出一些问题，看看其他人的回答可能会帮助我确定自己的方式。

其他人是否认为软件开发中存在常识？知道任何一种推理方式都会很感兴趣。

如果是这样，是否值得讨论？我们是否应该像有时采用最佳做法一样努力推动这一工作？是否值得进一步努力？

如果与反模式的类比看起来合理，那么一般规则是，只有在没有其他方法的情况下才使用反模式，甚至只有在非常有限的情况下才使用反模式。允许代码库偏离常识的灵活性应该是多少？答案“根本不是”似乎是不合理的，因为有时权宜之计要求偏离。但是，这似乎是与何时采用“最佳实践”不同的论点。也许不是；如果您不这样认为，我想学习为什么。

这是开放的，也许值得一个后续的问题，您会指出什么样的建议，这似乎是常识呢？

也欢迎其他想法。

¹也许我会更好地称它们为“常见重复出现的域模式”，但是“最佳实践”这个名称已经足够普遍，即使每个人都不认同它们是什么，也知道了它们的本质。如果“最佳”部分困扰您，请想象我用不太权威的话语代替了“最佳做法”。

最佳实践是已发现在相对广泛的环境中效果很好的实践。它们的问题在于A）表达式有时被滥用以进行营销，B）作为固定规则，它们不够灵活；在不考虑是否适用于当前情况的情况下，不应遵循一组固定的规则。

最佳实践很好地解释了为什么它们是“最佳”，以及在什么情况下应使用它们。然后，您可以推断何时不使用它们。

“常识”的问题在于它太灵活了-它可以用来为几乎任何事情辩护，当人们不同意并且双方都声称自己的立场是“常识”时，您就无法进行理性的讨论。有一个好的指导原则，但是对于团队遵循的指导原则却很糟糕。

我想你倒退了。

当教程序员安全性的基本知识时，我总是教他们使用安全性，best practices但是当与安全专家（或更多“具有安全性经验”的程序员）打交道时，我永远也不会讨论best practices，实际上我经常会违反它们。

更好的定义是：

“最佳实践”是专家的常识，应由非专家应用。

也就是说，除非您在给定领域具有足够的专业知识以了解微妙的权衡取舍，否则您无需声称“常识”。并且当您这样做时，您不应再盲目地遵循“最佳实践”的规定。

除非您有足够的经验来使用自己的“常识”，否则“最佳做法”是一个临时占位符。

最佳做法->“首先，您要学习规则”。经验->“然后，您将学习何时以及如何打破它们”。

愿意尝试替代方案（当然，使用非关键代码-最好是个人项目和一次性方案）可以帮助您建立所需的体验。

当然，常识与经验是不一样的，而且您不一定总是需要太多经验才能看到在错误的位置应用良好技术的缺陷-但是为过度应用和错误构造错误的合理化很容易一项技术的应用不足，并且由于这里的“常识”显然不是编程的先天知识，因此这种感觉显然仅在特定组中才是“常识”。

“取得优势”非常容易。实际上，不可能避免-有时一侧确实是正确的，而另一侧确实是错误的，并且主张平衡是不合理的。这里的麻烦在于，真正的地狱并没有太多权衡一种相关性的最佳做法，而是当两种相互冲突的最佳做法意见冲突时。

处理此问题可能更多是关于人际技巧，而不是技术技巧。我对此很不好:-(

尽管如此，从他人的经验以及您自己的经验中学习仍然很重要-即找出最佳做法是什么，为什么使用它们以及优点（或缺点）是什么。

在我看来，这个问题是语义上的骗局。如果我们使用这些定义，那么毫无疑问：

最佳实践：一种在给定领域中解决问题的经过实践证明的方法（即，实时最佳实践对于数据库最佳实践是完全陌生的）

常识：专业经验，可警告程序员要避免的陷阱

最后，最佳实践是一种解决特定问题的元设计模式，它是根据实际经验选择的，而“常识”则是基于对多个问题集的总体观察来解决问题的指南。

Common sense = You.CommonSense

Best practices = Sum(Experts.Experience + Experts.CommonSense)

有趣的时机。上周发表了这篇文章，讨论了为什么常识不一定在所有情况下都是理想的。

常识非常适合处理日常情况下出现的那种复杂性...由于它在这些情况下非常有效，因此我们倾向于在所有情况下都信任它

（我的粗体字）

基本上-人类在我们尚未开发根深蒂固的系统等领域并不擅长使用常识，因此我们应该始终使用一套有文档记录的标准，而不要依赖我们自己的常识！

常识不对应于学习反模式，也不与最佳实践相反或相反。

常识的第一个问题是它的名字-它得出结论，它既是常识又是明智的。通常，它在两个方面都容易受到攻击。使用您的示例：

仅在没有其他方法的情况下才使用反模式，即使如此，也只能在非常有限的情况下使用

据我了解，这不是反模式的产生方式。这是由于文化和社会因素的增加；在相当长的一段时间内无视最佳实践和标准；忽略将来获得短期收益的成本-例如通过使用捷径解决方案（作为维护的噩梦）来满足最后期限；等等。没有机构着手采用反模式-他们只是在成长。

同样地，常识经常被用来表示“通常完成的事情”，并证明缺乏思想，洞察力和努力解决解决方案所涉及的内容是合理的。它也被用作“按照我的方式做事的理由，因此很显然是常识” –以及对审查和批评的辩护。

就最佳实践而言，@ Michael的前两段是最佳实践应有的极好的总结-一种资源，可帮助每个人改善自己的工作。它还提供了决策（尤其是设计决策）的透明度以及向他人学习的能力。最佳做法的缺点是，当它生成清单文化时-“我已经勾选了所有框，所以我所做的一切必须没事”-无需对清单的适用性进行思考，谨慎和关注。

这是一个滑溜溜的论点，常常演变成一场宗教战争。

几乎所有的最佳实践都可以用相反的有效案例来应对。

一些最佳实践比其他一些最佳实践。全局状态变量几乎总是可以用其他方法更好地完成，而GOTO通常不是一个好主意，但是当您进入模式/反模式或直接数据/抽象数据参数时，它会变得不清楚。在您开始谈论开发方法和实践时，尤其如此。

在某些情况下，常识和最佳实践甚至相互矛盾。

没有最佳实践的管理机构，即使存在单个小组，也无法为每种可能的情况定义每种可能的“最佳”。标记为最佳做法的许多东西只是试图向不知情的个人出售工具或培训的不良营销。

即使您的整个团队都同意某件事是最好的，也不一定总是能够在各种约束因素下以这种方式实现它。

恕我直言，您必须使用最佳实践作为指导，以指导您在设计中应更仔细地考虑什么。您可能有偏离的正当理由，但您可能需要确保团队中的其他所有人都同意，然后再去做一些奇怪的事情。

在那之后，关于最佳实践的一些争论几乎可以归结为不构建下一个必须进行开发的开发人员会讨厌的东西。每个人都讨厌不是他们风格的代码，每个人都将一切归咎于任何离开的人，所以要么在他们抱怨某件事后向下一个开发人员解释它，要么您就不会呆在那里而被别人说坏话无论您如何编码。这使得该担忧基本上是无关紧要的。

常识并不总是能产生最佳结果。但是，已经尝试了最佳做法。这使最佳做法成为更可靠的信息来源。

最佳实践并非最佳，常识也不常见。;-)

无论是最佳实践还是常识，我都喜欢将其视为模式。请记住模式的定义：上下文中的解决方案将力转化为结果上下文。

对于您想做的任何事情，您都应该知道它所适用的上下文，它所解决的力量以及所产生的结果上下文。然后，决定您的团队通常要使用的模式。（这可以是正式的也可以是非正式的，但无论哪种方式，它都比《四人帮》大得多。这包括语言习语和本地帮助程序库，而不仅仅是已发布的模式。）

如果根据经验，在某种情况下，最好不要使用给定的模式，而要做其他事情，让人们知道。此处的上下文或力量可能有所不同（或者可能会导致不必要的上下文。）我不在乎这是开会，代码注释还是其他内容，但是如果您明确表示自己故意破坏了模式，您将遥遥领先。

最佳实践是他们在学校教给你的东西，常识是老板想要你形成的东西。前者创建的软件符合某些优雅，风格等标准。后者支付账单/赚钱，因此您每周都会得到付款。

一种是艺术，另一种是业务，我们太多人忘记了它。

夸大一点：区别是常识是偏见，最佳实践是（应该）科学

以我的经验，当人们不想提供证据或至少不想为一种做事方式提供论据时，会使用“常识”。这并不意味着方法必然是错误的，但这也不意味着它是好的。

在我遇到的事物中，这些宝石被合理化为蜜蜂的常识。

• HTTP方法在很大程度上无关紧要，在传输少量数据时使用GET，在传输更多数据时使用POST（即，对于URL来说使用太多）
• 函数不应太小，因为很难记住它们的作用。一个大功能优于5个小功能，因为您可以将其读为一个
• 数据库和Web服务器必须在同一台计算机上运行，​​否则Web服务将变慢。扩展的唯一方法是通过黑客和放弃抽象来加速代码，以便一台机器的功能就足够了。

关于“常识”的有趣之处在于，它并不那么普遍：挑选两个团队，让他们陈述他们所谓的“常识”，并享受宗教战争。

另一方面，作为“最佳实践”，我会考虑做一些具有更多“同行评议”的方式。为了将某事视为“最佳实践”，我希望对其进行足够清晰的表述，以便可以将其表示为一个概念（“结构化编程”是最佳实践，“傻瓜令人困惑，避免使用它们”是常识），并且多次涂抹，效果良好。