This is a little diatribe on how code reviews can help, not hurt. This draws heavily on the article A Case for Code Review . This is a real case scenario that happend recently and I am attempting to clue my manager in that code reviews are a good thing and don't necessarily waste time.. I was wondering if I could get any feedback: During the last several months of their development cycle we find that Tom wrote a CSV class, Dick wrote a CSV class, and Harry wrote a CSV class. How did it come that these three all spent time doing the same thing? Lets see… [No Code Review: The CSV Scenario] Tom writes a cool CSV class. It works well, is a little awkward to work with, but it gets the job done admirably. Tom begins to use this code in a production environment. Dick is given the task of wrapping Tom’s CSV class into a COM object that could be used server side. This also means that we get binary reuse from Tom’s code in clients such as Visual Basic and Visual Basic Script, in addition to C++. Dick realizes that he has an issue with Tom’s implementation. Tom seemingly used an additional class library to develop the CSV code (the code is not independent), and Dick’s server objects can’t use any additional libraries. Static linking is not really an option. Dick also finds that Tom’s CSV class isn’t as intuitive as it could be and feels clumsy using it. In the interest of progress, Dick decides to use his own CSV code to drive the wrapper and begins using that religiously (Dick was in serious error here. What he should have done was gone to Tom and asked him to make the necessary modifications to his CSV class to remove the additional dependency). Harry, not knowing that either of Tom or Dick had visited this particular problem, also wrote his own CSV code. Then, he dropped it in favor of using the Microsoft ADO CSV driver, which has a very consistent look and feel and is ready made (no development time). That means (for those of you keeping count!) that in the last couple of months, that CSV code has been re-visited THREE different times by THREE different individuals resulting in THREE different implementations. Tom begins developing the CSV code. He starts with a class outline that essentially defines the responsibilities of the class and how it would be used. This CSV code is probably implemented as a simple class with methods to open/close/read/write fields in a CSV file. Maybe even it defines a custom delimiter so we aren't left high and dry with just the ability to decode comma-delimited files. Pretty cut and dry. He offers it up for review. Tom, Dick and Harry all verify that it appears to behave as it was defined, maybe Dick and Harry offer suggestions to how they would interface with the class (ease of use) and be sure that everything was commented adequately. Now, during this discussion they figure out that they need to add additional responsibilities: namely the ability to query the CSV file and return a result set. This means that it would probably be beneficial to further enhance the design by offering a Row(s) class, which is nothing more than a collection of the fields that make up that row and some method to iterate them. It comes up that one of the intended uses of this code is in server side logic. This allows them to quantify how server side code should be crafted. They also figure "Hey, wouldn't it be great to be able to use this code in other environments? Like VB or VBScript?". Now the decision is made that the code needs to be distributed as a COM object, which entails further discussion on how the COM objects published interface will look. Sometime in the discussion, it comes up that Microsoft distributes an ADO CSV driver. The CSV driver is implemented as a COM object, and would work in each of the required environments. Further discussion ensues on the merits of using ADO or their own CSV code. A decision is made Tom either continues his progress on the CSV code or they opt to use the ADO CSV driver. The plus side being that every member of the team knows the tool(s) that are available to them, and when they should use one over the other. They all meet at the same bat time, the same bat channel next week, or at the next coding milestone for another review. Edited by - mordell on 4/3/00 11:35:21 AM

*gives standing ovation*

What an article! Code Reviews are kind of like posting to the GDNet message boards in fast-motion, and with less ego

The second case of your story is definitely better, IMO. Not only did they learn how a CSV class works, but they also shared ideas. Although they ended up using an already-built CSV in both cases, that is certainly not always the case (especially in game programming). The general equation is:


group_experience += (member1_experience ^ member2_experience ...)


(I''m using the exponent operator here.)


Or, perhaps an even more realistic equation would be as follows:


group_experience += ((member1_experience ^ member2_experience ...) - (member1_ego ^ member2_ego ...));



I feel that inflated egos are a team''s worst nightmare. But there''s something more important than just ego. Ego affects a team most because it affects communication. Code Reviews seem to be an excellent source of good communication. Anything that increases the amount of good communcation in a team increases the team''s chance for success. Anyway, that''s enough of my opinions




- null_pointer
Sabre Multimedia

I guess there is always the chance of bruising an ego...and to be honest, I used to NOT be open to having a group of people picking through my code. It always seemed so invasive..kinda like a physical exam.

But, after reading that article on gamasutra, I have been in high gear trying to get some sort of code review process implemented on our team.

I think that the biggest draw back in our scenario is that every one is always soo busy that they will automatically try to shootdown anything that might take away from development time.

Anyways...for those of you who haven''t read the article, check it out.

Zipster, do you know how arrogant that makes you sound?

Code reviews are a great thing. No matter how good you think you are, someone will think of something better, or something different that you may not have thought about.

You definately do not have the attitude of a good team member. I for one wouldn''t want to work with you. Team members share information, they don''t horde it.

As for stealing code... Do you use DirectX? Win32 API? I guarantee that you didn''t learn the Win32 API or DirectX without "stealing" examples other people wrote. Oh no! You''re not the coding god you think you are! You thief!!! If you are the one person who learns everything from only the documentation (with no code snippets), then I apologize.

<< most peoples coding styles is way different than mine, since mines the best anyway >>

::rolls eyes::


Books to check out:
Game Architecture and Design
Code Complete


Josh
http://www.jh-software.com