Hi Monks!
We know software engineering principles and how to write maintainable code, and it's all well and good.
AFAIK, we should also know that in the real world, with real projects and real requisites, we have to find a middle between software engineering and "make things work".
I don't want an ideology war, I know what should be better, but IMHO I think - probably I'm wrong- maintain real code in real world, according the engineering principles it's very very hard. Not impossible, but difficult. That's because in real world, requisites changes too fast, and projects are not "so" descriptive: in real world, in real companies, in the control room there aren't always project manager with competences in IT.
So, you can try to write your perfect code but after release - no beta testing, it's horrible but in real companies can happen-, control room changes requisites and operation, and this must be done for "yesterday", and they changes again and again and again, because they don't know really what they want.
In order to satisfy "everything at once" you see your almost-well-written-code fall into WTF-code: you can control it almost, but entropy grows.
How do you manage this situations, what are your experiences about?
Greetings.In reply to Good programming practices and changes in requirements: how to maintain good code by DanBev
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |