Refactoring: mission (un) feasible?

What if the project sources resemble a swamp, and it is planned to live in it for a long time? Refactoring project source codes is the most profitable of the two alternatives to deal with the problem. The second of the alternatives - to throw away and rewrite everything again - usually does not suit you, for various reasons.

And how to do this refactoring, even if you don’t know where to start? How to drain a swamp of code and not drown it?

Of course, the ideal option is to consider refactoring one of the activity on the project from the very beginning and to allocate project time to the team for it. In life, oddly enough, however, most often it turns out that the previous project leader was not very puzzled by this issue, preferring to go with the flow; perhaps he was hoping to someday bring this burden to a less fortunate lead - while the project had not yet collapsed; or maybe just didn’t know what to do. Chef, the mustache is gone!

I'll tell you how I do it.

Rule number 1: refactoring is a process.Therefore, first of all, you need to make friends with the thought that you can’t convert it to "hurt yourself" either in a week or two. After realizing this fact, we take the book of M. Fiesers, “Effective work with the legacy code” (Working Effectively With Legacy Code), and begin to get acquainted with it. At the same time, we make sure that we are well familiar with the source control that we use, and in parallel with reading the book we put in order the code (primary “cleaning”): delete the commented out and “dead” code, it does not have a place in the project; we structure "porridge" according to files; Let's bring in line with the coding convention. It is better not to carry out more serious alterations at this stage. If it is possible to write unit tests, you should think about it (but do not, since it is usually useless to write them at this stage, let's endure to the next :).

Rule number 2: source control around the head . You will laugh if you find out how many people don’t know what brunch is. A good knowledge of source control will help you not to completely hurt the 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 regarding brunches, even if you do not have svn. You can also search online for slides Source control & Agile and tyts . A lot of fun about source control is written here .

Rule number 3: automate the routine, it’s a sign - for luck :)This is me to the fact that it is worth getting some autobuild system in order to assemble the project in 1 click. Such a system is really a plus for morality, because I have often met a situation when a project had to be built with my hands from the studio, copying artifacts in complex sequence for strange shared folders on the network for half an hour, and this situation very much discouraged people from then change. I used CruiseControl for a long time (I recommend it), it’s used TeamBuild from TFS (party policy), but not fundamentally - make / ant / nant, which starts from the console, will do for a start.

By the time the book is read, the codebase should look decent so that at least it doesn't feel sick from the source, as well as being easy to rebuild. Of course, it’s still far from feeling the beauty of the project, and the architecture is not that lame - it barely walks :)

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

As you write your code, it will become clear that our subsystem will somehow have to access the rest of the code in some way. We select this interaction surface in 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 to make it exactly and how neatly is unprincipled, 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 at it and refactor the existing “meat” behind it according to the book that you read while continuing to cover the tests in depth. The book I referred to also describes tricks that can help if you do not start with your own sandbox and add functionality to the existing (bad) code.
In general, rule 5 flows smoothly from here (the swamp, after all!) Rule 5: if it works, don’t touch it, but write a unit test, then break it . And then - if our code somehow climbs there.

In general, “from a great distance”, the process of ennoblement of the project should look like crystallization of brine — it starts at a small point and gradually covers the entire project, breaking it up into parts, which then “recrystallize”. Your “sandbox” will be this little point from which it all begins. Rule number 6: divide and conquer - i.e. sort it out, fix it, change it .

I almost forgot - at each stage of your long (do not hesitate;) way automated code analysis tools can be useful to you - (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.

Everything seems to be.
In the comments, I would like to see your ways of taxiing "bydlokod" by refactoring - there is nothing to hide useful information.