重构-改善既有代码设计_实用代码重构，第1部分-什么是好的代码？

重构-改善既有代码设计

Refactoring is about re-thinking your code, everything in it, for the sake of making your code better. In this series on code refactoring, I’ll show you the Why, When, What, Where, and How of refactoring since refactoring is more of an art more than a science. In this part I’ll explain what makes code good, the basis which I build upon later through the rest of the series.

重构就是重新思考您的代码及其中的所有内容，以使您的代码更好。 在这个有关代码重构的系列文章中，我将向您展示为什么，何时，什么，在何处以及如何进行重构，因为重构更多是一门艺术，而不是一门科学。 在这一部分中，我将解释什么使代码更好，这是我在本系列其余部分中所基于的基础。

什么是好代码？ (What is Good Code?)

The main goal of refactoring is clean code, better code, or whatever you might call it. But what actually constitutes good code? Good code is smelled and tasted. If you’ve written a lot of code, you understand what I mean; you can easily identify whether code is good or bad with experience. But what if you are new to coding but still want to do things right?

重构的主要目标是干净的代码，更好的代码或任何您可能称之为的代码。 但是什么才是好的代码呢？ 闻到了好代码。 如果您编写了很多代码，您就会明白我的意思； 您可以轻松地凭经验确定代码是好是坏。 但是，如果您是编码新手，但仍然想做正确的事情怎么办？

We can summarize the aspects of good code with these three guidelines:

我们可以使用以下三个准则来总结良好代码的各个方面：

• Readable
  可读的
• Extensible
  可扩展的
• Efficient
  高效的

可读性 (Readability)

When your code follows some standard well-known syntax, style, and documentation practices, or in other words when you and your development colleagues can easily interpret the code with minimal ambiguity, your code is said to be readable and consequently maintainable in terms of style and appearance. To achieve this, you should follow a coding standard. You may use some public standard or create your own if you like, but whichever you choose, your colleagues should find your syntax, style, code documentation, and comments straight forward, clear, and require no further explanation as much as possible. I prefer using a public standard since it can shorten the learning curve for new people joining my development team later.

当您的代码遵循某些著名的标准语法，样式和文档惯例时，或者换句话说，当您和您的开发同事可以轻松地以最小的歧义来解释代码时，就可以说，您的代码在样式方面是可读性和可维护性的和外观。 为此，您应该遵循编码标准。 您可以使用一些公共标准，也可以根据需要创建自己的公共标准，但是无论您选择哪种方式，您的同事都应该直接，清晰地找到您的语法，样式，代码文档和注释，并且无需进一步解释。 我更喜欢使用公共标准，因为它可以缩短以后加入我的开发团队的新手的学习曲线。

Readability and extensibility overlap when you use basic constructs of your programming languages for what they were intended as much as possible, and for solving well-known problems you use well-known patterns (design patterns). But what if you have a new problem? Or what if you’ve just crafted a better solution for an old problem? Terrific! Other programmers won’t be able to understand your new billion dollar solution if you don’t document it properly! Keep your mind working at its best and flying as high as you like, but remember to take the time to describe inside your code how and why you made it.

当您将编程语言的基本构造用于尽可能多的用途时，并且为了解决众所周知的问题，请使用众所周知的模式(设计模式)，以使可读性和可扩展性重叠。 但是，如果您遇到新问题怎么办？ 或者，如果您刚刚为旧问题设计了更好的解决方案，该怎么办？ 了不起！ 如果您没有正确记录下来，其他程序员将无法理解您的新十亿美元解决方案！ 始终保持最佳状态，并随心所欲地飞腾，但请记住花时间在代码中描述如何以及为什么创建代码。

可扩展性 (Extensibility)

Both readability and extensibility contribute to the maintainability of your code and overlap at certain times. But to sharpen the difference, readable code is maintainable in terms of its style and extensible code is maintainable in terms of its logic. The same argument applies to design patterns since they contribute to both readability and extensibility.

可读性和可扩展性都有助于代码的可维护性，并且在某些时候会重叠。 但是，为了缩小差异，可读代码在样式上是可维护的，而可扩展代码在逻辑上是可维护的。 相同的论点适用于设计模式，因为它们有助于可读性和可扩展性。

Your code is extensible when it follows some re-usable, logical, well-known patterns, be it defined standard design patterns or normal logical flow. For example, some developers favor using the Singleton design pattern for working with database connections. As another example, most of us would use a standard foreach to iterate over an array, which is a standard flow. One might use a for loop or even a while loop under similar circumstances, but this is fairly uncommon in PHP so it should be documented why such constructs were necessary foreach to avoid confusion.

当您的代码遵循一些可重复使用的，逻辑的，众所周知的模式时，无论是定义标准设计模式还是正常的逻辑流程，您的代码都是可扩展的。 例如，一些开发人员倾向于使用Singleton设计模式来处理数据库连接。 再举一个例子，我们大多数人将使用标准的foreach遍历数组，这是标准流程。 在类似的情况下，可能会使用for循环甚至while循环，但这在PHP中并不常见，因此应记录为什么每个都必须使用此类构造以避免混淆。

The major aspects of extensibility are decoupling and encapsulation. Decoupling means that your code (mainly functions/methods and classes) shouldn’t depend or overlap each other; code should be as “pure” as possible, with any overlapping functionality and other non-related entities removed. If you are writing procedural code, your functions should only contain the logic that their names imply; don’t make functions do too much! Use a “toolbox” approach when writing code – small basic routines work together to build big complicated systems.

可扩展性的主要方面是去耦和封装。 解耦意味着您的代码(主要是函数/方法和类)不应相互依赖或重叠。 代码应尽可能“纯净”，并删除任何重叠的功能和其他不相关的实体。 如果要编写过程代码，则函数应仅包含其名称所隐含的逻辑； 不要让函数做太多！ 编写代码时使用“工具箱”方法–小型基本例程可以一起构建大型复杂系统。

Encapsulation is an integral part of decoupling. Whenever you decouple components, you have already done some encapsulation. To encapsulate components, continue separating its internals from the global scope and make all interactions with it occur at its interface level. This is a modular approach which makes it easier to later remove or update any part of your system as opposed to a monolithic design which makes your code spaghetti.

封装是去耦的组成部分。 每当断开组件的耦合时，就已经完成了封装。 要封装组件，请继续将其内部结构与全局范围分开，并使与其进行的所有交互都在其接口级别进行。 这是一种模块化方法，与使代码成为意大利面条的整体式设计相反，它使以后更容易删除或更新系统的任何部分变得更加容易。

效率 (Efficiency)

You should keep efficiency in mind from the very first line of code in any project since bottlenecks are known to come from some very unwise usage of language constructs, for example nesting several loops and using recursion unwisely, and from some unwise usage of logical patterns, for example not making use of caching and sending/receiving data to/from streams without proper buffering. Efficiency is important, but don’t compromise the first two rules for the sake of it. In fact, compromising readability and extensibility can actually result in less efficiency! For the majority of cases, efficiency is directly proportional to applying the first two rules. When there is an exceptional situation, do your best to make sure you have other ways of keeping your code good.

您应该在任何项目的第一行代码中都牢记效率，因为已知瓶颈是由于一些非常不明智的语言构造用法(例如嵌套多个循环和不明智地使用递归)以及不明智地使用了逻辑模式而引起的，例如，在没有适当缓冲的情况下，不利用高速缓存并向/从流发送/接收数据。 效率很重要，但不要因此而折衷前两个规则。 实际上，损害可读性和可扩展性实际上会导致效率降低！ 在大多数情况下，效率与应用前两个规则成正比。 在特殊情况下，请尽力确保您还有其他方法来保持代码良好。

摘要 (Summary)

In this article I introduced you to what makes code good. I limited the discussion to three major aspects: readability, extensibility, and efficiency, and described what each means.

在本文中，我向您介绍了使代码变得更好的原因。 我将讨论限制在三个主要方面：可读性，可扩展性和效率，并描述了每种方法的含义。

Now that you know what constitutes good code, we can move on to the next parts in the series. In part 2 I’ll show you some things to be on the look out for when refactoring for better readability.

既然您知道什么是好的代码，我们就可以继续学习该系列的下一部分。 在第2部分中，我将向您展示在进行重构以提高可读性时需要注意的一些事项。

Image via Fotolia

图片来自Fotolia

翻译自: https://www.sitepoint.com/practical-refactoring-1/

重构-改善既有代码设计