Thomas Ganss wrote: > You haven't specified where your main pains are. > Do you have at least rudimentary architecture ? > How often do you have code reviews / refactored your code ? > Have you been striving for good code ? Is it a total mess ?
Umm... We have been striving for good code, but being a small place, it's rather difficult. The software in question is basically an ERP program for the mattress industry. The program started out as a project for one company, with a single programmer, with plans to grow. The program, I am sure, still has much code left from those first days of coding. With customer demands for new features, we do our best to keep everything extensible, and open, but once a piece of code is written, it's very rare that it will be changed unless it is being debugged. > Guessing only from the number of screens, you probably > have more than trivial amounts of data. You have guessed right. One of our largest customers is using an Access database that is around 800Mb and they have licenses for about 20 concurrent users (of our program). I know this may not sound huge for someone who works at Walmart head office, but it's been interesting to get Jet to work well. > *Based on that assumption*, I'ld move the data FIRST. > Get rid of the JET engine! If you are certain you will > have to support SQL server, make it SQL server and > MSDE/new express version first. Only then (perhaps) > think about adding a totally free database engine. > If not, take your pick but *move the data*. This is a very interesting thought. That would mean a whole bunch of rewriting of the current codebase. The thought had been to write the port in an extensible manner, allowing Jet, but being written well enough to easily use other backends. We'll have to see. > While you are on it, refactor the old code into something > at least resembling a 3 to 5 layered approach with COM. > Doesn't need to be perfect 100%, but more than 50%. This makes sense, but OTOH, it might be more worth our time to properly redesign in a more OOP friendly language. > Then exchange the parts that benefit the most by > implementation inheritance, since VB's interface inheritance > is arguably the "best" technical reason for redundant code. > > I'ld guess the business layer[s] would be the next things to convert - > but if your VB-forms are mostly slightly augmented copies differing > only slightly, the GUI actually might benefit most from a rewrite, > if the business rules are written redundance poor. > > One of the typical scenarios asking for GUI inheritance > is insurance - customer data is only specific for few fields > and even policy field groupings resemble each other across > similar policies. A "minmally redundant" business layer could > even in VB be implemented without too much sweat- for instance > by having methods overwritten in a inheritance based OOP - > design as name mangled methods on objects responsible across > similar problem domains, keeping the "common" methods clean. Unfortunately, there is little duplication across the different screens. There definitely is some, like screens for picking a date range of a report, with the reports being hardcoded (in our internal report writing format) behind the print button on the screen. Here, the report should be moved to a different module, or imported from a special format report file, but the number of these types of screens are few and far between. > Check your code with a critical eye - > even code forced to be totally OOP for > > technical reason=langauge > > can be written across a wide spectrum of quality. > > If there is nothing which is good enogh to be converted last > or no segregation/layering at all in the current program, > (even if it came from the DOS dinosaurs, there were > "good coding practices" known - some of the old "libraries" > were better decoupled than modern day OOP class libraries.) > get rid of most of the people responsible and start only then. I think what needs to happen, is good coding guidelines put into place, with a language that supports proper OOP. Inheritance doesn't even work in VB, let alone polymorphism, unless you want to count passing Variants and figuring out the types and then returning a variant. > my 0.02 EUR Thanks for your thoughts. It gives me some things to think over. -- http://mail.python.org/mailman/listinfo/python-list
