Rub*_*uby 4 design-patterns dependency-injection coding-style
我是编程新手，准确地说是 11 个月。我真的很想成为一名专业程序员并编写高质量的代码，所以我正在学习干净的代码、SOLID 原则和 OOP 设计。我注意到，设计遵循干净代码和可靠代码的代码比不遵循这些代码要花时间。
这是我的第一个付费项目，我真的很想编写高质量的代码。我意识到，我花了几天时间才编写了应用程序中遵循干净代码和 SOLID 的一些组件，而如果不遵循干净代码，则只需不到一天的时间。
我认为如果我继续应用干净的代码，我将无法达到截止日期，但我必须这样做，因为我知道业务会增长并且需求会发生变化。我正在开发一个海滩度假村计费和预订系统，我知道将来它需要处理在线预订。
我可以说学习 ORM、WCF 等新技术很容易，但干净的代码、SOLID 和设计模式是不同的。
我是一名初学者程序员，您对我有什么建议，学习这种模式需要多长时间，应用干净的代码和 SOLID 是否比不应用这些代码需要更多的时间来开发应用程序？
对于事物的不同观点，不要专注于预先编写干净的代码。
首先编写解决问题的代码，然后返回并清理它。唯一需要注意的是，不要走太久而不回去清理。通过清理它，我的意思是返回并仅针对定义系统意图的抽象实施 SOLID 原则。
我读过的大多数代码，无论是否来自专业人士，你几乎都可以看出他们何时试图在第一遍中编写完美的代码，因为他们总是失败，而且他们永远不会回去清理它。实际的干净代码是迭代代码块草稿的结果，只有原始作者才能理解，直到熟悉所用模式的任何人都可以轻松理解它。
尝试预先编写完美的代码是不成熟的优化。
首先，您最终会得到大量实际上并不需要的抽象，只是为了满足有关可维护代码的一些教条。很多时候，您会在解决方案的结构上花费大量时间，以至于您试图解决的实际问题在翻译中丢失了。实际上，抽象的数量越少，就越容易弄清楚一段代码的核心职责。最好首先仅在最高级别构建抽象，然后仅在绝对必要时构建更多抽象。
其次，你经常根据当前需求的参数设计错误的抽象，而不是如果你确切地知道需求将来会如何变化的话。
我在职业候选人搜索项目中有一个很好的例子。最初我们的需求是加载结果集的搜索结果和糖果数据（统计图表等）。我们使用 SQL 来实现这一切，并将加载糖果和将搜索结果获取到不同服务的过程分开。几年后，我们决定尝试使用弹性搜索来实现这一切。事实证明，我们将糖果生成与搜索结果分开的想法没有必要使用弹性搜索，因为它可以同时完成这两件事。
我们身上发生的事情是，我们过于热衷于让班级负责一件事。事实上，我们有不同的服务来生成搜索 SQL 并将搜索参数保存到数据库。当我们使用elasticsearch实现这一点时，参数保存服务派上了用场，但这仍然是预先完成的不必要的工作。事实上，我们为可维护性而预先投入的大部分额外时间几乎都是浪费，因为我们最终不得不重新处理核心抽象错误才能满足新的需求。
如果我们能重来一次，我们就会将所有代码编写在一个巨大的搜索服务中。在我们的起草过程中，我们会将我们实现的其他每个服务分解为该服务上的简单私有函数。两年后，当我们创建第二个搜索实现时，为了突破共享服务，我们所要做的就是将私有功能复制到新服务，并将共享功能在新服务上公开。与试图立即编写“完美”代码相比，这是一种更加务实的方法。
不要误解我，拥有干净的代码会让你的代码更加优雅和可维护；你只是不能在第一遍就写出来。仅通过阅读一本书或查看人们认为干净的源代码，您无法真正理解什么使代码干净。除此之外，为了实现构成干净代码的原则的全部意图，还需要花费大量时间来遇到像我上面描述的那样的错误。 不要害怕犯这些错误，它们会让你成为更好的程序员。 害怕错误是一种不宽容的观点，它会让你成为一个更糟糕的程序员。