|
1. What kinds of problems do your code reviews find? Our reviewers attempt to find the problems that matter, rather than the stylistic or trivial issues often found by automated analysis. The following types of problems are found regularly:
a. Security issues, such as:
- Failure to authenticate or authorize the calls being made to the middle tier
- Passwords being stored in the database in clear text or being hashed without salt
- Failure to protect middle tier methods from a dictionary attack
- SQL injection vulnerabilities
b. Performance concerns, such as:
- Failure to close database connections
- Excessively chatty interfaces between distributed objects
- Unnecessary database calls
c. General architectural and coding issues, for example:
- Incorrect technology choices, often forcing the project to implement complex functionality that is already freely available.
- Inconsistent architecture throughout the project, resulting in increased maintenance costs and more bugs.
- Cut-and-paste coding, where the same code is repeated in dozens (or hundreds) of places. A bug found in this code results in a major effort to fix it.
- Incorrect use of inheritance, leading to unmaintainable code
- Badly designed roles, resulting in a security framework that cannot be used.
2. When should our project be reviewed? It depends on the size, complexity and target audience. Traditionally, a project-wide code review is done just before the software is released to beta customers. This gives the development team a chance to fix performance or security issues before they impact the wider release. If your project includes a technical architecture phase where a small portion of the functionality is completed for use as a reference by other developers, that portion can be reviewed less expensively than the complete application.
3. What kinds of projects should be reviewed? Code Reviews are useful for reducing risk. External code reviews are also a great tool for helping your team learn more about a new technology. If any of the following describe your project, you should consider an external code review:
- The project was developed by an outsourced team.
- The software has aggressive performance or scalability goals.
- Some or all of the development team is new to the technology used.
- An attacker stealing a copy of the data or deleting the data would be catastrophic.
4. Will you make the changes to our code? We feel it is most effective to have your developers make the code changes. Many of the problems found in reviews occur repeatedly in the code. Having your developers make the changes saves you money. Plus, making the changes is an effective way for your development team to learn how to avoid making the same mistakes again.
5. Will you review our requirements? At Code Reviewers, we focus on the actual code. We suggest business requirements be written with and reviewed by your users (or business experts and marketing department for shrinkwrap software).
6. Can you arrange for multiple reviewers? It is usually not cost-effective to have several experts review the same code simultaneously; the additional defects found rarely justify the cost. However, we will frequently have multiple reviewers inspect a single project; for example a database expert reviews the database, while a different reviewer inspects the architecture and application logic.
To learn more about Code Reviewers or to request a quote, please e-mail us at info@codereviewers.com or contact us via phone, fax or mail.
| 
