How do you view large blocks of new code

Question

I am a strong proponent of code reviews, whatever that means. I know that these are different things for different people and groups, and they can be applied differently at different stages of development.

When I make a one-line change in #define to correct a typo in the user’s tooltip, “Hey Joe, did I spell“ FooBar ”correctly? Easily. When you make several related changes to several related functions, the sanity check on the shoulder is 10 -15 minutes of work.

But what about a new project with tens of thousands of brand lines slapping the new code? This does not happen so often, so it’s not so convenient for me. How do you view it? One on one? Set off and browse offline with later feedback? In the settings group?

For different approaches, are there any rules of thumb for viewing rows / hours, so can I estimate the time it takes?

Answer 1

I think it is recommended to review the code before it reaches thousands of lines of completely new code. After that, it becomes the problem you are facing.

Answer 2

My approach is to decompose the work into smaller pieces and review the changes as soon as possible. It’s much easier to browse 100-200 lines of code than browse a few thousand, and you can distribute any changes that need to be made to the following code.

Answer 3

Personally, when I am in charge of another programmer; I check the source check in diff as close as possible to the daily

This ensures that everything is operational. If their changes are not in working order, I will wait until they are.

If they take more than 3 days to get changes in working condition ... I take this as a warning flag that needs to be examined. Usually this is something simple, for example, making too many changes at the same time or basic refactoring with too many consequences.

Answer 4

If the code is quite complicated, I like to view it using the original one-on-one developer. That way, I can ask them to explain how this works, instead of wasting time figuring it out for themselves. I use the diff tool to see what has changed in several files, and we go through the stream, paying close attention to the changes.

If the code is pretty straight forward, I usually look at it myself. I will only call the original developer if I have questions or problems. Once again, I use the diff tool to see what has changed and go through the stream.

If there is a ton of new code / changes, then I usually only look at the critical path and check other parts of the code in places. In this situation, I am not trying to find anything that may be wrong with the code. My assumption is that testing will capture most errors. My review is mainly to catch any major bugs, to make sure the code follows the basic good software practices and that it will be easy to maintain.

Answer 5

Ideally, you will review the code as you create it so that you can provide feedback and significantly reduce problems.

However, I would use static analysis tools. This can check for regular problems and even do a general analysis of dependencies in the code.

And the very first thing that would be: does he have unit tests? Start with them, check that they are well understood, they can quickly identify some communication problems.

If the code for an existing system that you are working on as a team, you should consider:

• Continuous Integration + makes small changes (instead of making a big commit in a few days)
• TDD - focus your team on unit tests, especially to avoid traction
• Have not only unit tests, but also other types of tests. Separate different types of tests, you do not want to run a load test trigger for each assembly, for example.
• Try using static analysis tools with assembly
• Review assembly information as a first step before moving on with a code overview.

Answer 6

Integrating code review easily in your projects:

• Provide a mandatory rule to verify the code before any registration.
• Let the reviewer write a comment for registration.
• Call the reviewer in sessions in a formal way (for example, by adding a required comment field to your VCS) or informally.
• Come up with a reward for auditors, for example. some kind of scoring system, for example, on SO :-) (seriously, otherwise no one will do this)

Answer 7

If you cannot do incremental reviews as others have suggested, you can still manage the post-fact review of new features by dividing it into manageable chunks. You can do this on a one-by-one basis, in stages, on an individual basis, or whatever works best for your system.

A tool such as Code Collaborator allows you to add selected files to your code overview, so you can break them down this way. Without a tool, you can also simply submit a reviewer several feedback packages for related files.