Question

Um, What important information do you analyze when reviewing code? help please heh

Answer 1

Having code review strictly defined as a part of daily programming workflow brings a few benefits to the team.

1. Found in the code, mistakes like mistypes, security bugs, architectural errors and business logic flaws are much easier and quicker to be fixed than if found by QAs in the product already compiled. So code review saves a lot of time and, eventually, money, especially if otherwise the bugs would be found only after the product went public.

2. Code review is a form of communication between developers and thus a great way to help both junior developers quickly raise their proficiency through learning their trouble spots and senior developers find common mistakes.

3. When a reviewer learns the code written by someone else, he gets to know the product better. Thus, when it comes to making new decisions on the development process, there are at least two specialists who: perfectly know how the product has been written; can easily communicate to each other; able to find and discuss the best possible solution for the current problem.

4. If a developer knows his work will be reviewed, it simply means he is more motivated to write the flawless code and will put more efforts to that. That makes both the developers and the code reviewers more professional, since both of them will strive to achieve better results in their work.

Step-by-step explanation:

The 'code review' process gathers fellow developers and sometimes QA specialists, who together use predefined approaches to read the code line by line and then check it for flaws, adherence to coding and commenting standards and consistency with the overall program design.

I Hope This Helps.

Answer 2

THE IMPORTANT INFORMATION TO ANALYZE WHEN REVIEWING CODE

1. Establish goals. Code reviews are more than just finding errors and bugs.You may be thinking about adding new features and how to implement them. You may be trying to ensure that the code meets certain style standards established by your organization.

2. Do your first pass. Try to get to the initial pass as soon as possible after you receive the request. You don’t have to go into depth just yet.

3. Run tests. You can try to spot tiny errors by looking at line after line of code, but it’s often easier to run the piece of code in question and see how it works.

4. Do your in-depth pass. Now it’s time to sift through the lines of code with a fine-toothed comb and find the bugs, the style issues, the misplaced parentheses, etc

5. Submit the evaluation. Minor changes such as coding errors and typos can be fixed as you go along. But major changes should always be discussed with the code’s author first. Ask yourself, is the change you’re proposing really a problem