It sounds like the process of code reviewing has sorta begun. It hasn't as an official thing, but a rumbling under the feet of your development team. There are two sides of the issue, those who care, and those who don't. Obviously you are one of those who do care.

Code reviews establish one and one thing: Is what you are looking at 'good'? New code, old code, code from last month, is any of it worth anything. The biggest gain you earn is akin to the opensource idea of "many eyes". You can witness, if you haven't, many solutions being posted on pm that have small mistakes, but have been caught by someone else.

You have a few argumenets usable for management if you need to convince them that should you make the slightest change for the better, it is for the better. Better code means easier maintenance, simpler design, faster updates after refactoring etc ec.. there is a return on acting upon fixing bad code. I suggest the refactoring text by fowler on this. He has a good 10 pages on interacting with manglement on this issue.

As for the best way to review? I'm guessing there is no design document. Start from the biz straight down to the code. A task needs to get done.. (use case) This task involves doing these N steps with certain conditionals in a certain direction. (activity diagram for the use case). The data is stored as such (class diagrams and entity relationship digrams) using these bits of logic. (in code documentation, class diagrams, sequence diagrams etc..). As you cover case by case, you'll slowly envelop everything. It's a bit of systems analysis and design with an existing project/product.

Being a tech person, your biz cases need not be the best MBA (Master of Business Administration degree) speak in the world. If your biz team helps you, you'll have the definitive manual on your system. And when you make changes, anyone can browse the manual and figure these things out. More importantly, you'll know the relationships and dependencies of how everything works.

Update: MBA cleared up (tnx davis)

----
Then B.I. said, "Hov' remind yourself nobody built like you, you designed yourself"

In reply to Re: Howto best review code that has not been reviewed before? by exussum0
in thread Howto best review code that has not been reviewed before? by gumpu

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.