Tracy Reed wrote:
On Fri, Oct 31, 2008 at 03:43:29PM -0700, Tracy Reed spake thusly:
So all of that complication is there because when he wrote webmin he
didn't know about perl modules and they have never migrated over to
using them.
So then the next question becomes: Do I refactor everything into
proper perl modules and get rid of all of that foreign_call stuff?
This would take quite some time and add no functionality and would
certainly break things requiring lots of debugging and preferably unit
testing written before we started that business so we would even know
what we broke. On the other hand, dealing with all that cruft just
because the dude didn't know modules pains me and there have got to be
some advantages to perl's module system that we are missing out on
here.
No matter which direction you go, you need to get sign off on what the
code *should* be doing. This needs to include management as well as the
daily users.
This can be unit tests, documentation, or something else.
However, until you establish what it should be doing, you can't make an
intelligent decisions as to whether to:
A) write unit tests and refactor the current code
B) switch to a completely different system
C) upgrade to latest and rewrite the custom stuff
If this really isn't part of their core business functions, you should
probably look at B the hardest. The goal is to spend as little time
maintaining code as possible. The best way to do that is to find a
system that matches your needs better.
You need to point out that this may require some adjustment to the way
they do things (business methods) to better match some existing system
in order to avoid having to pay the continuous cost of maintaining code.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
