how to handle code that is deemed dangerous to change, but stable?

Question

What is the best way to handle a big team that has access to a stable but no so pretty code, that is easy to introduce bugs into?

I'm looking for something along the lines of SVN locking the file(s).

Answer 1

I'm thinking more like refacter, if the code is hard to work with then it needs to be redone, it may take some time but it will likely be better in the long run as you won't cause as many problems.

Answer 2

Yeah, lock it until you can write a more maintainable replacement for it.

Michael Feathers' book on legacy code will be a good read for that team. Of course, easier said than done, but that particular code can become a design debt for your software in the long run.

Answer 3

Svn does have a setting for locking the file to prevent concurrent access (similar to Source Safe) but I would recommend building some automated unit tests and integration tests around the fearful code. Hopefully you have a solid QA group as a safety net as well.

Answer 4

Black-box it in a library so it can't be messed with. Document the interface well.

Answer 5

Write unit tests if you don't have them already. Then start refactoring, and keep doing regression tests upon every commit.

Answer 6

Produce complete unit tests so that if it has to change, you know it still works.

Answer 7

Tell them to leave it alone.

It works, what is the benefit of changing it other than prettying it up (and the potential cost is high) so you just need to explain the cost/benefit analysis.

I would hope your developers would be smart enough to understand this and, if not, you can use your source code control system logs, rolled up tightly, to beat them to death:-) .

Answer 8

1. Write automated unit tests. If you have tests that test the code you are maintaining you can be assured that any modifications haven't broken it. Test frameworks such as JUnit can help.

2. Get a copy of Martin Fowler's classic book Refactoring and read it. Pay particular attention to the concept of code smells. This will point you to particular refactorings that will help with your situation.

3. Get a good IDE that has refactoring support built in. IDEs won't support all of the refactorings in the book but many of them will have a number of them. Eclipse and NetBeans in the Java world are free and support refactoring well.

4. Consider a continuous integration server like Hudson to track whether your tests are failing.

Answer 9

If you have Subversion, locking files isn't terribly unless the code is just a few files. Subversion doesn't let you lock sub-directories, just individual files. Plus the lock can be broken.

What you probably want is a pre-commit hook script. You can do pretty much anything, but I've used it to restrict access to a certain subdirectory to specific people (branches, SQL scripts). Also, unless you have access to the server you can't break a pre-commit hook.

See the Version Control with Subversion book on Implementing Repository Hooks. The Subversion distribution should include some good examples of how to do exactly this.

Answer 10

Set up automated builds and unit tests. Any kind of repository that tracks changes is good, but won't prevent bugs.

Also, only make changes that you can run right away. The Agile methodology that says release early and often helps here. That way, you can get a better understanding of the code as you get deeper into it.

Basically, if you can, start with refactoring that doesn't change the functionality. Then introduce new functionality on top of the refactored code. Do it slowly with small, deliberate changes.

Locking the source while changes are made probably won't help as much as communicating what is changing and where. Your best approach is to make open communication channels. Set up a forum using something like Slashcode where they can discuss things openly and ask questions, and leave a record.