In our Systems Analysis and Design class we’re studying RUP and not having ever worked in a company big enough to warrant its use, I’m having trouble understanding a lot of the advantages we’re told it has, although I’m sure I’d start to see them in a big enough software project.. maybe.
We’ve been told how immature software engineering is, and how we still have so much to learn from more mature manufacturing industries. Like when building a car (do we really want to take advice from American manufacturers right now?), a blueprint must be created first, and only when you have the entire thing designed, end to end, do you start the actual assembly of the product. I’ve heard this argument quite a few times and it’s frustrating to hear it over and over again, simply because software is not a car. It’s not an airplane either. Nor a house. I would argue that software development is more similar to writing a book than it is to any traditional manufacturing process.
The key is refactoring. With a book you can re-arrange pages and chapters, and rewriting a page isn’t expensive. However, if you’re making a car and you have all the parts in front of you, it’s expensive to change something or reassemble things. Even more so with a house or airplane: just not comparable to software.
Anyway, I’ve been doing a lot of refactoring recently. I guess my style of development is XP-like, if you have to give it a name. I throw something together that works, then clean it up when I have it working, then continue throwing more stuff together until that works and repeat the cleanup. It’s a pretty obvious way of development if you’re doing a solo project, but I just wanted to make note of it as refactoring’s been my focus for a while now. It’s an interesting bit of work to try to help a design fall out out of the mess that’s there. I usually end up with monstrously long functions and then:
- Restrict scope of parts that seem related. Usually I have these double-spaced out so it’s just a matter of putting braces around them.
- Break these parts out into functions. This might involve introducing globals, but that’s ok.
- Group the related functions and globals together and have a good hard think about how classes might be designed with them, and how these classes would work together.
One thing that I keep concentrating on is semantic cohesion. Just looking at the above bullet points alone might put something together that works, but that’s not enough. By thinking of what each class means and what it represents, it becomes much easier to group them together with a super class and use those classes polymorphically, and to extend them in directions that make sense. Right now if you look through my code you might see a lot of “cross-cutting concerns”, where one function is doing something that it really shouldn’t have to be doing. A nice way of spotting these is, for example, when I find code creating rigid bodies and meshes inside my mouse listener. If a mouse event callback wants to do that sort of thing, that’s ok, but it should allow the graphics and physics classes look after it instead of taking on that responsibility itself.
Refactoring code is something I did a bit in Havok for a few weeks. There was one particular project which I was given ownership of, and most of the work I did on it was reducing duplicate code, and removing hard-coded values (and of course, finding flexible, centralised ways of replacing those hard-coded values).
It’s quite enjoyable to sit down with a big mess of code, and spend a few hours moving things around only to have no more apparent functionality, but an altogether better system. Later on in the project it really will help me rewriting code, and if I end up taking a break from it around exams and coming back to it when applying to a Master’s programme, if it’s an intuitive design I should be able to jump right in.
Not wanting to break tradition, here’s a video of Yellow Magic Orchestra playing Rydeen. This TV performance was in 1993, ten years after they broke up. (Thanks Jim!)
