In this week’s blog we’ll talk about peer review, sometimes known as a code review or walkthrough.

What is it?

This is a thorough technical and logical line-by-line review of code. It is usually done in a small module, like a program, subroutine, object, method, etc. Sometimes a meeting can be held to discuss any issues related to the revision.

Why?

One of the main objectives of this process is to identify possible improvements and ensure that business requirements are met. 

Advantages, disadvantages

A lot of programmers complain about code reviews because they think it takes a lot of time. This may be true in some cases. Nevertheless, the drawbacks are usually outweighed by the benefits. The main advantages of this process are the following. First of all, it helps reduce bugs. In the long run, all that work will be significantly less if you find those bugs later on when the project is much advanced. That means less rework. There’s also more team communication. All of this helps to improve the team cohesiveness.

How does it work?

The methodology varies from company to company but most methodologys follow this 3 step process consisting of preparation, review, and follow-up. Here’s a look at each step.

Preparation

First, the code being reviewed must be complete, tested by the programmer, and in the programmer’s view, ready for the next step in the development life cycle. The code and other affected project components, such as documentation, test cases, a project schedule, or requirements changes must also be available to the review participants

Review

Reviews are conducted as needed, usually based on the rate of code output. The frequency of individual participation in a peer review depends primarily on the size of the programming team. A team of three programmers might include all three in every review. Larger teams might be able to rotate participation based on experience, skill level, subject matter familiarity, or site-unique factors.

Follow-up

Follow-up provides evidence of the meeting’s success and incentive for the continued use of reviews. The value of future reviews will be degraded if decisions are not enacted, and eventually programmers will view the process as just another waste of time. Follow-up is critical for all participants, especially the programmer. The documentation must be kept in a central location where anyone can reference it.

References

https://www.techrepublic.com/article/developers-guide-to-peer-reviews/

https://smartbear.com/learn/code-review/guide-to-code-review-process/

The customer is always right

The first step into writing good code is to make shure that you application works just like the customer wants it to. A good thing to remember is that the customer will never care about use cases and diagrams. They want to see your software acually doing stuff. So no matter how good your list of features and how pretty your diagrams are; if your software doesn’t do what your customer wants, those pretty diagrams aren’t worth anything.

Use case driven development

In this approach you focuse on one scenario in your use case diagram. You must code all the scenarios in one single use case.

Feature driven development

In this approach you start off with a specific feature and before moving on to the next one you complete the previous feature fully.

Which one do I like more?

I like the use case driven development more. I think the FDD is not optimal. I feel like most of the time, the features are all inter-connected. This makes it difficult to code. Of course, if your features are all independent from one another there’s no problem. What I think it’s that most of the time this is not the case. Maybe a few features are independent. But in my short experience the difficult and important features are always dependant on one another.

My take one this chapter

On this chapter they described a series of design principles. A lot of them were things that we kind of knew but it is really important to keep in mind and acknowledge their importance. The principle that I think it’s the most important one it’s the Don’t Repeat Yourself Principle (DRY). This one is the principle that I’ve broken the most.

My bad practices

When I’m breaking this principle I get the feeling when I’m doing it that it’s something bad. Most of the times it’s pure lazyness. I kinda know what I’m suppose to do to follow this principle. At first I tell myself that I just want to make things work and not worry about fancy things. But when I’m done with the things I wanted to “just work” I’m afraid that if I change something I might break my code. It’s a funny cycle I keep getting myself into.

An example

When I was doing a project with a friend that wasn’t from the school I broke the DRY principle several times. I had to connect to a database and I had to do it from several files. What I was wrongfully doing was that I wrote the information to connect to the database in every file. So I had an options object with the name of the database, password and username in every file. This is wrong in multiple levels. First of all, if I wanted to change the database the I connect to I would have to check in every single file for the name and change it. Secondly, the password was written in a lot of files of my project. If I upload my project to github it would be disastrous. In both cases I need to make a different file where I store the information and export it. And in every file that I need that information I import it. Finally, I would add this specific file to my .gitignore file, so that it is not uploaded to github.

What I should do

What I should strive to do is to start making things right from the very beginning. I think most of us programmers don’t do this because we sometimes feel like we’re not making any progress. It is difficult to do things right from the very beginning because we sometimes don’t know how.

Installing

Installing the game was easy. The problem is the Java jdk. In a previous project for my advanced database systems (it’s not “advanced” actually, it’s just non-relational databases) I had to modify my JAVA_HOME path in my system variables. After fixing that I ran the game with no problem.

Version

I played the XP and the waterfall versions.

Gameplay experience

I’ve never heard of a game like this so the experience was unique. I had no idea if what I was doing was good or not. I just went with my gut feelings. It was very fun because all of my classmates were struggling with it.

Difference between XP and waterfall

In the XP mode you had very little options so sometimes you couldn’t do anything except skiping to the next event. On the other hand, in the waterfall version, you had too much freedom. You could fire people, you could lower their wages and you could give them bonuses. I prefer the XP version because the waterfall version overwhelms me with choices.

I got a score of 25 in the XP version. I didn’t finish the waterfall version

If you already did the design and draw a class diagram in UML then you’ve already done the hard part. Now you have to follow what you diagram says.

Attributes

I can use the class diagram that I did for my mid-partial project for my Object Oriented Programming course. At the top we have the attributes of the class Contacto. To turn this into code you have to pay attention to the sign (this will be the acces type) and type variable. If there’s a minus sign you make the attribute private. If there’s a plus sign you make the attribute public. Then you just make it a String if it says that your attribute is a string.

Methods

The acces type rule still holds here so there’s no need to explain it again. What you have to look for is the values the method recieves and the return type. For java these things really matter but for languages like python or javascript it is not that important.

Relationships

You need to pay attention to the relationship between you classes becuase it directly affects the code. With inheritance you need to specify which class it extends from (if you’re in java). There are also composition and aggregation relationships, when there’s such a relationship you’ll need to create another attribute to the class.

Now, which programming language?

Mobile apps

Native

IOS – Swift

Android – Kotlin or Java

Hybrid – which Framework

React – Javascript

Vue, Angular – Typescript

Flutter – Dart

Back-end web development

Ruby

Javascript

PHP

Python

Server side application

Rust

Go

Games

For consoles

C++/C# along with the unreal framework

For desktop

C# along with the unity framework

Data Science/Machine Learning

Python

R

To create a static website

HTML CSS

Web app

Javascript

References

How to choose the best programming language for a software development project

From Models to code with no mysterious gaps – interview with Leon Starr