哪种流行的“最佳实践”并不总是最好的，为什么？[关闭]

“最佳实践”在我们行业中无处不在。一对“编码的最佳实践”谷歌搜索变成了近150万个结果。这个主意似乎给很多人带来了安慰。只需按照说明进行操作，一切都会很好。

当我读到一种最佳实践时（例如，最近我刚刚阅读了“ 清洁代码”中的几本），我感到很紧张。这是否意味着我应该始终使用这种做法？有附带条件吗？在某些情况下可能不是一个好习惯吗？在我进一步了解该问题之前，如何确定？

清洁代码中提到的几种做法并不适合我，但老实说，我不确定这是否是因为它们可能不好，或者这仅仅是我个人的偏见。我确实知道，技术行业中的许多杰出人士似乎都认为没有最佳实践，因此至少我那令人烦恼的疑问使我成为了一个好公司。

我已经阅读的最佳实践的数量太多了，无法在此处列出或询问个别问题，因此我想将其表述为一个一般性问题：

在某些情况下，哪些通常被称为“最佳实践”的编码实践可能不是最佳选择，甚至是有害的？这些情况是什么？为什么使这种做法不佳？

我希望听到有关具体示例和经验的信息。

我想你已经把这句话打在了头上

我讨厌把事情看成是面子，而不是批判地考虑

当它没有解释为什么存在时，我几乎忽略了所有最佳实践

雷蒙德陈说得最好在这篇文章中，他说：

好的建议带有基本原理，因此您可以分辨出什么时候变为坏的建议。如果您不理解为什么应该做某事，那么您就陷入了对货物崇拜编程的陷阱，即使不再需要甚至变得有害时，您也将继续这样做。

最好将其放入环中：

Premature optimization is the root of all evil.

不，这不对。

完整报价：

“我们应该忘记效率低下的问题，大约有97％的时间是这样：过早的优化是万恶之源。但是，我们不应该在这3％的临界水平上放弃机会。”

这意味着您可以在整个设计过程中利用特定的战略性能增强功能。 这意味着您将使用与性能目标一致的数据结构和算法。这意味着您了解影响性能的设计注意事项。但这也意味着您这样做时不会轻率地进行优化，这样做只会给您带来可观的收益，但会牺牲可维护性。

需要对应用程序进行良好的架构设计，以免在您向它们施加少量负载然后最终重写它们时，它们不会在最后崩溃。缩写词的危险在于，开发人员经常以它为借口，根本不考虑性能，直到最后对它做任何事情都为时已晚。最好从一开始就建立良好的性能，前提是您不关注细节。

假设您正在嵌入式系统上构建实时应用程序。您选择Python作为编程语言，因为“过早的优化是万恶之源”。现在，我对Python没有任何了解，但这是一种解释语言。如果处理能力有限，并且需要实时或近乎实时地完成一定数量的工作，并且您选择的语言需要比您的工作具有更大处理能力的语言，那么您就很费力。现在必须从一种精通的语言开始。

每个函数/方法返回一个。

不要重新发明轮子是一种被广泛滥用的教条。它的想法是，如果存在合适的解决方案，请使用它而不是创建自己的解决方案。除了节省精力外，现有解决方案可能比最初设想的要更好地实施（无错误，高效，经过测试）。到现在为止还挺好。

问题是几乎没有100％合适的解决方案。可能存在80％合适的解决方案，使用它可能很好。但是60％合适吗？40％？您在哪里划界线？如果不划清界限，最终可能会在项目中合并一个blo肿的库，因为您正在使用其10％的功能-只是因为您想避免“重新发明轮子”。

如果您确实发明了轮子，那么您将获得所需的一切。您还将学习如何制作轮子。边做边学不应被低估。最后，定制轮可能比现成的通用轮更好。

“对所有内容进行单元测试。”

我听说它经常说所有代码都应该具有单元测试，这一点我不同意。对方法进行测试时，必须对该方法的输出或结构进行任何更改两次（在代码中一次，在测试中一次）。

因此，我认为单元测试应该与代码的结构稳定性成比例。如果我是从下往上编写分层系统，则我的数据访问层将测试wazoo。我的业务逻辑层将经过很好的测试，我的表示层将进行一些测试，而我的视图几乎没有测试。

始终对接口进行编程。

有时只有一个实现。如果我们将提取接口的过程推迟到看到需要接口的时间，我们通常会发现它是不必要的。

不要使用任何开放源代码（或.NET开发人员使用的非Microsoft）

如果Microsoft不开发它-我们不在这里使用它。想要使用ORM-EF，想要使用IOC-Unity，想要记录-企业记录应用程序块。有这么多更好的库存在-但是我总是被困在开发世界的美元菜单中。每当我听到“ Microsoft最佳做法”时，我都会发誓我认为《麦当劳的营养指南》。当然，如果跟随他们，您可能会生存，但您也会营养不良和超重。

• 请注意，这可能不是您的最佳做法，但这是我在几乎所有工作领域都遵循的常见做法。

面向对象

有一个假设，就是因为代码是“面向对象的”，所以它非常神奇。因此人们继续将功能压缩到类和方法中，仅是面向对象的。

所有代码都应加注释。

不，不应该。有时您会有明显的代码，例如，在设置器做一些特别的事情之前，它们不应被注释。另外，为什么我要这样评论：

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

方法论，尤其是混乱。当我听到大人使用“ Scrum Master”一词时，我不能保持直面。我非常厌倦听到开发人员抗议方法论X的某些方面对他们的公司不起作用，仅由Guru So-and-Su告诉他们，它行不通的原因是实际上他们不是真正的从业者X的方法论。“加倍努力，我的Padawan学习者必须加倍努力！”

敏捷方法中有很多智慧-其中很多--但是它们经常被堆满很多肥料，以至于我无法抗拒呕吐反射。从Wikipedia的Scrum页面获取以下内容：

Scrum中定义了许多角色。根据它们在开发过程中参与的性质，所有角色都分为猪和鸡两个不同的组。

真？猪和鸡，你说呢？迷人！迫不及待想向我的老板推荐这个...

对象关系映射... http://en.wikipedia.org/wiki/Object-relational_mapping

我既不想从我的数据中抽象出来，也不想失去那种精确的控制和优化。我在这些系统上的经验非常差...这些抽象层生成的查询甚至比我从离岸外包中看到的还要糟糕。

将函数名称写成英语句子：

Draw_Foo()
Write_Foo()
Create_Foo()

等等，这看起来不错，但是在学习API时会很痛苦。搜索“以Foo开头的所有内容”的索引有多容易？

Foo_Draw()
Foo_Write()
Foo_Create()

等等

MVC-我经常发现，将许多Web设计问题纳入MVC方法中，更多的是使框架（导轨等）满意，而不是简单或结构。MVC是“建筑宇航员”的最爱，他们似乎过于重视简单的支架。嗯

基于类的面向对象-在我看来，它鼓励了可变状态的复杂结构。多年来，我发现基于类的面向对象的唯一引人注目的案例是构成任何面向对象的书的第一章的老套“形状->矩形->正方形”示例

雅尼

（您将不需要它）

当我不得不在现有代码库上实现功能时，这种方法花费了我数小时的时间，而如果仔细计划，这些功能将事先包含在这些代码中。

我的想法经常由于YAGNI而被拒绝，并且在大多数情况下，后来有人不得不为该决定付费。

（当然，可以说设计良好的代码库也可以在以后添加功能，但实际情况有所不同）

对于SQL

1. 不要使用触发器
2. 始终将表格隐藏在视图后面

为了：

1. 它们是拥有它的功能。您有一个表的多个更新路径，还是需要100％审核？

2. 只是为什么 如果要重构以维护合同，我会这样做，但当我读完该文档后，便不会更改视图以匹配任何表更改

编辑：

数字3：使用EXISTS避免*。尝试1/0。有用。列列表未按照SQL标准进行评估。第191页

主要是设计模式。它们被过度使用和利用不足。

单一责任原则

^{（“每个班级应该只有一个责任；换句话说，每个班级应该只有一个，并且只有一个改变的理由”）}

我不同意。我认为一个方法只应该有一个改变的理由，并且一个类中的所有方法应该彼此之间具有逻辑关系，但是该类本身实际上可以做几件事（相关的事情）。

以我的经验，这个原则常常过于热心地应用，并且您最终会遇到许多微小的单方法类。我工作过的两家敏捷商店都做到了。

想象一下，如果.Net API的创建者具有这种思维方式： 我们将拥有ListSorter，ListReverser和ListSearcher类，而不是List.Sort（），List.Reverse（），List.Find（）等！

我不再分享SRP （从理论上讲它并不可怕），而是分享一些我漫长的轶事经历：

在我工作的地方，我写了一个非常简单的最大流量求解器，它由五个类组成：一个节点，一个图，一个图创建器，一个图求解器，以及一个使用图创建器/求解器来求解一个类的类。实际问题。没有一个特别复杂或很长（求解器最长的〜150行）。但是，确定类具有太多的“职责”，所以我的同事着手重构代码。完成后，我的5个班级已扩展到25个班级，它们的总代码行是原来的三倍多。代码的流程不再明显，新的单元测试的目的也不再明显。我现在很难弄清楚自己的代码做了什么。

在同一地方，几乎每个类都只有一个方法（它只有“责任”）。遵循程序中的流程几乎是不可能的，并且大多数单元测试包括测试该类从另一个类中调用代码，这两个目的对我来说都是一个谜。从字面上讲，有数百个班级应该只有几十个班级。每个类仅执行一个“操作”，但是即使使用“ AdminUserCreationAttemptorFactory”之类的命名约定，也很难分辨出类之间的关系。

在另一个地方（也具有类应该只有一种方法的心态），我们正在尝试优化一种方法，该方法在特定操作中会占用95％的时间。经过（有点愚蠢的）优化之后，我将注意力转向了为什么它被称为“ bajillion次”。它在一个类的循环中被调用...其方法在另一个类的循环中被调用..该方法也在一个循环中被调用..

总而言之，有五个级别的循环（严重地分布在13个类中）。仅仅通过查看它就无法确定任何一个类实际上正在执行的操作-您必须绘制一个心理图，说明它调用了什么方法以及那些方法调用了什么方法，依此类推。如果将所有方法都归纳为一种方法，那么问题方法将嵌套在五个显而易见的循环级别中，那么大约只有70行。

我要求将这13个类重构为一个类的请求被拒绝。

既然您提到了“干净代码”，尽管它包含一些好主意，但我认为它对将所有方法重构为子方法以及将那些方法重构为子子方法等的痴迷程度实在太过分了。您应该使用二十行（据说是好命名的）一线而不是十行方法。显然有人认为它很干净，但对我来说，它似乎比原始版本差很多。

另外，替换简单的基本事物，例如

0 == memberArray.length

在类中调用该类自己的方法，例如

isEmpty()

是一个可疑的“改进”恕我直言。另外：区别在于第一次检查完全按照它的意思进行：检查数组长度是否为0。好的，isEmpty()也可以检查数组长度。但是也可以这样实现：

return null != memberArray ? 0 == memberArray.length : true;

也就是说，它包含一个隐式的空检查！对于公共方法来说，这可能是好的行为-如果数组为null，则某些东西肯定为空-但是当我们谈论类内部时，这不是很好。虽然必须封装到外部，但类内部必须准确知道类中发生的事情。您不能从自身封装类。显式胜于隐式。

这并不是说打破冗长的方法或进行逻辑比较是不好的。当然可以，但是在什么程度上做（甜蜜点在哪里）显然是口味的问题。分解一个长方法会导致更多方法，而这并非免费。如果您一眼就能看到所有内容都在一个方法中，那么您就必须四处浏览源代码才能查看实际情况。

我什至可以说，在某些情况下，单行方法太短了，不值得成为一种方法。

“对评论持开放态度”

评论绝对是一件好事，但太多的评论同样是不好的，甚至还不够不够。为什么？好吧，如果看到太多不必要的注释，人们倾向于将注释排除掉。我并不是说您可以拥有完全自我记录的代码，但是最好使用需要注释的代码来进行解释。

GoTo被认为有害

如果要实现状态机，则GOTO语句比“结构化编程”方法更有意义（可读性和高效的代码）。当我在一份新工作中编写的第一段代码不仅包含一个goto语句，而且包含多个goto语句时，这确实使某些同事感到担忧。幸运的是，他们足够聪明，可以意识到这实际上是此特定情况下的最佳解决方案。

任何不允许对其规则进行明智且有文件证明的例外的“最佳实践”都是令人恐惧的。

我们为使代码可测试而做出的牺牲

我花了很多时间来使我的代码可测试，但是我不假装如果选择的话就不会。但是，我经常听到人们推崇这些是“最佳实践”的想法。这些做法包括（以.Net语言编写，但也适用于其他语言）：

• 为每个类创建一个接口。 这使要处理的类（文件）数量加倍，并重复了代码。是的，接口编程很好，但这就是公共/私有说明符的目的。
• 在启动时未实例化的每个类都需要一个工厂。 显然，new MyClass()这比编写工厂要简单得多，但是现在不能单独测试创建工厂的方法。如果不是因为这个事实，我只会使我现在做的工厂班级数量的1/20减少。
• 公开每个班级，这完全没有在班级上使用访问说明符的目的。但是，非公共类不能从其他项目访问（并因此进行测试），因此唯一的选择是将所有测试代码移至同一项目（并随最终产品一起发布）。
• 依赖注入。显然不得不放弃每一个我用一个字段和构造函数参数的其他类的不仅仅是创建它们，当我需要他们显著更多的工作; 但是我不能再单独测试该类了。
• 单一责任原则让我头疼不已，现在我将其转移到自己的答案上。

那么我们该怎么做才能解决此问题？我们需要对语言架构进行彻底的改变：

• 我们需要模拟类的能力
• 我们需要能够从另一个项目测试内部类的私有方法的功能（这似乎是一个安全漏洞，但是如果被测者被迫命名其测试器类，我认为不会有问题）。
• 依赖注入（或服务位置）以及与我们现有工厂模式等效的东西必须成为语言的核心部分。

简而言之，我们需要一种从头开始设计的语言，并且要考虑到可测试性。

将应用程序划分为多个层；数据层，业务层，UI层

我不喜欢这样做的主要原因是，大多数遵循此方法的地方都使用非常脆弱的框架来完成它。IE UI层是手工编码的，用于处理业务层对象；业务层对象是手工编码的，用于处理业务规则和数据库；数据库是SQL，已经相当脆弱，并且由不喜欢更改的“ DBA”组管理。

为什么这样不好？最常见的增强请求可能是“我需要屏幕X上具有Y的字段”。砰! 您只是具有一个影响每个单独层的新功能，并且如果您与不同的程序员将各个层分开，那么对于一个非常简单的更改，它就成为涉及多个人员和团队的大问题。

另外，我不知道我参加过多少次类似这样的争论。“名称字段的最大长度限制为30，这是UI层，业务层还是数据层问题？” 有一百个论点，没有正确的答案。答案是相同的，它影响所有层，您不想使UI变得笨拙，而不必遍历所有层，并在数据库上失败，只是为了让用户发现他的输入太长。如果更改它，它将影响所有图层等。

“层”也容易泄漏。如果任何层在物理上都被进程/机器边界（IE Web UI和业务后端逻辑）隔开，则规则将重复，以使一切正常运行。也就是说，即使是“业务规则”，某些业务逻辑也会出现在UI中，因为用户需要UI能够响应。

如果所使用的框架或所使用的体系结构能够抵抗较小的更改和泄漏（即基于元数据）并在所有层中进行动态调整，则可以减轻痛苦。但是，对于大多数框架而言，这是一个极大的痛苦，需要对UI进行更改，对业务层进行更改以及对数据库进行更改，而对于每个小的更改，都会导致比该技术所产生的工作量更大，帮助更少。

我可能会为此受到抨击，但事实是这样的：)

JavaBeans

Java中JavaBean的使用。看到我的问题为什么我不应该使用不可变的POJO而不是JavaBean？在StackOverflow上。

用户故事/用例/角色

当您为一个您不熟悉的行业编程时，我了解这些需求，但是我认为，如果完全实施它们，它们将变得过于公司化，浪费时间。

80个字符/行的限制是愚蠢的

我知道需要做出一些折衷来适应GUI端最慢的运行程序的速度（屏幕分辨率限制等），但是，为什么该规则适用于代码格式？

参见...有一个叫做水平滚动条的小发明，创建该滚动条是为了管理最右边像素边界之外的虚拟屏幕空间。为什么设法创建了出色的生产力增强工具（例如语法突出显示和自动完成）的开发人员为什么不使用它？

当然，* nix恐龙虔诚地使用了CLI编辑器，这些编辑器遵循其VT220终端的陈旧旧限制，但是为什么我们其他人都遵循相同的标准？

我说，拧紧80个字符的限制。如果恐龙足够强大，可以整天破解emacs / vim，为什么它不能创建自动包装行的扩展或为其CLI IDE提供水平滚动功能的扩展？

1920x1080像素监视器最终将成为标准，全世界的开发人员仍然生活在相同的限制下，除了他们为什么这样做外，与他们的工作无关，长者刚开始编程时就告诉他们这样做。

80个字符数的限制不是最佳实践，但是对于极少数程序员来说，这是一个小众实践，应该这样对待。

编辑：

可以理解，许多开发人员不喜欢水平滚动条，因为它需要鼠标手势，所以...为什么不为使用现代显示的我们这些人增加列宽限制（大于80）。

当800x600的计算机显示器成为大多数用户的标准时，Web开发人员增加了他们的网站宽度以容纳大多数用户...为什么开发人员不能这样做。

测量，测量，测量

很好，可以进行衡量，但是为了隔离性能错误，可以进行衡量以及逐步消除。这是我使用的方法。

我一直在努力寻找“智慧”的来源。有人拿着一个足够高的肥皂盒说了这句话，现在它可以旅行了。

我的老师要求我以小写字母（例如）开头所有标识符（不包括常量）myVariable。

我知道这似乎是一件小事，但是许多编程语言都要求变量以大写字母开头。我重视一致性，因此我的习惯是，所有内容都以大写字母开头。

使用单例

当您仅应具有某个实例时。我不同意更多。切勿使用单例，只分配一次，并根据需要传递指针/对象/引用。绝对没有理由不这样做。

使用unsigned int作为迭代器

他们什么时候会知道使用signed int更安全，更不易出错。为什么数组索引只能是正数，为什么每个人都高兴地忽略4-5是4294967295的事实，这是如此重要？

方法不应超过单个屏幕

我完全同意单一责任原则，但是为什么人们会认为它是指“一个功能/方法在最佳逻辑粒度上最多只能承担一个责任”？

这个想法很简单。一种功能/方法应完成一项任务。如果该功能/方法的一部分可以在其他地方使用，请将其切成自己的功能/方法。如果可以在项目的其他地方使用它，请将其移到其自己的类或实用程序类中，并使其在内部可访问。

如果一个类包含27个在代码中仅被调用一次的辅助方法，那将是愚蠢的，浪费的空间，不必要的复杂性增加以及大量的时间消耗。对于想看重重构代码但又不会产生太多结果的人来说，这听起来似乎是个好规则。

这是我的规则

编写函数/方法来完成某件事

如果您发现自己要复制/粘贴一些代码，请问自己是否为该代码创建函数/方法会更好。如果一个函数/方法在另一个函数/方法中仅被调用一次，那么将它放在首位真的有一点意义（将来会被更频繁地调用）。在调试期间添加更多的函数/方法跳转是否有价值（即，添加的跳转是否使调试更容易或更难）？

我完全同意，需要检查大于200行的函数/方法，但是某些函数只能在多行中完成一项任务，并且不包含可以在项目的其余部分中抽象/使用的有用部分。

我是从API开发人员的角度看的……如果一个新用户要查看您的代码的类图，那么在整个项目的整个范围内，该图的多少部分才有意义，而在整个项目中将单独存在多少？项目内部其他部分的助手。

如果要在两个程序员之间进行选择：第一个倾向于编写尝试做太多事情的函数/方法；第二个将每个函数/方法的每个部分分解到最细粒度的层次；我会选择第一手放下手。第一个将完成更多的工作（即编写更多的应用程序内容），其代码将更易于调试（由于调试期间函数/方法的跳入/跳出次数减少），并且他将花费更少的时间进行忙碌的工作以完善方法代码看起来比完善代码的工作方式还要好。

限制不必要的抽象，不要污染自动完成功能。