English Original:Top 6 Refactoring Patterns to help your Score 80% in Code Quality
In the past to do a lot of code in the daytime, found some code quality more common problems, the following is the top five :
bloated class :
Classes are bloated because developers lack the understanding of the most basic coding principles, the "single Responsibility Principle" (SRP). These classes tend to become bloated because different and functionally missing methods are placed inside the same class.
Long method :
There are several reasons why methods can become very long: the code for many functionally complex modules with no correlation is placed in the same method. This is mainly because developers lack the concept of SRP. Multiple conditions are placed within the same method, which often occurs within a long method. This is due to the lack of McCabe code complexity and the concept of SRP comparisons.
a large number of parameters :
I often encounter these kinds of situations, some methods interact with other methods, or call other methods to pass in a large number of parameters. This occurs if you change one of the parameters, you have to make changes within multiple methods.
constant values are everywhere :
It is often found that developers (especially novices) use constant values (mostly devil numbers) with definite meanings, but do not give them the appropriate constant variables. This can reduce the readability and legibility of your code.
Ambiguous method name :
In many cases, the following method names can affect the readability and legibility of the code: vague, not meaningful, method name technical, without mentioning the name of the domain concerned
6 methods of reconstructing the above code odor (gimmick)
Here are 6 refactoring methods that you can use to help you solve the code quality problems of 80% (80-20 Principles) and help you become a better developer. Extract class/Extraction method: As mentioned above, a code odor like "bloated class" (a class that provides functionality that should have been provided by several classes) should move the methods and properties in the original class to the appropriate number of new classes. The methods and properties of the corresponding new classes in the old class should be removed. In addition, some classes are sometimes too bloated because they contain member methods that are used by other classes to be members of other classes. These methods should also be migrated to the appropriate classes. Extraction method: Like the "too long method" mentioned above, the code odor can be eliminated by extracting code from the old method into one or more new methods. Separation conditions: Many times, a method is long because it contains several branch statements (If-else). These branching conditions can be extracted and moved to several separate methods. This does greatly improve the readability and legibility of your code. Introducing Parameter objects/retaining global objects: I found another very common scenario when I was doing code reviews-several parameters were passed in. The problem is primarily related to the need to add or remove a method parameter from an existing method. In this scenario, it is recommended that the related method parameters be composed of an object (the introduction of Parameter objects) so that methods pass these objects instead of each individual parameter. Replace magic numbers with symbolic constants: for meaningful and literal constants that are used everywhere, you should assign them a named constant. This can greatly enhance the readability and understanding of the code. Renaming method: As mentioned above, ambiguous method names can affect the usability of your code. These ambiguous names should be renamed to meaningful names that might be relevant to the business term to help developers better understand the code through the business context. This is tricky and requires developers to collaborate with business experts to sort out the business requirements that the code needs to meet. Interestingly, this refactoring approach may seem very easy to understand, but it is often overlooked by many developers, although this is often the case in the Refactor menu items of the IDE in Eclipse.
Turn from: http://kb.cnblogs.com/page/199831/