0

I have been asked to do a code review of about 50 applications over a period of 6 weeks. (Management has changed and the new CTO asked for an full internal software audit)

I am wondering, what are the key areas to evaluate software on? (The focus should purely be on the quality of the codebase and not e.g. how it was deployed)

Please note: This is not the same question as "What are the 9 or 10 qualities of software?".

The first few things that came to my mind are:

  1. Code readability (descriptive variable/method/class names, comments etc)
  2. Layering (data/business/UI)
  3. Configuration (no hardcoding)
  4. Sufficient level of abstraction (to remain flexible)
  5. Organisation of the code
  6. Use of 3rd party libraries (approved or not etc)
  7. Separation of concerns
  8. Test coverage (if applicable)
  9. Modularity of code
  10. Penalties for breaking principles such as "DRY"
  11. ...

I will appreciate your answers to help me identify an extensive list of what you think are the key areas for software evaluation.

closed as too broad by gnat, FrustratedWithFormsDesigner, Robert Harvey, Bart van Ingen Schenau, amon Nov 28 '14 at 13:39

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    Have you been told WHY you have been asked? There may be specific objectives: security audit, potential acquisition, etc. – paj28 Nov 27 '14 at 21:58
  • 6
    And the obligatory link to the only real metric for code - WTFs per minute. – Telastyn Nov 27 '14 at 22:04
  • @paj28 good point, I'll put it in the question - reason = audit – z0mbi3 Nov 27 '14 at 22:22
  • 4
    My guess is none of the above. Stop thinking like a Programmer and think more like a CTO. He is interested in things like Cost/benefit, Security, Can I hire prorammers/contractor with the skills to maintain it, do I have key person vulnerability. Is the code Maintainable, how hard/expensive is to change (compared to a "new" system), will it run on new hardware and updated OS's... If he is thinking at the level you have described, he is a programmer, not a CTO. – mattnz Nov 28 '14 at 1:02
  • Good point @manttnz. – z0mbi3 Nov 28 '14 at 12:10
3

50 applications in 6 weeks sounds enormously ambitious. You need to tell your new CTO that this is only a lightweight review; there's no way you're going to detect bugs or security flaws in this time.

I'm mostly familiar with code review for security, and the rule of thumb I use is 10 KLOC per day - and even that is ambitious, and can only be achieved by focusing on the parts of code that really matter for security.

A few suggestions:

  • Design a report template at the beginning, and get the CTO to approve this. It should be concise: a few red/amber/green statuses for different areas, maybe a few list of key people, issues, etc.
  • Include documentation in your review. This could include tickets on your issue tracker.
  • Speak to key people related to each application. This lets you get to the important issues more quickly.
  • Establish what coding standards you have, and whether they are mandatory or advisory.
  • Take a risk-based approach, where you spend more time on applications that matter more.
  • Try to establish whether you could reasonably make changes to the application. You sound like you've got decent coding skills: if you think you'd struggle, this is clearly a concern for future maintenance of the app.

Apart from that, good luck! This is an opportunity to shine, so make the most of it.

Not the answer you're looking for? Browse other questions tagged or ask your own question.