Java Development from hell (WARNING: redundancy detected)
-
I've inherited a java application. it's a Spring thing which runs in Tomcat7.
it's running into a dedicated VM, with 2GB of ram. not much, but it should be enough for what the app does.here i'll put a list of the horrors i've found:
when i logged into the tomcat web manager i found this:
##JVM
Free memory: 50.68 MB Total memory: 252.20 MB Max memory: 270.54 MBinside a bunch of controllers. this pattern repeats ad infinitum:
if (thing.getThingVariable(things[i]) != null) { doTheThing( thing.getThingVariable(things[i]) ); } else { System.out.println("Error: 4 - inexistentThing:" + things[i]); return null; }
isn't it beautiful when you get nullPointerExceptions in another method because someone tought it was a good thing to spew an error into the console of a web application?
stay tuned, next chapter: "yeah, we have unit tests, they fail, so we turned them off"
-
Seems like Tomcat is running with the Xmx250M option (default?)
-
Yeah wiring beans can be painful sometimes especially when you get into profiles and anything that isn't a singleton bean but I'm not sure that's how you handle it.
I suspect that's why there is a few unit tests here in the vein of
@Autowired
private Somebean sb;@Test
public void testSomebeanNotNull() {
Assert.assertNotNull(sb);
}We've also taken TDD to heart here too though
-
That's a really dumb test. The Spring container won't finish booting if the dependency isn't satisfied; it will instead throw an exception (with the stack trace from hell, but drill down and it will tell you what went wrong).
-
I was thinking that too but TDD!
TDD
TDD
TDD
TDD
*edit why in fucks name doesn't the A symbol actually work. Also it's font editing in every other application. Why is it just a tooltip for header here?
-
I was thinking that too but TDD!
TDD is people taking a good idea and beating it into a bloody pulp with stupidity.
-
I watched a video once where a guy was making a simple script using TDD. Now, I'm sure it was a little slower because it was a talk after all, but still, he was faffing about so much with doing it that way that I'm convinced that it would take him half the time to write the code, write the test and then fix any errors. AKA the "normal" way around.
Or maybe not. I don't know. It's backwards to my brain at least.
-
would take him half the time to write the code,
write the test and then fix any errors.and push it straight to productionFTFWD
-
I watched a video once where a guy was making a simple script using TDD.
Test-first makes a lot of sense during software maintenance. Prove that the bug is there, make the change to fix it, prove that the bug no longer shows up, keep the test around so that it doesn't become discofixed without people knowing about it.
But much of what passes for TDD is just Bad, as it ends up just testing the components on which you rely. Test your own code, or your integration with someone else's, but don't test their stuff. (That's both difficult and Not Your Job.)
-
Test-first makes a lot of sense during software maintenance.
Yep. Just like any bug fixing, first you want to reproduce it! And no one likes those temporal bugs that just won't stay fixed. Well, I say no one, but...
-
much of what passes for TDD is just Bad
In order to do Test Driven Development, one must first understand testing.
-
the default. these fuckers didn't even checked the server configuration. despite being told that their application couldn't handle more than two concurrent users
-
Why is a rooster in a pot labeled "ice cream"? Blood red ice cream? What flavor is that, Satan's Asscheeks?
I have all kinds of problems with these emojis, also these posts annoy Boomzilla.
-
Microsoft done did a better job:
-
-
Microsoft done did a better job:
-
@Onyx said:
would take him half the time to write the code,
write the test and then fix any errors.and push it straight to productiondirectly on the production serverFTFWD
FTFS
-
That works, as long as you're consistent.
See, if you do that all the time, something is bound to be broken, constantly, and that's considered the normal state of affairs. Meaning, you're never the guy that broke the prod. However, that one time it actually fixes something, you're hailed as the hero that fixed the prod!
Filed under: 504 OK, I still have the Kuro-bar, am I breaking the server?, Also, this extension thing is actually useful, need to get that in the store...
-
Test your own code, or your integration with someone else's, but don't test their stuff. (That's both difficult and Not Your Job.)
What do you do
ifwhen a third-party tool or the compiler itself does things not quite the way the documentation says?
-
What do you do
ifwhen a third-party tool or the compiler itself does things not quite the way the documentation says?For preference? If the developers are willing to fix, upgrade. If the developers aren't, BURN IT WITH FIRE! Seriously, there's usually someone else who'll at least try to do a better job.
If that's not possible, then we get to less good options like writing a replacement yourself (since then at least the bugs are your own bugs) or, if all else fails, struggling on with that junk because it there's no sane alternative after all. That last one usually happens for political reasons of various types.
-
That last one usually happens for political reasons of various types.
sigh
I think the worst alternative is to hack together a workaround that relies on the bug. If the developers fix their bug some day, our application breaks. If enough developers rely on that bug, it becomes unfixable.
(Relying on someone else's bug is not just belgiuming bad style, I'd say it is even an Evil Idea™.)