My team of about 70 programmers is developing C and C++ code for embedded, multiprocessor, image-processing project. We have a coding standard, and hold design and code reviews. The problem is that we don’t have solid design review checklist.
Currently we have scattered design checklists, but most of them are vague. For example, you might find statements like these:
- Component design should be extendable.
- Coupling should be reduced between modules.
The problem of these statements is that they are totally subjective and not measurable. Extendable design for me might means something else for another one.
Is there some kind of widely accepted or proven checklist or design rules that can serve as a basis for our design reviews, especially for our object-oriented C++ code base?
First off, you should gather the scattered design checklists and associated pieces so that they are in a single place for reference.
Second, the leads of your various teams need to review the components that have been pulled together. Note what looks:
- good and universal (for your organization)
- needing work but still universal
- good, but specific to particular teams
- needing work, and not clear if anyone can use
Third, start using the first category with everyone in their reviews. Next, start revising the middle two categories so they can be used and it’s clearly understood who they apply to. Finally, ditch the ones in the last category.
Congratulations, you have the basis for your organizations guidelines.
That’s probably not going to be sufficient for everything you need. Start taking a look into external resources like:
- Google’s C++ Style Guide
- C++ Coding Standards by Sutter & Alexandrescu
- This SO Question: Coding Style …
- Or this Microsoft link which has additional links below
1
I don’t think it is possible to create one set of definitive rules that tell you if your design is good or not. There is just too much variability in what is considered a good design.
However, bad designs do have some level of commonality. These common elements are described in a similar fashion as design patterns and called anti-patterns. You can use then to avoid bad designs from becoming reality.
That said, I don’t think you should use a design review to rubber-stamp a design as good or bad. In my opinion, a design review should be more like a brainstorm session where one designer presents his initial ideas on how to tackle a particular feature and his co-workers ask critical questions and give their views on the issue, so that you identify the trouble-spots in the design.
1
You can always refer to standard texts on good and bad software design patterns to decide with more certainty as to what is good or bad design. Basically referencing a standard text might help your team identify shortcomings that could cause problems in the future, in terms of for e.g. extensibility, scalability etc. Basically this way you can leverage others’ experience.