|
|
Posted by Dikkie Dik on 12/21/05 19:44
tony@marston-home.demon.co.uk wrote:
>>>If it ain't broke, don't fix it
>
>
>>Again, where have you been in the last 20 years? If a statement does not
>
> appear to be executed because it "silences" any error condition, you
> have a hell of a time finding bugs. PHP code can be very hard to read
> because of its un-strictness. When I see a parameter initialised as
> FALSE, I assume it is a boolean. I mean, the initialization is also
> documentation. You see the parameters in your editor wherever you use
> them. But it may be an array, a string, or whatever. But FALSE will not
>
> break the code. You can write monstrous code that coincidentally works
> with the parameter types you pass. Now code that is illegible is not
> legible by your collegue either, *SO IT IS BROKE*. And, *YES, IT NEEDS
> TO BE FIXED*.
>
> You are missing the point. I'm talking about the situation where a
> developer looks at an existing function which works in thousands (if
> not millions) of scripts, and decides that the code is not elegant or
> clean enough for his taste, so he decides to refactor it, but this
> refactoring then breaks a lot of scripts. The argument that the code is
> now *cleaner* or *purer* is irrelevant to the customers - all they know
> is that previously valid scripts do not work any more. They do not care
> if the code is clean or dirty, just that it keeps on working as
> expected.
>
Not at all. If a refactoring breaks something, it is by definition not a
refactoring. But that is beside the point. I encountered far too much
code that was beyond maintenance.
"Don't touch that code. It works, OK?"
"What does it do then exactly?"
"We don't know, but it works!"
I heared this conversation at least 200 times. It is exactly my
definition of broken software. Working software (if I create or maintain
it) is something I have control of. I know the state of my code, because
the unit tests tell me what state it is in. When I change a line of
code, even if I have a less then bright day, I still know the
consequences just by running the tests. Working software is not some
cute image on my screen, but proof that the components do what they are
supposed to. And that they obey their contract. If the code has become a
minefield it is definitely broke. Worse even. You can't repair what you
can't touch.
It is absolutely not irrelevant to the customers wether the code can be
maintained or not. Or how dangerous that is, or how much time it would cost.
Especially when environments change. The OS changes, the language
changes, the computer hardware changes, the goal or use of the
application changes and all those changes can call for maintenance. I
think no company or programmer can afford to say to a customer that a
piece of code is declared "not broke" and, oh, beyond fixing. A dirty
hack is a time bomb. It is only safe to use one if you are 100% sure you
disarm it in time. If not, it is guaranteed to blow in your face when
you least expect it.
Best regards
Navigation:
[Reply to this message]
|