Code Review: What is it and Why is it Important?

Link to blog:

In this blog written by Dario Macchi, Macchi explains what is code review and why it necessary to do. He identifies what it is, its purpose, What is peer review, what do peer reviewers look for, what is an external review, what do external reviewers look for, and a few scenarios on what should code reviewers do if something goes wrong or if something is missed within the the code review process.

Code Review: is systematic examination … of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.”

Purpose: to validate the design and implementation of features within the code. Macchi identifies that there are two levels of code Review. These are the peer review and the external review levels.

Peer Review:  focused on functionality, design, implementation, and usefulness of proposed fixes for stated problems. Macchi explains why it is neccessary to perform a peer review within his company because in his company, they expect developers to talk to each other about their design intentions and receive feedback throughout the design and implementation process. Macchi’s real life experience gives us an example about the working field of software development and testing and how peer review is necessary. Peer Reviewers look for feature completion, potential side effects, readability and maintenance, consistency, performance, exception handling, simplicity, the reuse of existing code, and test cases.

External Review: addresses different issues and focuses on how to increase code quality, promote the best practices, and remove “code smells” or poorly written code. This review process looks at the quality of the code itself and its effects on the overall project. External reviewers look for readability and maintenance, coding style, and code smells.

A scenario that Macchi illustrates is “What is an external reviewer misses something?” The answer he gives is that we do not expect the external reviewer to make everything perfect. There is always something that would be missed. In this case, it is better to have more than one external reviewer. Another set of eyes always helps.

I chose this blog because I wanted to know the right process on reviewing code. I also chose this blog because it relates to my Software Quality Assurance and Testing Class since I was given an assignment to review code with my group of classmates which emulates the peer and external review process and emulates the real life workplace. Macchi definitely outlines the aspects of code review very well when he identified the two levels which were peer review and external review. Knowing code reviews will definitely help me apply myself in the future to many software development and testing jobs as well as my video game development career because there is always a 100% chance that I will review code with a team of other programmers no matter where I work at, especially when it comes to creating video gaming software.


From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

Code Coverage

Code Coverage

“Did my tests cover all the code?” – this would be a question that absolutely popped up in testers’ mind often when they were writing their tests. Code coverage could answer this question for them. Code coverage helped testers understand how much of their code was tested. Since I had not used any code coverage tools before, I thought that it would be a good idea to start learning about them through an introduction post. Below was the URL for the post.

In this post, Sten Pittet, who had been in the software business for ten years in various roles from development to product management, introduced the definition of code coverage, the common metrics in the coverage reports, a tip to choose the right tool for different projects. He also discussed about what percentage of coverage that testers should aim for. Moreover, he thought that testers should focus on unit testing first, use coverage reports to identify critical misses in testing, make code coverage part of their continuous integration flow.

Sten mentioned a few metrics that testers should pay attention to when reading coverage reports They were function coverage, statement coverage, branches coverage, condition coverage, line coverage. Function coverage showed how many of the functions defined had been called. Statement coverage showed how many of statements in the program had been executed. Branches coverage showed how many of the Boolean sub-expressions had been tested for a true and a false value. Line coverage showed how many of lines of source code had been tested. The example given in the post helped me understand the terms easier.

In Sten’s opinion, 80% code coverage was a good goal to aim for. Trying to reach higher coverage might turn out to be costly, while not necessary producing enough benefit. He also said that it was normal to have low coverage for the first run, and testers should not feel pressure to reach 80% coverage right away. To be honest, I really surprised that he only recommended 80% coverage. But when I thought harder, it made sense that getting higher coverage might be costlier, less benefit since real-life projects were usually bigger than school projects. He also highlighted that testers should write tests based on the business requirements of the applications rather than write tests that hitting every line of the code.

Furthermore, Sten emphasized that good coverage did not equal good tests. Code coverage tools could help testers understand where they should focus next, but they would not tell if their existing tests were robust enough for unexpected behaviors. Therefore, beside achieving great coverage, testers should have a good robust test suite and verify the integrity of the system. I agreed with him. Looking at his example, I could see clearly how bad it was if we only relied on the tools to write tests. Beside information about code coverage, I could apply his advice whenever I wrote tests.


From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.

How Does Angular Teach You to be a Better Software Engineer?

Link to blog:

In this blog, Tomas Trajan gives his insight about what differentiates Angular from other frameworks. From the given title of his blog “How does Angular teach you to be a better Software Engineer?” he highlights some of the key characteristics of using the Angular framework. In his blog, he organizes his argument into a few aspects about considering Angular.

First, Trajan briefly gives a summary of his experience as a software engineer, taking part in a few software engineering interviews by being both the interviewer and the interviewee. He claims that along with him and his colleagues, there have been many talented front-end developers. Next, Trajan explains the differences between a developer vs. an engineer and how to set yourself apart from the rest of the software developers/engineers by learning frameworks and libraries.

Trajan states that “Registering and cleaning up of click handlers to prevent memory leaks by hand can be quite tedious and error prone activity.” Since we don’r want to spend our time dealing with everything on the lowest level, it makes sense. Trajan also states that “What we want is to abstract away everything unessential so that we get to a level where we can focus on what really matters – delivering useful features to our users – while still preserving flexibility to get our hands dirty when necessary. ” This goes back to the acronym YAGNI since as a programmer, you don’t need to include things or abstract things that you think you may need.

According to Trajan, Angular is an opinionated framework that can teach you many of the industry’s best practices. It also helps you to adopt the mindset to implement nontrivial web applications. “Angular has a concept of ‘Module’ which can group and hide (encapsulate) its internal parts while clearly defining interface with imports /exports for the outside world. This can significantly reduce the amount of code you have to read and understand before you can see a big picture of the particular codebase because you don’t have to deal with unnecessary details. It will make you ask yourself questions about what functionality should you expose when creating a new module.”

I chose this blog because it gives an overview about how and why Angular is good framework to use, especially in terms of working with software. I’m also getting to know how to use it in my Software Design Class, which also sparked my intention on knowing a little bit more about Angular in the general sense. Trajan gave his good insight about Angular and provided his own experience on how it would be efficient in knowing how to use frameworks such as Angular. His brief explanations gave me the understanding on why Angular is great to work with. Angular will definitely help me in my future career as a video game developer because it is a good framework to grasp concepts about abstraction, import/exports, and modules.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

Creating Your Code Review Checklist

In this blog post, Erik Dietrich goes over creating a code review checklist. If you were to Google “Code review checklist”, the author lists results that may show up:

  • Does every method have an XML comment?
  • Do classes have a copyright header?
  • Do fields, methods, and types follow our standard naming convention?
  • Do methods have too many parameters?
  • Are you checking validity of method parameters?
  • Does the code have “magic” values instead of named constants?

He then goes on to list two problems with going through a sometimes lengthy checklist:

  • You can’t keep 100+ items in your head as you look at every method or clause in a code base, so you’re going to have to read the code over and over, looking for different things.
  • None of the checks I listed above actually require human intervention. They can all be handled via static analysis.

His suggestion for stream-lining the process of going through a big checklist is to automate the easy stuff. “Get static analysis tools that developers can install in their IDEs and run prior to delivering code, which will flag violations as errors or warnings. Get static analysis tools that run on the build machine and fail the build for violations.”

Code Review for the Important Stuff

The author lists an example checklist for a code author:

  • Does my code compile without errors and run without exceptions in happy path conditions?
  • Have I checked this code to see if it triggers compiler or static analysis warnings?
  • Have I covered this code with appropriate tests, and are those tests currently green?
  • Have I run our performance/load/smoke tests to make sure nothing I’ve introduced is a performance killer?
  • Have I run our suite of security tests/checks to make sure I’m not opening vulnerabilities?

The author lists an example checklist for a code reviewer

  • Does this code read like prose?
  • Do the methods do what the name of the method claims that they’ll do? Same for classes?
  • Can I get an understanding of the desired behavior just by doing quick scans through unit and acceptance tests?
  • Does the understanding of the desired behavior match the requirements/stories for this work?
  • Is this code introducing any new dependencies between classes/components/modules and, if so, is it necessary to do that?
  • Is this code idiomatic, taking full advantage of the language, frameworks, and tools that we use?
  • Is anything here a re-implementation of existing functionality the developer may not be aware of?

I chose this resource because it had very useful information on code review, which ties into QA. I feel the content of the article is very informational and useful to my future career. It is a good starting point for making sure you have thoroughly checked the quality of your code and automated tests are only going to increase in use, so it makes sense to automate what you can.

The post Creating Your Code Review Checklist appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Learning more on Design Patterns

So for this week I have decided to read “Brief Introductions to Design Patterns” from the Technical Blog by Future Processing. The reason I have chosen this blog is because I want to have a simple, clear understanding of the design patterns. It will help in which pattern should I utilize mostly for the rest of the patterns to implement easily after using it.

This blog post basically goes over selected patterns using the division that was proposed by the Gang of Four. The division goes from Creational patterns, Structural patterns, and Behavioral patterns. For creational patterns, they are supposed to prevent from occurring problems and introduce more control over creating objects. The three selected patterns from Creational are Singleton, Factory Method, and Abstract Factory. Singleton provides global access to at most one given class references, Factory Method provide an interface to generate objects, and Abstract Factory provides an interface for creating groups of objects without exact implementation. For Behavioral patterns, they are meant to introduce flexibility to solutions connected with inter-objects communication. The two selected patterns from Behavioral are Observer and Strategy. Observer is used to inform the group of objects to change the state of another specific object while Strategy is used to isolate algorithms, encapsulate them, and make them interchangeable. Structural patterns are to facilitate the operation and design applications through finding an easy way to realize dependencies between entities. The two selected patterns from Structural are Facade and Adapter. Facade is a simple pattern that makes code more legible and comfortable to use by stitching intricate references. Adapter seems similar to Facade, but is to introduce a new interface that hides the previous one.

Based on the contents of this blog, I would say this was a very intriguing read on the take of the design patterns. The author provided some UML diagrams and code written in a variety of programming languages to show each of the differences from the patterns. It was simple and easy to follow once looked closely. What I did before to understand the design patterns was that I tried to stick with only one programming language which was Java and implement each pattern in a way to utilize in future practice. It has helped me understood some of the patterns that was confusing at first with glance of the UML diagrams.

What I learned from this blog about certain design patterns is that the Singleton pattern should not be used too carelessly as it breaks two principles of SOLID and is problematic when implementing in multi-threaded environment. The idea I got from this blog is that while Singleton Pattern might be helpful in some ways, it is not what should be used every time before utilizing the other patterns.  For future practice, I shall try to use the Façade Pattern more often as it will help in making better designed API and will give a better start that the other patterns can be utilized easily.


Link to the blog:

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-11-20 21:07:22

The article this blog post is written about can be found here.

I decided this week to research the Law of Demeter, also known as the principle of least knowledge. I chose this article specifically to write about because it provides a source code example in Java, it gives examples of the sort of code that the Law of Demeter is trying to prevent, and it explains why writing code like that would be a bad idea.

The Law of Demeter, as applied to object-oriented programming, is a design principle consisting of a set of rules about which methods an object should be able to call. The law states that an object should be able to call its own methods, the methods of arguments that are passed to the object as parameters, the methods of objects created locally, the methods of objects that are instance variables, and the methods of objects that are global variables. The general idea behind it is that objects should know as little as possible about the structure or properties of anything besides itself. More abstractly, objects should only talk to their immediate friends, not to strangers. Adhering to the Law of Demeter creates classes that are loosely coupled, and it also follows the principle of information hiding.

The sort of code that the Law of Demeter exists to prevent are chains of function calls that look like this:


The article explains that this is a bad idea for several reasons. ObjectA might get its reference to ObjectB removed during refactoring, as ObjectB might get its reference to ObjectC removed. The doSomething() methods in ObjectB or ObjectC might change or get removed. And since your classes are tightly coupled when you write code like this, it will be much harder to reuse an individual class. Following the law will mean your classes will be less affected by changes in other classes, they’ll be easier to test, and they will tend to have fewer errors.

If you want to improve the bad code so it adheres to the Law of Demeter, you need to pass ObjectC to the class containing the original code in order to access its doSomething() method. Alternatively, you can create wrapper methods in your other classes which pass requests onto a delegate. Lots of delegate methods will make your code larger and slower, but it will also be easier to maintain.

Before reading this article, seeing a chain of calls like that probably would have made me instinctively recoil, but I wouldn’t have been able to explain exactly what was wrong. The bad examples given in this article clarified the reasons why code like that is weak. The article also gave me concrete ways I can follow the Law of Demeter in future code.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Blog 6

Soft Qual Ass & Test

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.