VB to Python migration

[Josh]

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.