软件 基本设计 详细设计_好的软件设计的基础是什么？

软件 基本设计 详细设计

In this article, I want to elaborate on the broad concepts of good software design rather than the specifics that may differ a little from language to language.

在本文中，我想详细介绍优质软件设计的广泛概念，而不是因语言而异的细节。

When is code good and when is it bad? It’s a subjective and controversial topic. There are a lot of language- or framework-specific rules and guidelines, but I have a strong belief that good code or good design is not only or always tied to them. Often, they make code complex, scattered, and over-structured. Therefore, I believe that good design is subject to its use case.

什么时候代码好而什么时候坏？ 这是一个主观和有争议的话题。 有许多特定于语言或框架的规则和准则，但是我坚信，好的代码或好的设计不仅或总是与它们相关。 通常，它们会使代码变得复杂，分散且结构过度。 因此，我相信好的设计取决于它的用例。

Luckily, I think there are still some ways to determine if the software can be considered “good” or “bad” for its use case.

幸运的是，我认为仍有一些方法可以确定该软件在其使用案例中是“好”还是“坏”。

好的设计很简单 (Good Design Is Simple)

Often, I come across code that is perfectly structured with all the bells and whistles, set up with proper interfaces, and it adopts specific code patterns and code style tools that do not return a single error or warning. But still, I think it sucks.

通常，我遇到的代码具有完美的结构，并具有适当的接口，并采用适当的接口设置，并且采用特定的代码模式和代码样式工具，这些工具不会返回单个错误或警告。 但是，我仍然认为这很糟糕。

Every time something is written, it should be proportional. A lot of developers adopt patterns just for the sake of patterns. They’re almost yelling, “Look how good I am at adopting this pattern I just read about” instead of really understanding why they chose a specific pattern.

每次写东西时，都应该成比例。 许多开发人员只是为了模式而采用模式。 他们几乎在大喊：“看看我在采用我刚刚读过的这种模式方面有多强”，而不是真正理解他们为什么选择特定模式。

Good design is often simple. By that, I mean proportional to the size of the solution they provide. If you provide a simple feature to the application that is only used once, should you be using all kinds of fancy stuff? Think about if your code complexity is proportional to the solution you are providing. Is your feature going to be the backbone of your application or the base of an extension or inheritance in your application? You better have it well structured. Is it just a solution to a small problem in your application? It better be as simple as it can be.

好的设计通常很简单。 我的意思是与他们提供的解决方案的大小成正比。 如果您为应用程序提供仅使用一次的简单功能，那么您是否应该使用各种花哨的东西？ 考虑一下您的代码复杂度是否与您提供的解决方案成比例。 您的功能将成为应用程序的骨干，还是应用程序中扩展或继承的基础？ 您最好使其结构合理。 这仅仅是解决您的应用程序中的一个小问题的方法吗？ 最好尽可能地简单。

我们倾向于过于复杂化我们的功能 (We Tend to Overcomplicate Our Features)

When talking to the Project Owner of our application, we retrieve requirements. After first drawing out our ideas for the implementation, we often overcomplicate the initial design of our approach. It’s often beneficial to sit down with a few developers and really drill down what is actually needed. There are a few ways you can make sure you provide the easier solution possible.

与我们的应用程序的项目负责人交谈时，我们会检索需求。 在首先提出实现想法之后，我们常常使方法的初始设计过于复杂。 与几个开发人员坐下来并深入研究实际需要的内容通常是有益的。 您可以通过几种方法来确保提供更简单的解决方案。

正确的问题 (Aks the right questions)

As developers, we are often asked to do something, and we just do it. This on-demand behavior is probably normal for junior developers, but as you progress, try to ask intelligent questions and be sure those questions are answered before estimating or designing the solution. When you ask certain questions over and over again, you also train your Product Owner or management to think about these questions before requesting a feature. Questions like:

作为开发人员，我们经常被要求做某事，而我们只是这样做。 这种按需行为对于初级开发人员来说可能是正常的，但是随着您的前进，请尝试提出明智的问题，并确保在估计或设计解决方案之前已回答了这些问题。 当您一遍又一遍地提出某些问题时，您还将培训产品负责人或管理人员在请求功能之前考虑这些问题。 像这样的问题：

• What is the end-goal of this feature?
  此功能的最终目标是什么？
• Who is going to use it?
  谁将使用它？
• Is there a simpler way of achieving the same goals?
  有没有更简单的方法可以实现相同的目标？
• Will it make the application bigger and more complex? Is that worth it?
  它将使应用程序更大，更复杂吗？ 值得吗？

将解决方案分为多个部分 (Divide the solution into multiple parts)

The first thing I always do is step away from the application the feature needs to be implemented in. Then think of the smallest piece of code you can make and deliver that brings you a bit closer to the goals set for this feature. Do this for all of them, reassess if all of the steps are necessary, and estimate their development time separately. Also, try to develop those elements in as standalone a fashion as possible. The easier it is to swap out functionality, change it, or delete it, the easier it is to code.

我始终要做的第一件事是远离需要在其中实现功能的应用程序。然后考虑一下您可以制作和交付的最小代码段，这使您更加接近为此功能设置的目标。 对所有这些都执行此操作，重新评估所有步骤是否必要，并分别估计其开发时间。 另外，尝试以独立的方式开发这些元素。 交换功能，更改或删除功能越容易，编写代码就越容易。

如果确实需要某些小功能，请挑战您的产品负责人 (Challange your Product Owner if certain small features are really essential)

As you divide your approach into small parts, it is often easier to discuss it with non-tech people. This opens up the possibility to discuss it with the team and Product Owner and reassess if all parts are needed. Since you estimated them already, a better value-based decision can be made on if the feature is worth it.

当您将方法划分为小部分时，与非技术人员进行讨论通常会更容易。 这样就可以与团队和产品负责人进行讨论，并重新评估是否需要所有部分。 由于您已经估算了它们，因此如果功能值得，可以做出更好的基于价值的决策。

Don’t forget to estimate the level of complexity it adds and how it affects the cost of maintaining the application.

不要忘了估计它增加的复杂性级别以及它如何影响维护应用程序的成本。

好的代码很容易更改 (Good Code Is Easy to Change)

When code is easy to change, it’s cheaper to maintain, easier to understand, expand, delete, and again, change! As written in the book The Pragmatic Programmer: “A thing is well designed if it adapts to the people who use it.” In essence, all design principles are a way of making code easier to change. Decoupling, single responsibility principle, DRY. These are all principles that make your code better and easier to change.

当代码易于更改时，它的维护成本更低，更易于理解，扩展，删除，以及更改！ 就像《实用程序员 》一书中所写：“如果事物能够适应使用它的人，那么它就是经过精心设计的。” 本质上，所有设计原则都是使代码更易于更改的一种方式。 解耦，单责任原则，干。 这些都是使您的代码更好，更容易更改的原则。

为什么我讨厌代码中的注释 (Why I Hate Comments in Code)

When you need to comment your code, it basically sucks. When you need to explain why you are doing something, the code is not self-explanatory and should probably be refactored anyway. Code comments are a clear sign of bad code, and there are a lot of simple steps you can take to make your code more readable.

当您需要注释代码时，它基本上很烂。 当您需要解释为什么要执行某项操作时，该代码并不是不言自明的，因此无论如何都应该对其进行重构。 代码注释清楚地表明了错误代码，并且可以采取许多简单的步骤使代码更具可读性。

Comments do not make up for messy code. We tend to write extra comments when code is confusing or makes dangerous assumptions.

注释不能弥补混乱的代码。 当代码令人困惑或做出危险的假设时，我们倾向于写一些额外的注释。

The only comments that make sense are:

唯一有意义的注释是：

• Legal comments
  法律评论
• Explanation of intent
  目的说明
• To improve readability
  提高可读性
• Warning of consequences
  警告后果
• To-do comments
  待办事项

如何编写更好的代码 (How to Write Better Code)

There are a lot of simple principles that can help you write easier code that your colleagues will like and love to work with. For each of these, a completely separate article can be written, so here is a simple list to start your journey toward better code.

有许多简单的原则可以帮助您编写更轻松的代码，而您的同事会喜欢并喜欢与他们一起工作。 对于其中的每一个，都可以编写一个完全独立的文章，因此，这里有一个简单的清单，可以帮助您开始着手编写更好的代码。

班级 (Classes)

Classes should be small. How small? As small as they can be. A class should only have one responsibility and its name should be derived from that. If you cannot think of a logical and descriptive class name, it is probably too big.

班级应该很小。 多么小？ 尽可能小。 一个班级应该只承担一个责任，并且其名称应从该责任派生。 如果您无法想到一个具有逻辑性和描述性的类名，则它可能太大。

方法/功能 (Methods/functions)

Like classes, they should be small, do just one thing, and have an explanatory and simple name. Be careful with idents. A lot of indentations is often a sign of a messy method. With Foreach and switch statements, be sure to write the actual executed code in a separate function that makes it more like an index of what the method actually does for the different implementations.

像类一样，它们应该很小，只做一件事，并具有解释性和简单的名称。 注意标识。 许多缩进通常是一种凌乱方法的迹象。 对于Foreach和switch语句，请确保将实际执行的代码编写在单独的函数中，这使其更像是该方法对不同实现实际执行操作的索引。

有意义的名字 (Meaningful names)

Classes, functions, and variables should all have meaningful names. Never use $a = b;, for example. Let your code be the documentation of your functionality and intent.

类，函数和变量都应具有有意义的名称。 永远不要使用$a = b; ， 例如。 让您的代码成为功能和意图的文档。

格式和代码样式 (Formatting and code style)

Be sure your entire application and your complete team use the exact same code style — and be very strict about it. Every IDE and language has tools for this. A consistent space or newline can make all the difference. When it's not consistent, it can drive you insane. Being really strict in this area will instantly improve the cleanliness of your application, especially in languages that are not very strict in this regard.

确保您的整个应用程序和整个团队使用完全相同的代码样式，并且对此非常严格。 每种IDE和语言都有用于此目的的工具。 一致的空格或换行符可以起到很大作用。 如果不一致，则会使您发疯。 在这方面非常严格将立即提高您应用程序的清洁度，尤其是在这方面不太严格的语言中。

翻译自: https://medium.com/better-programming/what-are-the-fundamentals-of-good-software-design-5eda80f5f32b

软件 基本设计 详细设计