在这篇文章中，我想详细介绍良好软件设计的广泛概念，而不是特定于语言的细节。代码什么时候好，什么时候坏？这是一个主观且有争议的话题。有许多特定于语言或框架的规则和指南，但我坚信好的代码或好的设计不仅或总是与它们有关。通常，它们会使代码变得复杂、分散和过度结构化。因此，我相信好的设计取决于它的用例。幸运的是，我认为仍然有一些方法可以确定软件对其用例来说是“好”还是“坏”。好的设计很简单。我经常遇到结构完美、接口到位、接口到位、特定代码模式和代码样式工具不返回任何错误或警告的代码。不过，我还是觉得不好。每次你写东西，它应该是成比例的。许多开发人员只是为了模式而采用模式。他们大喊大叫，“看看我在采用我刚刚读到的这种模式方面有多强大”，却没有真正理解他们为什么选择特定模式。好的设计通常很简单。我的意思是与他们提供的解决方案的大小成正比。如果您为您的应用程序提供仅使用一次的简单功能，您是否应该使用各种花里胡哨的功能？考虑您的代码复杂性是否与您提供的解决方案成正比。您的功能是应用程序的支柱，还是应用程序扩展或继承的基础？你最好把它结构化。这只是解决您应用程序中的一个小问题的方法吗？最好让它尽可能简单。在与应用程序的项目负责人交谈时，我们倾向于使我们的功能过于复杂，我们检索需求。在第一次提出实施想法后，我们经常将方法的初始设计过于复杂化。与一些开发人员坐下来深入了解实际需要的东西通常是有益的。有几种方法可以确保更简单的解决方案。正确的问题作为开发人员，我们经常被要求做某事，而我们只是去做。这种按需行为对于初级开发人员来说可能是正常的，但是随着您的前进，请尝试提出明智的问题并确保在估计或设计解决方案之前回答这些问题。当你一遍又一遍地问某些问题时，你也在训练你的产品所有者或管理人员在请求功能之前考虑这些问题。诸如此类的问题：此功能的最终目标是什么？谁会使用它？有没有更简单的方法来实现相同的目标？它会使应用程序变得更大、更复杂吗？这值得么？将解决方案拆分为多个部分我总是做的第一件事是远离我需要在其中实现功能的应用程序。然后考虑您可以制作和交付的最小代码片段，使您更接近为此功能设置的目标.对他们所有人都这样做，重新评估是否所有步骤都是必要的，并分别估计他们的开发时间。此外，尝试尽可能独立地开发这些元素。交换功能、更改或删除功能越容易，编写代码就越容易。如果某些必要的小功能真的很重要，请挑战产品负责人当您将方法分成小部分时，通常更容易与非技术人员讨论。这允许与团队和产品所有者进行讨论，并重新评估是否需要所有部件。由于您已经对它们进行了估算，因此如果这些功能值得，您可以做出更好的基于价值的决策。不要忘记估计它增加了多少复杂性以及它如何影响维护应用程序的成本。好的代码易于更改如果代码易于更改，则维护成本低，易于理解、扩展、删除甚至更改！正如本书《实用程序员》中所写：“如果一个东西适应了使用它的人，它就是被设计出来的。”本质上，所有设计原则都是一种使代码更易于更改的方法。解耦，单一职责原则，干。这些是使您的代码更好、更易于更改的原则。为什么我讨厌代码中的注释当您需要注释代码时，它基本上很糟糕。当你需要解释为什么做某事时，代码是不言自明的，所以无论如何都应该重构。代码注释清楚地指出了错误代码，您可以采取许多简单的步骤来提高代码的可读性。注释不能弥补凌乱的代码。当代码令人困惑或做出危险的假设时，我们倾向于编写额外的注释。唯一有意义的注释是：LawReviewPurposeExplanationImprovesReadabilityWarningConsequencesToDo如何编写更好的代码有许多简单的原则可以帮助您编写更简单的代码，您的同事会喜欢并喜欢一起工作。对于其中的每一个，都可以编写一篇完全独立的文章，因此这里有一个简单的清单，可以帮助您开始编写更好的代码。班级应该很小。多么小？越小越好。一个类应该只有一个职责，并且它的名称应该从该职责派生。如果您想不出一个合乎逻辑的描述性类名，它可能太大了。方法/函数就像类，它们应该很小，只做一件事，并且有解释性的和简单的名字。注意标志。大量缩进通常是方法混乱的标志。对于Foreach和switch语句，请确保将实际执行代码编写在单独的函数中，这使其更像是该方法针对不同实现实际执行的操作的索引。有意义的名字类、函数和变量都应该有有意义的名字。例如，永远不要使用$a=b;。让您的代码成为功能和意图的文档。格式和代码风格确保你的整个应用程序和你的整个团队使用完全相同的代码风格，并且对此非常严格。每个IDE和语言都有用于此目的的工具。一致的空格或换行符会产生很大的不同。如果它不一致，它会让你发疯。对此非常严格会立即提高应用程序的清洁度，尤其是在对此不是很严格的语言中。
