应该始终使用编码最佳实践吗？

在对软件进行编码时，对于正在构建的应用程序，体系结构应该始终是最佳实践还是实践？

如果我要构建一个两页的Web应用程序，该应用程序可能会使用5年，并且在那5年中有2项改进，那么我应该编写依赖注入，设计模式，带有视图模型的model-view-controller等代码吗？

应始终使用编码最佳实践

总是？不，那很傻。

最佳做法是准则。对于大多数人来说，在大多数情况下，如果实施得当，它们将产生最佳效果。当您考虑解决方案时，它们就是您的起点。但是在某些地方，可以并且应该忽略最佳实践，因为有更好的解决方案。

问题是人类看不到未来。初学者（以及许多非初学者）不可避免地认为他们处在特殊情况下，规则不适用于他们。如有疑问，请使用最佳做法。经过数不胜数的工程师的多年辩论和经验，比您或我还聪明的发现，他们产生了始终如一的良好结果。但是他们中的任何一个（或几乎没有）都知道您的特定问题以及您的情况。有时您会遇到例外情况，这些情况可能会折磨规则。

是。这是不言而喻的。你为什么不做最好的事？

那不是问题。困难的部分是找出什么是最佳实践，因为要回答这个问题，您需要确切地知道您有什么需求以及多年来这些项目可能如何发展，这是非常困难的。

但是，有一个很好的经验法则：永远不要采用一堆设计模式的名称，然后不加考虑就将它们组合在一起，这并不是最佳实践。

除此之外，您的问题确实无法回答。弄清楚对于给定情况什么是“最佳实践”是一名软件工程师所要做的一切。您将不得不缩小范围以获得更好的答案。

最佳实践是最有效地满足软件对功能，可维护性，性能等方面的功能性和非功能性需求的一种方法。如果这种方法恰好符合某些“行业标准”，那就太好了。但是，如果不这样做，实用主义就可以胜出。

我目前在哪里工作，我们正在从头开始为产品构建新的Web UI。它绝不会是RESTful的。它专门使用POST。它不是多层的，不使用任何微服务，也不使用NoSQL数据库。它没有像Enterprise Java这样的架构。

换句话说，它根本不是时髦的。

但是它确实集成了先进的HTML5 框架，该框架具有类似于Angular的数据绑定，自动缩放到移动设备和台式机等不同设备类型，与Telerik的Kendo UI集成以完成所有繁重任务以及完全加密和安全的功能数据通道。

最棒的是，这将在30天之内完成，这一壮举将需要一年的Java开发人员在企业体系结构中实现。代码是ES6 / Typescript；这是我见过的最干净的代码。

没有。最佳实践通常被认为是99％的时间是最好的事情，但这并不意味着它们总是适用于每种情况。

作为开发人员，您的工作是了解和使用这些最佳实践，同时还要知道何时可以安全地将其抛弃。

这不应该是自我宣传，但是我最近在Salesforce.com平台上写了一篇与我的工作有关的博客文章，其中详细介绍了其中一种情况。黄金法则之一是“永远不要在循环内进行查询”，但是最近，在该平台上工作7年以来，我有一个完全正当的理由不遵守该法则。

要点是该平台对您可以在给定的执行上下文中执行的查询数量有所限制，但是在这种情况下，我必须在循环内进行查询以避免堆空间用完，并且知道我会很好地进入查询范围限制。

因此，这种情况很少见，但是有时候最佳实践与场景无关，因此，如果不合适，就不要强求它们。

我认为“最佳实践”是指某人在书中编写的一些规则列表。当然，如果您直截了当地说这个短语，那么您当然应该始终写出最好的代码。

我是否需要指出，没有一个单一的，被普遍接受的“最佳实践”？对于由一位专家提出的任何规则，您几乎总是可以找到另一位具有同等资历的专家，他们的说法有所不同。

但要点：简短答案：通常但并非总是如此。

每个领域都有其“最佳实践”和“教科书解决方案”。这些代表了许多很多年以来许多人积累的经验和智慧，因此不应忽视。但！总是有特殊情况，边缘情况等。在任何领域中，真正有能力的人都知道何时遵守规则以及何时违反规则。

我通常会说：首先要遵循教科书规则。如果遵循教科书的规则会带来麻烦-不必要的复杂性，不良的性能，等等-那么请考虑是否一次违反这一规则可能不是一个更好的主意。

如果您不遵守规则，而随心所欲，那么您的代码很可能是一团糟。无论您多么聪明，您都不是世界上第一个程序员。向他人的经验学习是有意义的。在我们的日常生活中，这就是为什么我们有父母，老师和传教士的原因：因此，我们不必自己重复每个愚蠢的错误就可以知道这是一个愚蠢的错误。

但是，如果您100％地刻苦地遵循某本书中的规则列表，则经常会发现自己将方钉钉在圆孔中。编写规则手册的人可能没有遇到过像您这样的案件。即使有，即使很少见，他们也可能忽略了它。一条规则在80％的时间内有效，这是一个很好的规则-只要您了解它在80％的时间内有效，而不是在100％的时间内有效。

我写了一本有关数据库设计的书，其中包括许多建议数据库设计人员遵循的规则。（我不会给出标题，所以我看起来不会无耻地自我推销。）我当然鼓励任何想要设计数据库的人阅读像我这样的书并从中学习的一切。但是当然，有些时候您应该违反我列出的规则。

我曾经为当时领导的一组开发人员编写了编程标准文档。最后一条规则是这样的：“如果您有充分的理由违反上述规则之一，那么继续吧，但是您必须在代码中包含注释，以说明您违反规则的原因。要有充分的理由，然后遵循规则。如果写评论比遵循规则更麻烦，则遵循规则。” 我们只有极少数人发现违反规则值得解释原因。

通过最佳实践，我假设您的意思是“软件开发社区逐渐了解的非正式规则，可以帮助提高软件质量”，而不是执行特定任务的某种字面上的最佳方法。

是的，除非您有理由不这样做。您应该认真考虑并适用于当前任务的情况和局限性，这应该是一个很好的理由。这意味着您完全理解该实践并能够应用它。让我们不要陷入这种观念，即如果您不了解它，那么它一定不是最好的想法。请参阅定义。

您并不总是会做最好的事情。当老板告诉你，“把这烂话扔掉，否则你就被解雇了！” 您将运送它，并可能去寻找另一份工作，但是您仍然会运送它。有时您会发现自己做的事情足够好。当然，您不想养成这种习惯，但是有时您必须使货车滚动，您不必担心马匹失明。

有些事情很重要，有些则不重要。

您应该针对眼前的问题调整语言和风格的选择。

例如，异常处理的“最佳实践”可能总是捕获异常并记录它们，但是在创建单元测试时，最佳实践通常是抛弃它们，以便单元测试框架可以正确报告它们。

另一方面，请考虑“干燥”规则。争取不会重复的代码始终是件好事，这不仅是因为显而易见的原因，而且还因为这样编写的代码越多，您成为的编码员就越好-这是一种增强编码/思维能力的好方法而不是您的打字和复制/粘贴技能，从长远来看，如果您遵循一些明智的规则，通常您会更喜欢重新访问您的代码（即使您期望它是一次性代码）。

总而言之，要灵活一些，但不要仅仅编写不可读的垃圾代码，因为您认为它是一次性的代码。

我将尝试从不同的角度来看待。

当今的现代框架使通过mvc，依赖项注入，分层体系结构等（在这里是Spring Boot爱好者）建立基本项目变得非常容易。我要说的是从生成的基础开始，并使用为您提供的工具，直到遇到一些需要手工解决方案的问题为止。然后，您可以从这些最佳实践中偷偷摸摸。

使用类似Spring Boot的2页Web应用程序，然后滚动自己的servlet，jdbc查询和其他东西，并不难。

根据我的经验，我认为只有一种最佳实践是强制性的：

保持简单，愚蠢（KISS）

换句话说：无论您选择哪种工具，API，体系结构等，如果保持简单，将来的工作就更容易，bug更少，速度更快，内存效率更高，以及您可能想要的其他一切。

人们谈论的所有其他内容：原则，模式，实践等-我认为我是可以选择的工具库，选择最适合我正在从事的项目的工具。它们都提供解决问题的技术和思想。诀窍是首先弄清楚您是否有这些问题。

最佳“最佳实践”始终包含一个部分，您应该利用自己的才智和经验来确定手册中的项目何时不合适。它们还可能包含有关审核，批准和记录此类例外并使它们成为“最佳”实践的一部分的部分。

在对软件进行编码时，对于正在构建的应用程序，体系结构应该始终是最佳实践还是实践？

从理论上讲，是的。

在现实世界中，只要您有能力，仍然可以。

当然，这意味着“否”。

时间和金钱的压力将始终试图将您推向“快速而肮脏的”解决方案的道路，因为它为客户带来了“更好”的价值。客户或他们的会计师不关心如何实施。如果您可以在两天内[严重]或在三个月内完美完成工作，您认为他们会要求您做什么？

最佳实践和您必须“摆脱”的东西之间的差距被称为“技术债务”；只要您有“偿还”计划，即稍后回去改进它，这是完全可以接受的。再说一次，不是您总能（永远）获得预算的东西。

一种策略是发布包含“快速”修复程序的早期Beta版本，但要确保在“完整”发布之前优先考虑必要的体系结构改进。再说一次，不是您总是（曾经？）要做的事情。