http://qs321.pair.com?node_id=384130


in reply to Howto best review code that has not been reviewed before?

Greeting again Monks!

Thanks for all the very useful responses and links! Have a lot of ammunition for the next meeting.

Let me try to answer some of the questions that were asked in the responses. First of all it really still is safe to travel! The software to control traffic consists of several layers. The bottom layer designed under very strict procedures and safety standards. It is designed by one team, reviewed by another, and tested by yet another. It contains the logic, some hardwired, to make sure no two trains can ever make use of the same track and collide.

The software we make sits on top of this layer. Since the bottom layer is secure the guidelines for our software are less strict. If our software fails things just stop and are delayed.

We do use revision control, a 20 year old one, but we do have a nice GUI in Perl/Tk on top of it. We do do a lot of testing, but only after all code is written.

To give an idea of the problems we have in our code:

A lot of this stuff, I hope, can be prevented if we get some budget for code review. Going to try to get them to adapt the approach suggested by dragonchild and etcshadow; only fix and refactor the stuff in functions that were changed,and add unittests in the process.

Management is now atleast entertaining the idea of code reviews and with this method and all the arguments supplied by the others that replied there is some light at the horizon.

Have the feeling that we are not the only shop with this kind of problem though :).

Many thanks again.

Have Fun

Replies are listed 'Best First'.
Re^2: Howto best review code that has not been reviewed before?
by Aristotle (Chancellor) on Aug 19, 2004 at 07:18 UTC

    You might enjoy reading about the Big Ball of Mud, and how to attack it.

    Makeshifts last the longest.

Re^2: Howto best review code that has not been reviewed before?
by adrianh (Chancellor) on Aug 19, 2004 at 12:47 UTC
    To give an idea of the problems we have in our code...

    I'd recommend you take a look at Peter Scott's excellent Perl Medic, which has lots of very good advice on maintaining legacy Perl.