Joshua Kerievsky's book "Refactoring using templates"

I read the other day sabzhevaya book. It was released back in 2008 (and the previous edition was even earlier), but I only got it recently. In theory, it would be necessary to read it after the book Fowler “Refactoring. Improving the existing code ”, which Kirievski constantly refers to, but I haven’t got to Fowler yet, although this didn’t make reading much easier. The second book, which is best read in advance, is “Object-oriented design techniques. Design patterns "gang of four.



The essence of the book "Refactoring using templates" is that in the book the author has collected 27 fairly complex refactorings, most of which are intended to introduce patterns into the program architecture described in the book of the gang of four as painlessly as possible. As Kirievski writes at the beginning, he often starts programming without using patterns until this part of the code needs to be expanded, then he is taken for refactoring. True, there is another refactoring in the book, which, on the contrary, saves the code from using singletons (the author calls the disease when using singletons for any reason, singletone and suggests opening an anonymous society of singletons).



After the first (and so far the only) reading, I didn’t particularly like the book’s idea, because many of the described refactorings are quite complex (in the sense that you don’t automate them, I want to believe that so far), but stupidly repeat the steps described, because The code has its own characteristics. The main thing is to understand the general ideas of individual refactoring steps, and, relying on them, already rework your code. Unfortunately, I realized this already towards the end of the book, so after a while I am going to re-read the book again.



In the course of reading, I often noticed that in the book I was not even interested in the refactorings themselves, but it is interesting to just read about how other programmers build the program architecture - almost all examples of refactorings are shown on the code from real projects. At the same time it is useful to read about the errors in the design.

')

When describing refactorings, Kerievsky first uses UML diagrams to show what happened and what happened, then writes where this refactoring may be needed, what it can improve, and what can be impaired. After that, he describes the main steps of refactoring and shows these very steps using the example of reworking a real code.



All examples, like Fowler, are in the Java language, but he does not use any particular language features, so the language is absolutely not important.



I would not say that the book is easy to read, however, closer to the middle of the book, my reading has noticeably accelerated, I don’t know what this is all about. The book is very strangely translated, and I don’t even know with a plus or minus sign. The fact is that many expressions were left without translation, including the names of refactorings. On the one hand, it’s good that you don’t have to wrestle with the translation in order to guess which particular term the author was referring to, but on the other hand the names of the refactorings could also be translated. It turns out that you are reading such an English-Russian text. There were places somewhere when the term was cited both in Russian and in English, why this could not be done in the whole book is not clear.



In general, the book is curious, you can read. Apparently it should be regarded as a continuation of the book of Fowler, but here I can be mistaken, because, as I said, the Fowler book has not yet been fully read (it is my next in line).



By the way, can you recommend some more good design books? And at the same time, maybe someone has already read the book. Effective work with legacy code , is it worth it?