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.
That perl code seems an example of stuff that's definitely *not* fun to work with because it is so dated and of such marginal quality. It fails best practices guidelines at a surprising number of points for such a small routine and even (I think) totally misuses 'local' (I think they may have intended the lexical 'my'). That 'local' misuse may even lead to weird hard-to-diagnose errors! Your situation is no doubt a classical problem. Making existing code healthy is a horribly expensive "invisible-benefit" job unless you can do it over a long gradual period -- which may not ever get fully completed. Rewrite is potentially equally expensive and maybe even especially risky as well, so what to do? If an opportunity arises to adopt or develop an entirely new management interface (which gives concrete business benefits), that would seem to offer a very enticing alternative. In a small developer environment, code quality really requires management (understanding and) commitment and some outstanding developer capability (and buy-in), at least in the lead-slot. Lacking these, the prognosis would be iffy, eh? If you have to stick with present code, I echo the recommendation that SJS made elsewhere to start with documentation and testing. Any top-level requirements specs is better than nebulous product definitions. Any testing is better than no testing! And besides, docs & testing (or even just thinking about testing) are useful for any path that is followed. Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
