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.



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.

What is Model-Based Testing?

Link to blog:

There are many different ways to test software. This blog written by Nico Kicillof defines what model-based testing is and what it is used for.

Model-Based Testing is a lightweight formal method used to validate software systems. It is considered “formal” because it works out of a formal specification or model of the software system. It is “lightweight” since it doesn’t aim at mathematically proving that the implementation matches the specification under all possible circumstances. Here is an image below from the link:


(In the image above, Kicillof shows the diagram that illustrates model-based testing in a nutshell.)

The difference from considering a lightweight method from a heavyweight method is that it comes between sufficient confidence vs. complete certainty as Kicillof likes to put it.

The first step of the process is that it is important to know that the method starts off as a set of requirements that could be written from the development team, or you the developer. The next step is to create a readable model that shows all the possible behaviors of a system meeting the requirements that were given to you the developer. Keep the model manageable by creating the right level of abstraction. Kicillof says this because it makes sense to keep a model manageable. If a model isn’t manageable, then it is basically a bad model to use. It would be difficult to make edits or reconfigure your model if you run into a specific type of problem where your model doesn’t clearly highlight how to fix it.

Kicillof gives the example of model based testing through the use of Microsoft Spec Explorer. He explains that in Spec Explorer, models are written as a set of rules in the mainstream language of C# which makes it less difficult to learn in comparison ad-hoc formal languages.

Kicillof’s explanation on how model-based testing works made me understand the concept better than before. The image he provides, just like the one shown above, illustrates the process of model-based testing. The numbers near each part of the process in the image made it easy to follow. I chose this blog because I wanted to know a little more on model-based testing. I wanted to think on how it would be used in my future career of video game development since it is another great way to test software. Depending on what games I’ll be creating in the workplace, knowing model-based testing is important because I think it is an easier formal way of testing in comparison to other types of testing.

Determining Which UML Diagram to Use

Link to blog:

This blog gives an overview on choosing which type of UML diagram to use when it comes to designing software. Some software designers may encounter a problem where they’re coming to a choice on whether which UML diagram to use that is most efficient for a particular task given to them. I am one of those designers because sometimes, I come to a problem where I can’t decide on which UML diagram I should use.

First, there are 3 classifications of UML diagrams: Behavior diagrams, Interaction diagrams, and Structure diagrams.

Behavior Diagrams: 

These are types of diagrams that show behavioral features of a system. This includes activity, state machine, and use case diagrams. Examples of a behavior diagram would be an Activity Diagram and a Use Case Diagram. The activity diagram shows high-level business processes, including data flow, or to model the logic within the system. To simply put it, behavior diagrams, in general, breaks down processes into individual decisions, loops and chain of events.

Interaction Diagrams: 

Interaction Diagrams are a subset of diagrams which emphasize the interaction of objects. This includes communication, interaction overview, sequence, and timing diagrams. These diagrams fulfill the need of designing a system where there are complex relationships between code elements and provides a view on how the elements interact over time. Examples of interaction diagrams include Collaboration/Communication Diagram, Sequence Diagram, Interaction Diagram, and Time Diagram. 

Structure Diagrams:

Structure Diagrams show elements of a specification that are irrespective of time. This means that the elements are not affected by the nature of time. Examples of structure diagrams include Class Diagrams, Composite Structure Diagrams, Component Diagrams, Deployment Diagrams, Object Diagrams, and Package Diagrams. Structure Diagrams, in short, help break large projects or features into parts and specify which parts do what and how they interact within the system.

I chose this blog because I wanted to know the different types of diagrams within the three classifications of UML diagrams. I was aware of the three classifications of UML diagrams, but I didn’t know certain types within each classification such as the Deployment and Composite Diagrams within the Structure Diagram Classification. The author of the blog briefly highlighted each of the three classifications in detail with links pertaining to each of the example diagrams presented within each classification. This made it easier to understand how each example operated. It is important for me to understand the different classifications and their examples of diagrams because when it comes to programming video games, which would be my future career, I would have to implement and figure which diagram is necessary for each type of game design.

7 Ways to be an Efficient Software Tester

Link to blog:

Currently as a college student majoring in Computer Science, I made the decision that I wanted to do a concentration in software development instead of data analytics. This is because my passion is to become a video game developer. While learning on the concepts of how software is designed and tested, I wondered what would be the necessary fundamentals of being an efficient software tester besides learning all of the test cases, techniques and terminologies. In this blog written by Willie Tran, he explains the seven tips on how an efficient software tester should be.

First, Tran identifies that sometimes, testing software can be chaotic and relates it to those who have experienced it in working in the field.

Anyone who has been working in the field for any extent of time has experienced unreasonable lack of organization, poor scheduling, and daunting bug reports. Working through this mess is a task of its own. The best way to avoid this situation is to create order in your own habits. If you can create a common and consistent order for any work you touch, then you will set an example for your colleagues.”

Later, he highlights the tips that a software tester should do to be successful and efficient. These tips include organize everything, write detailed bug reports, write clear test cases, take part and communicate, ask yourself questions, be positive, and don’t test.

Organize Everything:

Creating an organize structure is important. When you create an organized structure to store all of the important details, it is easier to gather the relevant details and and perform the right testing strategy for the specific assignment you’ve been given.

Write Detailed Bug Reports 

Writing clean, detailed bug reports helps a lot, especially if you’re working in a team. This means that if you do this, your team will be able to understand more clearly on what it is you are writing and what bugs that you’ve identified in your project. Tran also adds that the three points that he stresses when it comes to writing these reports are:

  1. Write with detail
  2. Write with clarity
  3. Write for others

Write Clear Test Cases 

Don’t create long test cases. Try to simplify as much as you can to avoid problems and save time.

Take Part and Communicate

If you are working in a team, communication is key. This makes it so that testing is a team effort. If everyone knows what they are doing with each other as well as what their tests do, the testing process will be successful.

Ask Yourself Questions

Asking questions to your self is also important in a sense that you are checking yourself as you go to see what can you do to improve the tests and make them more efficient. Ask yourself what the tests are answering and doing.

Be Positive 

Testing with a positive attitude, especially in a team can be a huge factor and contribution. If your team sees that you have confidence in your work, everyone can become successful in the effort towards creating tests.

Don’t Test

Don’t test at all at the start. Once you make the tests, see what parts of the tests need improvement. Once you’ve done that, then you can test.

This blog by Willie Tran helped me understand on what an efficient software testing looks like. I picked this blog because I wanted to know more about what makes a software testing efficient besides knowing all the concepts of software testing. Knowing these tips will help me in the future to become a video game developer because most of the time, I’ll be working in teams when testing and creating game software. It will be important for me to communicate with my team and stay positive throughout the process when I work and test the softwares.

How to simplify your life as a Software Developer

Link to blog:

Throughout the time the I spent as an individual when it comes to coding, it takes me awhile to write the perfect code that I need for my college homework assignments. Sometimes, I would try and write code during my free time if I’m bored and implement a certain design that I would attempt to do. After I finish writing the code, I feel that I could’ve done it more quickly and efficiently without having to write so much code, or try to edit and fix the code so many times. I know that I have a tendency to repeat code and make it more difficult than it already was. As I’m trying to improve on being an efficient programmer I know that I have to stop myself from repeating code, and to keep it simple when it comes to a specific design pattern while fulfilling the necessary specifications.  In this blog written by Jonathan San Miguel, he identifies three principles to keep the life of a developer simple as possible. These principles are KISS, DRY, and YAGNI.

KISS: This acronym stands for “Keep it Simple, Stupid!” It basically means that try to keep your code clean and simple as possible. The simpler the code is, the simpler it’ll be to maintain it in the future in case if you want to edit it. Miguel also adds “avoid using fancy features from the programming language you’re working with only because the language lets you use them…use them only when there are perceptible benefits to the problem you’re solving.”

YAGNI: This acronym stands for “You Aren’t Gonna Need it!” This means that as the programmer, you need to focus on your specification and write the code that does that particular task without adding anything extra such as features you think you might need in the future.

DRY: This acronym stands for “Don’t Repeat Yourself!” Try and prevent yourself from writing code that is similar to others that you previously wrote. “Maintain the behavior of a functionality of the system in a single piece of code” as Miguel noted in his blog. This principle is useful especially in big applications where they are constantly maintained, changed, or extended by many programmers.

Among these three principles, I think I need to focus on the DRY principle the most because I do have the tendency to repeat code. I chose this blog because I felt that I needed to improve on writing code in general. If I can improve on that, I’ll be golden, and coding won’t be that much difficult for me. Jonathan San Miguel briefly explained that main points of each principle, which made it easy to understand. He also gave his advice on some of the principles and identified which principle was useful for certain circumstances. Understanding these three principles will help me in my future career as a video game developer because when I write the code for video games, I’ll have to condense and simplify as much as I can within the design so the software can run smoothly and efficiently. It will also help me save time to do other things with the code too.


Writing Better Tests with J-Unit

Link to blog:

In this blog written by Tobias Goeschel, he makes the arguement that in order to create a readable, maintainable, and useful test suite, we need to change our testing habits by focusing on behavior instead of implementation. Throughout his blog, he outlines some of the aspects that are needed to understand on how to write better tests with J-Unit.

The Value of Test Code

Goeschel states that writing fast, bug-free code is easy, if it’s not too complex, written once, and never touched again. In order to keep the code in high quality and maintainable as possible, you need tests because they allow you to makes changes in the design and architecture, without damaging the behavior. Well written tests will reveal how to access the API, what data is suppose to go in and out, what possible variations of an expected behavior exists, what kind of exceptions might occur, how the individual parts of the system interact with others, examples of a working system configuration, and what the customer expects the software to do.

Test Behavior not Implementation

Goeschel states that we create fragile tests if we set our testing focus on implementation. He then defines behavior as “the range of actions and mannerisms made by individuals, organisms, systems, or artificial entities in conjunction with themselves or their environment.” He specifically highlights that “range of actions and mannerisms” explicitly limits our view to what is observable from the outside. The tests will become more flexible if we refrain from disclosing internals and phrase the tests accordingly.

Group Tests by Context

In order to keep tests organized, we need to make sure that test methods should be grouped closely together. This is important because it helps find each single test, and to understand the behavior of the system much more quickly and easily.

Enforce a Single Assertion Rule

It is important that we try to limit each test method to a single assertion because it makes the code easier to read by assigning meaning to an anonymous block of assert statements.

Choose Meaningful Names

Applying variables and names to method names are important as well. This means that avoiding names like “a”, “test1”, “data” or anything like those names would be best.

Avoid Complex Configuration 

Avoiding complex or bloated configuration promotes fast tests. It applies to extensive use of dependency injection frameworks like Spring. A better way is to declare dependencies explicitly.

Avoid Test Inheritance 

If tests depend on each other, we make it harder and more tedious to change our system. We don’t want our tests to introduce additional dependencies to the code base we create. Inheritance introduces performance problems when working with JUnit.

Overall, Goeschel’s outline of writing better tests with JUnit was very clear and concise as he highlighted the six key actions when performing the JUnit tests. I chose this blog because I was a little unclear about the nature of how JUnit tests are done. This blog made me understand on how effectively test with JUnit. Understanding JUnit may help me in my future career field if video game development because it is another type of test that I can implement when I run and test my gaming software.