优秀软件设计的基本元素是什么？不要陷入初级开发人员的陷阱

不要陷入初级开发人员的陷阱或使事情变得过于复杂
文章插图
【优秀软件设计的基本元素是什么？】> Photo by Markus Spiske on Unsplash.
在本文中，我想详细介绍优质软件设计的广泛概念，而不是因语言而异的细节。
什么时候代码好而什么时候坏？这是一个主观且有争议的话题。有许多特定于语言或框架的规则和准则，但是我坚信，好的代码或好的设计不仅或总是与它们相关。通常，它们会使代码变得复杂，分散且结构过度。因此，我相信好的设计取决于它的用例。
幸运的是，我认为仍然有一些方法可以确定该软件在其使用案例中是"好"还是"坏" 。
好的设计很简单通常，我遇到的代码具有完美的结构，并具有适当的接口，并采用了适当的接口，并且采用了特定的代码模式和代码样式工具，这些工具不会返回单个错误或警告。但是，我仍然认为这很糟糕。
每次写东西时，都应该成比例。许多开发人员只是为了模式而采用模式。他们几乎在大喊："看看我在采用我刚刚读过的这种模式方面有多强" ，而不是真正理解他们为什么选择特定模式。
好的设计通常很简单。我的意思是与他们提供的解决方案的大小成正比。如果您为应用程序提供仅使用一次的简单功能，那么您是否应该使用各种花哨的东西？考虑一下您的代码复杂度是否与您提供的解决方案成比例。您的功能将成为应用程序的骨干，还是应用程序中扩展或继承的基础？您最好使其结构合理。这仅仅是解决您的应用程序中的一个小问题的方法吗？最好尽可能地简单。
我们倾向于过于复杂化我们的功能与我们的应用程序的项目负责人交谈时，我们会检索需求。在首先提出实现想法之后，我们常常使方法的初始设计过于复杂。与几个开发人员坐下来并深入研究实际需要的东西通常是有益的。您可以通过几种方法来确保提供更简单的解决方案。
正确的问题作为开发人员，我们经常被要求做某事，而我们只是这样做。这种按需行为对于初级开发人员而言可能是正常的，但是随着您的前进，请尝试提出明智的问题，并确保在估计或设计解决方案之前已回答了这些问题。当您一遍又一遍地问某些问题时，您还培训您的产品负责人或管理人员在请求功能之前考虑这些问题。像这样的问题：
· 此功能的最终目标是什么？
· 谁将使用它？
· 有没有更简单的方法可以实现相同的目标？
· 它将使应用程序更大，更复杂吗？值得吗？
将解决方案分为多个部分我始终要做的第一件事是远离需要在其中实现功能的应用程序。然后考虑一下您可以制作和交付的最小代码段，这使您更加接近为此功能设置的目标。对所有这些都执行此操作，重新评估所有步骤是否必要，并分别估计其开发时间。另外，请尝试以尽可能独立的方式开发这些元素。交换功能，更改或删除功能越容易，编写代码就越容易。
如果某些必要的小功能真的很重要，请挑战产品负责人当您将方法划分为小部分时，与非技术人员进行讨论通常会更容易。这样就可以与团队和产品负责人进行讨论，并重新评估是否需要所有部分。由于您已经估算了它们，因此如果功能值得，则可以做出更好的基于价值的决策。
不要忘记估计它增加的复杂程度以及它如何影响维护应用程序的成本。
好的代码很容易更改如果代码易于更改，则维护成本较低，易于理解，扩展，删除，甚至可以更改！就像《实用程序员》一书中所写："如果事物能够适应使用它的人，那么它就是经过精心设计的。 " 本质上，所有设计原则都是使代码更易于更改的一种方式。解耦，单责任原则，干。这些都是使您的代码更好，更容易更改的原则。
为什么我讨厌代码中的注释当您需要注释代码时，它基本上很烂。当您需要解释为什么要执行某项操作时，该代码并不是不言自明的，因此无论如何都应该对其进行重构。代码注释清楚地表明了错误代码，并且可以采取许多简单的步骤使代码更具可读性。
注释不能弥补混乱的代码。当代码令人困惑或做出危险的假设时，我们倾向于写一些额外的注释。
唯一有意义的注释是：
· 法律评论
· 目的说明
· 提高可读性
· 警告后果
· 待办事项
如何编写更好的代码有许多简单的原则可以帮助您编写更轻松的代码，而您的同事会喜欢并喜欢与他们一起工作。对于其中的每一个，都可以编写一个完全独立的文章，因此，这里有一个简单的清单，可以开始您迈向更好的代码。