This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Forums » Discussions » Code review considerations - QA#5

Tuesday 21 May 2013 9:58:37 am - 3 replies

» Read full blog post


In the previous article I discussed code repository branching and code review procedures. Today I will follow up this by talking about what to focus on when doing the actual review of a code change.
[QA4 - Branching and code review procedures]

Tuesday 21 May 2013 10:24:40 am

Good read!

You mentioned that going back and improving existing codebase is very important and helps to build new code on the top of the old one. And I can't agree more, however this is rarely possible. Most of the projects are being developed in the shadow of a deadline and bad decisions made at the beginning of the project almost always make it to the final version. It's sad but it's true. That's also why I don't believe that proposing new solutions during code review makes much sense. It's too late, the code is there, time was spent. Deciding on solution should be a part of planning phase, long before any code is written.

Tuesday 21 May 2013 12:11:21 pm

Thanks, Konrad.

I agree that such decissions ideally should be done before you get to the stage of code reviewing. But it's not always done, and bringing up that discussion at the code review is better than it not being brought up at all. I would like a focus on it there to make certain it is a focus in the project at all.

Some bad decissions are always done at the beginning of a project. Some decissions you don't at the time know the consequences of. That's why you cannot not have the possibility of adjusting the project later. If there's no time for adjustments then you have failed on estimating the project.

Tuesday 21 May 2013 3:40:03 pm

If you dont make room to change the solution after it is coded then you are not developing, you are merely regressing and building technical debt. When projects are small and not meant to be maintained the technical debt means little, but if the project is meant to be maintained, then you need to actually be developing, and that involves being able to scrap a solution and implement a different one.


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from