So usually i have to look at one part of the logic, work out the flow and see what else is missing or jamming up the pipe to have caused a renegade flow.
But in my later years of having the luxury of maintaining huge web app written in their own proprietary style with no useful document, comments [gasp!] or even some old timer who can actually remember the flow or the behavior of each component. I ended up guessing how things should work.I look up for the best way to deal with this problem as Larry Wall, Perl God once quoted laziness is a programmer's virtue, and i didn't want to spend too much time and effort looking into old code, getting tangled in a maze of crappy lines of code and losing my mind and perhaps my beautiful set of hair too [creepy picture of Steve Ballmer comes to mind here - don't ask me why]
But i never really bother to implement these new learnings into my work as previously the crack and hack method was good enough to get the job done. Until more recently i have been caught again and again in a web of messy bug fixes courtesy of my own work. I found the biggest problems that i face when i deal with implementing a new feature or a bug fix is that i never can be too certain if i'm accidentally breaking something else.
So i begin to write unit test for my own code, for a few reasons. First of all it forces me to think of the conditions of the logic more properly and i can write better code, two i leave some bread crumbs for future developers to understand the behavior of the dare i say code that i've written and the tests can be combined in a full regression test in the future.
That would be good enough if the feature is something totally new which I and only I have the power to shape and mould. But it's not true is it for features/bug fixes which involves other codes?
0 comments:
Post a Comment