You'd think that if "even a little downtime is a big deal," and you're rewriting your company's core application, you'd test it under a realistic load before launching it.
If "... the team could not build a subset of the production environment to accurately predict how the penguins would fly," it's a red flag something is amiss with your architecture.
It's faster since 3.0 for sure. I'm happy with it on a P4 2.8 at work.
It crawls along on my PowerBook, but that's running at 400 mHz so what do you expect? Funny thing is, every time I go back to BBEdit and the command line, I don't last. The snappiness is great, but Eclipse's auto-complete, refactoring, and background compile make me faster overall.
Works great once it's set up and you don't change things. Sometimes my Firewire RAID array wouldn't show up correctly if OS X detected the drives in a different order.
And maybe this is obvious, but I couldn't find a way to move to OS X software RAID over to a Linux box without reformatting the drives.
Well, yes, poorly-written or not useful. I did a bad job of explaining myself. It's true that the best approach is to write tests around the legacy code.
However, my practical experience is that it's time-consuming to build unit tests for bad legacy code. So I tend to invest my time in broader-scope system/integration/functional tests for existing code.
I've also found that bad code tends to have many redundancies, unnecessary interfaces, "we'll need it someday" features, and "wouldn't it be cool..." features. Once I understand the code and have system tests, I'm going to remove that code anyway, so why bother to write unit tests for it?
Good point. But not much value in wirting the unit tests until you are ready to start refactoring that bit of code. It's hard to predict ahead of time what you will work on.
And sometimes the dependencies and interfaces are so bad, you're better off building system/integration test coverage to support your refactorings.
Based on experience with existing projects, this is the way to go -- write unit tests for bug fixes and new features.
It's an overwhelming, time-consuming, job to write unit tests for a big mass of existing code. I also find that once I get going, I end up throwing away or heavily refactoring a lot of legacy code anyway. So if I had written tests, I'd be throwing them out, too.
End-to-end system test, even superficial ones, have more value.
I will say that sometimes writing tests can help you understand messy old code.
You might want to check out "Working Effectively With Legacy Code" by Michael C. Feathers. It's got some good stuff.
Some of your graduates most have taken jobs at my company.
/** * Gets the name * @returns String name * @author RG * @throws Exception * @param boolean */ public String getName(boolean b) [ if (b) { return magicalSideEffectGetter(); } else { return name; } // Changed by RG 10/18/1999 // Re bug fix #1044 // return name; }
Of course, the old code, revision date, and author is in CVS. And the bug is in the bug database, but... more comments are better, right?
In the real world, this method would be about a page long.
Slashdot Mirror
You'd think that if "even a little downtime is a big deal," and you're rewriting your company's core application, you'd test it under a realistic load before launching it. If "... the team could not build a subset of the production environment to accurately predict how the penguins would fly," it's a red flag something is amiss with your architecture.
It's faster since 3.0 for sure. I'm happy with it on a P4 2.8 at work. It crawls along on my PowerBook, but that's running at 400 mHz so what do you expect? Funny thing is, every time I go back to BBEdit and the command line, I don't last. The snappiness is great, but Eclipse's auto-complete, refactoring, and background compile make me faster overall.
Tomcat is just a servlet container. A J2EE-compliant app server like Geronimo is a servlet container + a whole lot more.
Granted, most people only use their app server as a servlet container.
Those people would be better off with just Tomcat or Jetty. Interesting/nice to see Jetty included with Geronimo.
Works great once it's set up and you don't change things. Sometimes my Firewire RAID array wouldn't show up correctly if OS X detected the drives in a different order.
And maybe this is obvious, but I couldn't find a way to move to OS X software RAID over to a Linux box without reformatting the drives.
Well, yes, poorly-written or not useful. I did a bad job of explaining myself. It's true that the best approach is to write tests around the legacy code.
..." features. Once I understand the code and have system tests, I'm going to remove that code anyway, so why bother to write unit tests for it?
However, my practical experience is that it's time-consuming to build unit tests for bad legacy code. So I tend to invest my time in broader-scope system/integration/functional tests for existing code.
I've also found that bad code tends to have many redundancies, unnecessary interfaces, "we'll need it someday" features, and "wouldn't it be cool
Good point. But not much value in wirting the unit tests until you are ready to start refactoring that bit of code. It's hard to predict ahead of time what you will work on.
And sometimes the dependencies and interfaces are so bad, you're better off building system/integration test coverage to support your refactorings.
Based on experience with existing projects, this is the way to go -- write unit tests for bug fixes and new features. It's an overwhelming, time-consuming, job to write unit tests for a big mass of existing code. I also find that once I get going, I end up throwing away or heavily refactoring a lot of legacy code anyway. So if I had written tests, I'd be throwing them out, too. End-to-end system test, even superficial ones, have more value. I will say that sometimes writing tests can help you understand messy old code. You might want to check out "Working Effectively With Legacy Code" by Michael C. Feathers. It's got some good stuff.