Re-reading "refactoring": the second

The bad taste of those codes:

Duplicated code: The most common replication sticker syndrome. People will naturally think of extracting methods.

Long Method: This is too common. It's still helping a little kid refactor her Python code, a function that writes more than 100 lines. The most painful thing about her is that it's too painful to debug. In fact, the most painful is still behind. People do not want to split the function, the new program will feel the demolition of special scattered, and then N-layer call relationship, looks very laborious, rather than heap in a lump. This is a very wrong idea. The benefits of splitting are decoupled, reused, easy to test, easy to understand (of course, designed to be reasonable), and easy to control changes.

One of the principles in the book is that whenever a note is needed to explain something, we write the Eastern evil that needs to be explained in a function, and the function name embodies the annotation information. Most of the time, the extraction method can be done.

Large class: Similar to Long method, use the method of extracting subclasses, or the method of extracting an interface.

Divergent changes: This is mainly about the division of classes is reasonable, if a class for different reasons, in different directions to change, to modify the class of multiple functions, the class should be split. The pursuit is that all corresponding changes to an external change should occur in a single class, and all content within the new class should reflect that external change.

Shotgun surgery: If a single change triggers multiple changes within a class, you should use the Move method or move field to move the modified place to a class. This and divergent changes seems to have some contradictions, in fact, is unified. In general, the class adheres to the principle of "flock of birds".

To page 80.

Re-reading "refactoring": the second