Refactoring: mission (not) possible?

What to do if the source of the project resembles a swamp, and it is planned to live in it for a long time? Refactoring project source codes is the more advantageous of the two alternatives to deal with this problem. The second of the alternatives - throwing away and rewriting everything anew - usually does not suit, for various reasons.

And how to do this very refactoring, even if it is not known where to start? How to drain the swamp code and not to drown it?

Of course, the ideal option is to consider refactoring as one of the activities on the project from the very beginning and allocate the project time to it. In life, oddly enough, but most often it turns out that the previous lead of the project was not much puzzled by this issue, preferring to go with the flow; perhaps he was hoping someday to relieve this burden of a less fortunate lead — before the project fell apart; or maybe just did not know what to do. Chief, usyo is gone!
')
I'll tell you how I do.

Rule number 1: refactoring is a process. Therefore, first of all, you need to become friends with the thought that it will not be possible to alter the “zashib” either in a week or in two. After understanding this fact, we take the book by M. Fizer, “Working Effectively With the Legacy Code” (Effective Work with Legacy Code), and begin to get acquainted with it. At the same time, we make sure that we are well accustomed to the source control, which we use, and in parallel with reading the book we put in order the code (primary “sweep”): we delete the commented out and “dead” code, it has no place in the project; we structure "porridge" by files; We align with the coding convention. More serious alterations at this stage it is better not to carry out. If there is an opportunity to write unit tests, you should think about it (but not to do it, as it’s usually useless at this stage to write them, let's endure until the next :).

Rule number 2: source control around the head . You will laugh if you know how many people do not know what brunch is. A good knowledge of source control will help you not to end up a final project if some of your many changes are “incompatible with life”. In such a situation, only rollback will save the father of Russian democracy. Sobsna, I recommend the well-known work of SvnBook tyts , especially in terms of the brunch, even if you do not have svn. You can also search online for slides Source control & Agile and tyts . Very fun about the source control is written here .

Rule number 3: automate the routine, this is a sign - to luck :) This is me to the fact that it is worth acquiring some system autobild, to collect the project could be in one click. Such a system is really a plus for morality, because I have repeatedly encountered the situation when the project needed to be built by hands from the studio, copying artifacts in a complex sequence through strange shared folders on the network for half an hour, and this situation greatly discouraged people from then change. I used CruiseControl for a long time (I recommend), TeamBuild from TFS (party policy) is used, but not fundamentally - make / ant / nant, launched from the console, comes down to start.

By the time the book is read, the codebase should look decent so that, at least, not sick of the source, and also easily rebuilt. Of course, oh how far the feeling of the beauty of the project, and the architecture is not that limping - barely walks :)

Rule number 4: start small but good . Namely: the further strategy of working with the project is as follows: for the part of the project we are working on, we select a sandbox in which everything will be “as it should be” - isolate it from the rest of the code, write it _good_ - OOP, best practices in hand. Unit tests are highly desirable. Highly because refactoring to a keen eye and an honest word is better never at all :)

As we write our code, it will become clear that our subsystem will have to somehow access the rest of the code in some way. We separate this interaction surface into a separate API (for .net, for example, I create a static class through which methods my code interacts with the old one) and also write unit-tests for it. How exactly do it and how neatly - it is not fundamental, because we will gradually get rid of it. After our “beautiful” code successfully works with this API, and there are tests for this API, you can look behind it, and refactor the existing “meat” according to the book you read, continuing to cover the tests inwards. The book to which I referred, also describes techniques that can help if you do not start with your own sandbox, but add functionality to the existing (bad) code.
In general, from here a smoothly expires (swamp well, after all!) Rule 5: it works - do not touch, but write a unit test, then break it . And that - if our code somehow climbs there.

In general, “from a long distance,” the process of refining the project should look like a crystallization of the brine — it begins at a small point and gradually covers the entire project, dividing it into pieces, which then “crystallize”. Your sandbox will be this little point where it all begins. Rule number 6: divide and conquer - i.e. figure it out, fix it, change it .

I almost forgot - at each stage of your long (do not hesitate;) ways, you may find useful tools for automatic code analysis - (Visual) NDepend, FxCop and Gendarme for .net / mono, simian, all sorts of line counters and others (lint, for example, if you are C / C ++). Java-, php- and other comrades can enter the required.

It seems everything.
In the comments I would like to see your ways of taxiing the “bydlokod” by refactoring - there is nothing to hide useful information.