home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / software / 4454 < prev    next >
Encoding:
Text File  |  1992-11-22  |  2.9 KB  |  64 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!spsgate!mogate!newsgate!chdasic.sps.mot.com!dichter
  3. From: dichter@chdasic.sps.mot.com (Carl Dichter)
  4. Subject: Re: Code Reviews (was SE going offshore?)
  5. Message-ID: <1992Nov22.195802.23993@newsgate.sps.mot.com>
  6. Sender: usenet@newsgate.sps.mot.com
  7. Nntp-Posting-Host: 223.197.55.10
  8. Organization: SPS
  9. References: <1992Nov13.142754.12335@ornl.gov> <6962@dove.nist.gov> <1992Nov17.172139.15122@bnr.uk>
  10. Date: Sun, 22 Nov 1992 19:58:02 GMT
  11. Lines: 51
  12.  
  13.  
  14. I don't know whether you'd call them group code reviews or not:
  15. The way that we recommend (described in detail in the January 92 Unix Review 
  16. article "Two Sets of Eyes") is inspection before meeting.
  17.  
  18. In this method, you send your code to at least two, but no more than five people. 
  19. Ideally, this includes at least one experienced and one in-experienced person.
  20.  
  21. These reviewers read the code and provide results to a person designated as 
  22. a review recorder. This recorder may be the owner of the code, or one of the 
  23. reviewers. A meeting may not be held if no errors were found, or so many
  24. that the code needs to be completely reworked.
  25.  
  26. If a meeting is held, only the issues/problems found are discussed--
  27. you don't sit together while +20K lines of code are being reviewed.
  28.  
  29. Modules of code are reviewed as they are available to prevent future
  30. problems by educating the code author and all participants.
  31. If you wait until the code is all done to review it, you'll find
  32. many instances of the same errors-- most preventable.
  33.  
  34. Biggest reasons to do inspections:
  35. 1. Improve the process of making code by educating all participants.
  36. 2. Find opportunities for reuse: "You don't need to write that-- there
  37.    is one in Greg's code" or "That's great! Could you generalize it a little
  38.    and put it in the library?"
  39. 3. Make code more reusable and maintainable, by pointing out where it can 
  40.    be generalized or improved.
  41. 4. Finding bugs in code, design, requirements, etc.
  42.  
  43. Bob Bagwell's idea of using skilled, cheap, non-local workers to do inspections
  44. only helps in 3 & 4. Seperate workers may catch errors, but unless the US
  45. workers study the review results, they'll continue to crank out rubbish (1) --
  46. more so-- they know someone is picking up after them! These separate workers
  47. won't have the knowledge of other code, future code needs, conventions, or the 
  48. end-user requirements and market (2,3,4). 
  49.  
  50. However, if Bob means that the "super-programmers" and the "cheap labor" work together,
  51. you'll build a good crew and accomplish all of the objectives. You don't have to 
  52. use non-local labor, you can use recent grads or software technicians (cheap
  53. programmers). After a while, most of your "cheap labor" will have become 
  54. "super-programmers": you can take on more projects (after you find more "cheap
  55. labor").
  56.  
  57. ----------------------
  58. Carl R. Dichter               "iwannanugui"
  59. Motorola ASIC Division
  60. email: dichter@chdasic.sps.mot.com
  61. /*
  62. ** "People who never make mistakes work for people who dare to."
  63. */
  64.