Have Geek Brain

Where should the code be stored before checking the code?

Disclaimer I am not doing a code review, so this question is of purely academic interest.

I've seen a lot of stackoverflow posts that advocate / require code validation before it is allowed into source control.

If you do this, where do you store the code in the unsolicited code and how do you deal with the problem where the developer needs to update the code to resolve conflicts resulting from another check - are you requiring them to get their code reviewed again?

Thanks.

0


a source to share


7 replies


The code should be checked out in your repository (SVN, TFS, etc.). You can tweak the development branch (or even per developer) if you want it to not end up in the trunk until it is reviewed.



+4


a source


Code that is not tested is still tested. And trust is an important thing in development. so the answer is that the code only belongs to source control. From there, some get it for review. If there is a problem, you can undo it. Anything else is just a lot of chatter for something most of the time. Remember, the code in the repository is not "code in production"



Each user must update the data from the repository before committing it. If you find many updates, it is indeed possible to run the tests again. If no problem other than fixing.

+3


a source


Academic answer to an academic question, as we do not conduct code reviews.

ALL is checked for source control. If it is not fully functional / checked out / checked out, it goes into this development branch.

+1


a source


This practice is a great reason to use DVCS like Git. Developers can work for longer periods of time without making code errors, but still use version control techniques that we have evaluated. If you're using something like SVN, you'll have to fork over every bug / feature / whatever needs to be written and reintegrate it after checking the code ... which can be painful.

+1


a source


It really depends on what tools and procedures the team has created.

For an informal review of the code, you can simply check it for version control and let other developers revise it in their own charts; problems found in the overview are then checked separately. (What our team is doing.)

For a more formal code review, a tool like Google Rietveld and (I'm sure) Smart Bear Code Collaborator allows you to download the code for the review and have a minified version control style for each view as it gets updated during the review. (If you're interested in learning more about code review, Smart Bear has a free book on the subject.)

+1


a source


My current team does code reviews even before presenting the results to stakeholders, which is why I'm in a camp that advocates controlling the source code only after reviewing the code.

However, one possibility is to save the patch file in a directory on disk instead of performing source control. Another option is to use a separate branch that the changes are tied to before they are merged into their target branch, but I'm afraid this approach is dangerous.

0


a source


We store it on the developer's desktop. It hasn't been tested on SVN because it hasn't been executed yet.

If you have a lot of code, this is a problem - you've waited too long for consideration.

If this is a reasonable amount of code, it can be emailed to reviewers. Maybe he needs a ZIP file to keep it organized.

We sometimes submit it to SharePoint, but this is rare. Mail usually works fine.

-2


a source






More articles:


All Articles