Author Archives: osworup007

How much time to spent during Code Reviews

Last week, I wrote my blog on Code Reviews. This week I am writing about how much time we should be spending during Code Reviews. I found an interesting article titled “Don’t Waste Time on Code Reviews” on DZone written by Jim Bird.

According to the article, research shows that reviewers find far more maintainability issues than defects (a ratio of 75:25) and spend more time on code clarity and understandability problems than correctness issues. There are a few reasons for this. Finding bugs in code is hard. Finding bugs in someone else’s code is even harder. In many cases, reviewers don’t know enough to find material bugs or offer meaningful insight on how to solve problems. Or they don’t have time to do a good job. So they cherry pick easy code clarity issues like poor naming or formatting inconsistencies. But even experienced and serious reviewers can get caught up in what at first seem to be minor issues about naming or formatting, because they need to understand the code before they can find bugs, and code that is unnecessarily hard to read gets in the way and distracts them from more important issues.

Code reviews add to the cost of development, and if you don’t do them right they can destroy productivity and alienate the team. But they are also an important way to find bugs and for developers to help each other to write better code. So do them right. Don’t waste time on meetings and moderators and paper work. Do reviews early and often. Keep the feedback loops as tight as possible. Ask everyone to take reviews seriously – developers and reviewers. No rubber stamping, or letting each other off of the hook. Make reviews simple, but not sloppy. Ask the reviewers to focus on what really matters: correctness issues, and things that make the code harder to understand and harder to maintain. Don’t waste time arguing about formatting or style. Make sure that you always review high risk code and high risk changes. Get the best people available to do the job – when it comes to reviewers, quality is much more important than quantity. Remember that code reviews are only one part of a quality program. Instead of asking more people to review code, you will get more value by putting time into design reviews or writing better testing tools or better tests. A code review is a terrible thing to waste.

I would say that the title was somewhat misleading though. I wish the title was less misleading, though – it’s easy to read as “Don’t do code reviews,” which isn’t what the post was saying. I think the title was either poorly worded or it was written that way intentionally as click bait. I think a better title would have been “Don’t Waste Time During Code Reviews”. I was spending lots of time reviewing code that a static code review tools can do. Form now, I would rather use tools like FindBugs and PMD which uses static analysis to look for bugs.

Source: https://dzone.com/articles/dont-waste-time-code-reviews

 

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

#7_343

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

#7_443

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

#6_343

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

Test Automation

This week I read on article on Automated Testing. The article explains why Test Automation software is the best way to increase the effectiveness, efficiency and coverage of our software testing. As per the article, an automated testing tool is able to playback pre-recorded and predefined actions, compare the results to the expected behavior and report the success or failure of these manual tests to a test engineer. Once automated tests are created they can easily be repeated and they can be extended to perform tasks impossible with manual testing. Because of this, savvy managers have found that automated software testing is an essential component of successful development projects. Some of the major merits of using Automated Testing over the Manual software testing are:

Automated Software Testing Saves Time and Money: Once created, automated tests can be run over and over again at no additional cost and they are much faster than manual tests. Automated software testing can reduce the time to run repetitive tests from days to hours. A time savings that translates directly into cost savings.

Vastly Increases Your Test Coverage: Automated software testing can increase the depth and scope of tests to help improve software quality. Lengthy tests that are often avoided during manual testing can be run unattended. They can even be run on multiple computers with different configurations. Automated software testing can look inside an application and see memory contents, data tables, file contents, and internal program states to determine if the product is behaving as expected. Test automation can easily execute thousands of different complex test cases during every test run providing coverage that is impossible with manual tests.

Testing Improves Accuracy: Even the most conscientious tester will make mistakes during monotonous manual testing. Automated tests perform the same steps precisely every time they are executed and never forget to record detailed results. Testers freed from repetitive manual tests have more time to create new automated software tests and deal with complex features

Automation Does What Manual Testing Cannot: Even the largest software and QA departments cannot perform a controlled web application test with thousands of users. Automated testing can simulate tens, hundreds or thousands of virtual users interacting with a network, software and web applications.

Automated QA Testing Helps Developers and Testers: Shared automated tests can be used by developers to catch problems quickly before sending to QA. Tests can run automatically whenever source code changes are checked in and notify the team or the developer if they fail. Features like these save developers time and increase their confidence.

Source: https://smartbear.com/learn/automated-testing/

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

#5_343

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.

Code review guidelines

Since we are doing an assignment on “Software Technical Review”, every reviewer is required to follow certain guidelines while reviewing the code. So, this week I read an article on code review guidelines written by Madalin Ilie.

Ilie starts the article by explaining why Code Reviews are important? As per the article, software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive.

Then the author, lists some useful tips for the reviewer, as:

Critique code instead of people – be kind to the coder, not to the code. 

Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.

The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.

Note that Review meetings are NOT problem solving meetings.

Ask questions rather than make statements.

Avoid the “Why” questions. Although extremely difficult at times, avoiding the “Why” questions can substantially improve the mood. Just as a statement is accusatory—so is a why question. Most “Why” questions can be reworded to a question that doesn’t include the word “Why” and the results can be dramatic.

Remember to praise. The purposes of code reviews are not focused at telling developers how they can improve, and not necessarily that they did a good job. Human nature is such that we want and need to be acknowledged for our successes, not just shown our faults. Because development is necessarily a creative work that developers pour their soul into, it often can be close to their hearts. This makes the need for praise even more critical.

Make sure you have good coding standards to reference. Code reviews find their foundation in the coding standards of the organization. Coding standards are supposed to be the shared agreement that the developers have with one another to produce quality, maintainable code. If you’re discussing an item that isn’t in your coding standards, you have some work to do to get the item in the coding standards. You should regularly ask yourself whether the item being discussed is in your coding standards.

Remember that there is often more than one way to approach a solution. Although the developer might have coded something differently from how you would have, it isn’t necessarily wrong. The goal is quality, maintainable code. If it meets those goals and follows the coding standards, that’s all you can ask for.

I much agree with everything in this list. While every item on the list is important, some have more resonance for me. As much as possible, I will try to make all of my comments positive and oriented to improving the code. Overall, I believe this article will definitely aid me to be more effective during my code review time.

Source: https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines

From the blog CS@Worcester – Not just another CS blog by osworup007 and used with permission of the author. All other rights reserved by the author.