What exactly is Kanban?

Kanban in Japanese literally means billboard/signboard. It is designed to help you be agile, visualize your work and maximize efficiency.

The easiest way to understand Kanban is to imagine it like a water pipe, they have water going in and out. Similarly, Kanban has tasks coming in and going out through each step of the workflow(e.g. Todo, Doing, Done).

Just as water pipes have a limited amount of water that they can allow to go through at a time, Kanban has that as well. Using Kanban we can limit the number of tasks that goes into each step of the workflow. Also, Kanban helps us visualize our work and break it down into a prioritized list of tasks instead of just one big task which would then promote procrastination to our brain, and our brains tend to quite easily fall into that trap.

From my personal experience and from what I have read from others, using Kanban for managing our to-do list is a great idea and has many benefits. Let us go through them together.

Helps us overcome procrastination

By breaking our work into smaller tasks, we overcome procrastination.

Procrastination tends to happen when our brain sees some task as a complicated and time-consuming task. One of the ways to minimize our exposure to procrastination is to break our tasks into smaller, meaningful tasks. By doing that, our brain is tricked into thinking that each task is a simple and does not consume time that much, which as a result makes no sense to procrastinate, why keep being worried with a task when it literally takes minutes to be done?

Breaking the tasks into smaller, meaningful pieces is beneficial even if we do not use Kanban.

Makes prioritization very easy

After breaking down each task, we need to prioritize the tasks.

This step is very important because we need to know which task to move from Todo/Backlog to In Progress/Doing. Instead of just picking randomly, we need to follow a procedure to make sure that the most important tasks are done first, so that if we do not achieve to complete every task, we will be left with some less critical tasks.

Visualizes the work we have to do

After you break down each task and have a plan of what needs to be done, it will be very easy for you to see what your current status is, what you have completed and what are the upcoming tasks. However, this tends to be overwhelming, so that’s why we need the next benefit.

Improves focus

Limit WIP(Work in Progress) in DOING Column. This column would have a limited number of tasks to improve our focus. KANBAN is like a pipe, only accepts a limited number of tasks as input(into DOING) and as a result it gives the finished tasks, which are better in quality because you are more focused while doing them, and also you have prioritized the tasks, so this minimizes the risk of procrastination and gives you a feeling of success when you see all those important tasks being completed.

Helps us find a balance

Avoid overload by keeping WIP limit very low, so that you don't feel overwhelmed with the amount of tasks you have to do, but you also want to find a balance between overloading yourself and not doing the work you are expected to do. Personally, I like to keep only one task in the DOING column, so that I only focus on one thing at a time. If there is something I need to do urgently, I add that to DOING, and move the current task into the top of the TODO list(which has tasks ordered by priority).

Example Board

A great board that helped me start using Kanban for my daily life is this:
https://trello.com/b/lZmvFcpe/cause-if-anyone-can-tash-kanban
It has 6 columns: Backlog(Work), Backlog(Personal), Prioritized(This Week), Doing, Done.

• Backlog(Work) contains a prioritized list of planned work-related tasks
• Backlog(Personal) contains a prioritized list of planned personal life-related tasks
• Prioritized(This Week) contains a list of tasks that are taken from the backlog and are planned to be done within a week
• Doing contains only one task at a time which is in progress
• Done contains all the tasks that are done

From my experience using this board as a template, I find that the Done column tends to get populated quite quickly, so I added another column for the older Done tasks.

Of course I could just archive the cards that are done, but having many tasks in the Done column gives you a great sense of achievement and motivates you to move all your cards to that column, and we should use every opportunity we get to trick our brain into working harder!

References

https://kanbanize.com/kanban-resources/getting-started/what-is-kanban/

Feel free to respond if you have anything to say or you can reach out to me privately on Twitter(@KelmendiDhurim) or via email(dhkelmendi@gmail.com).

Last but not least, make sure to follow me here on Medium so that you do not miss new stories I publish.

Thank you for your time!

Personal Kanban was originally published in Remote Engineering Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article aims to give a solid explanation of SOLID Principles and give some insight on their benefits and potential issues when applying them. Let’s go through each of them briefly.

S — Single Responsibility Principle(S.R.P)

A class should have one, and only one, reason to change.

When requirements change, this implies that the code has to undergo some reconstruction, meaning that the classes have to be modified. The more responsibilities a class has, the more change requests it will get, and the harder those changes will be to implement. The responsibilities of a class are coupled to each-other, as changes in one of the responsibilities may result in additional changes in order for the other responsibilities to be handled properly by that class.

• What is a responsibility?!

A responsibility can be defined as a reason for change. Whenever we think that some part of our code is potentially a responsibility, we should consider separating it from the class. Let’s say we are working on a project that helps people become more active in their community, and the system needs to have social media integration. It would be a good idea to separate the social media integration responsibility from the other parts of the system, as we should always be prepared for external changes.

If you want to see SRP in action, check out this article about PORO(Plain Old Ruby Objects), which explains how SRP is implemented in Ruby on Rails applications to make the codebase scalable and maintainable.

Have you ever heard of something being Open and Closed at the same time?! Well, I certainly have, so lets take a look at it together.

O — Open-Closed Principle

You should be able to extend a class’s behavior, without modifying it.

This principle is the foundation for building code that is maintainable and reusable.

Robert C. Martin

How can something be open and closed?! A class follows the OCP if it fulfills these two criteria:

• Open for extension

This ensures that the class behavior can be extended. As requirements change, we should be able to make a class behave in new and different ways, to meet the needs of the new requirements.

• Closed for modification

The source code of such a class is set in stone, no one is allowed to make changes to the code.

How do we achieve this?

Through abstractions. In order to be able to extend the behavior of a class without changing a single line of code, we need to make abstractions. For example, if we had a system that works with different shapes as classes, we would probably have classes like Circle, Rectangle, etc. In order for a class that depends on one of these classes to implement OCP, we need to introduce a Shape interface/class. Then, wherever we had Dependency Injection, we would inject a Shape instance instead of an instance of a lower-level class. This would give us the luxury of adding new shapes without having to change the dependent classes’ source code.

How do we know whether to make Shape a class or an interface? For that, we’ve got the Liskov Substitution Principle, which tells us when inheritance is suitable. Let’s take a look, shall we?

L — Liskov Substitution Principle

Derived classes must be substitutable for their base classes.

What is wanted here is something like the following substitution property: If
for each object o1 of type S there is an object o2 of type T such that for all
programs P defined in terms of T, the behavior of P is unchanged when o1 is
substituted for o2 then S is a subtype of T.

Barbara Liskov

Let’s visualize the definition with a case study. Let’s say we have a Rectangle class, and we have a class that extend it, Square. Let’s also say that Rectangle has two methods, setWidth and setHeight, which, well, set the width and height of the rectangle respectively.

The problem is that the behavior for the two methods differs between the Rectangle and the Square classes. The reason for that is that a Square, by mathematical definition is a Rectangle with equal height and width. So, the two methods will change the same value, whereas for the Rectangle, they will change the width and height respectively, which are different values from each other.

When we are using abstraction(Open-Closed Principle), we want the methods to behave the same for each derived class, and not differently. In this case, we can clearly see that a Square class should not be extending the Rectangle class, because the behavior of the inherited methods differs.

• The solution

As Robert C. Martin suggests here, we should design by contract. What this means is that each method should have preconditions and postconditions defined. Preconditions must hold true in order for a method to execute, and postconditions must hold true after the execution of a method.

…when redefining a routine [in a derivative], you may only replace its
precondition by a weaker one, and its postcondition by a stronger one.

Bertrand Meyer

This is a clear and to-the-point explanation of this definition that I found online:

1. Assume your baseclass works with a member int. Now your subtype requires that int to be positive. This is strengthened pre-conditions, and now any code that worked perfectly fine before with negative ints is broken.
2. Likewise, assume the same scenario, but the base class used to guarantee that the member would be positive after being called. Then the subtype changes the behavior to allow negative ints. Code that works on the object (and assumes that the post-condition is a positive int) is now broken since the post-condition is not upheld.

Robert C. Martin suggests that it is helpful to document(comments) the preconditions and postconditions for each method.

I — Interface Segregation Principle

Make fine grained interfaces that are client specific.

Clients should not be forced to implement interfaces they do not use.

Robert C. Martin

In other words, it is better to have many smaller interfaces, than fewer, fatter interfaces.

For example, let’s say we had an interface called Animal, which would have eat, sleep and walk methods. This would mean that we have a monolithic interface called Animal, which would not be the perfect abstraction, because some animals can fly. Breaking this monolithic interface into smaller interfaced based by role, we would get CanEat, CanSleep and CanWalk interfaces. This would then make it possible for a species to eat, sleep and for example fly. A species would be a combination of roles, instead of being characterized as an animal, which would not necessarily be the best description. At a larger scale, microservices are a very similar case, they are pieces of a system separated by responsibilities, instead of being a great monolith.

By breaking down interfaces, we favor Composition instead of Inheritance, and Decoupling over Coupling. We favor composition by separating by roles(responsibilities) and Decoupling by not coupling derivative classes with unneeded responsibilities inside a monolith.

D — Dependency Inversion Principle

Depend on abstractions, not on concretions.

A. High level modules should not depend upon low level modules. Both should depend upon abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

Robert C. Martin

Let’s say we have a system that handles authentication through external services such as Google, GitHub, etc. We would have a class for each service: GoogleAuthenticationService, GitHubAuthenticationService, etc. Now, let’s say that some place in our system, we need to authenticate our user. To do that, as mentioned, we have several services available. To be able to make use of all the services, we have two possibilities: We either write a piece of code that adapts each service to the authentication process, or we define an abstraction of the authentication services. The first possibility is a dirty solution that will potentially introduce technical debt in the future; in case a new authentication service is to be integrated to the system, we will need to change the code, which as a result violates the OCP. The second possibility is much cleaner, it allows for future addition of services, and changes can be done to each service without changing the integration logic. By defining a AuthenticationService interface and implementing it in each service, we would then be able to use Dependency Injection in our authentication logic and have our authentication method signature look something like this: authenticate(AuthenticationService authenticationService). Then, we could authenticate by a specific service like this: authenticate(new GoogleAuthenticationService). This helps us generalize the authentication logic without having to integrate each service separately.

By depending on higher-level abstractions, we can easily change one instance with another instance in order to change the behavior. Dependency Inversion increases the reusability and flexibility of our code.

Benefits

Following principles always has benefits. It is no different in software engineering. Following the SOLID Principles gives us many benefits, they make our system reusable, maintainable, scalable, testable and more. For more about the benefits of each of these principles, make sure to read Uncle Bob’s articles.

For a fun and simple explanation of the SOLID principles, check out these photos.

Feel free to email me if you have any questions, challenging opportunities, or you just want to say hi.

Finally, be sure to follow me so that you do not miss any new stories I publish.

SOLID Principles made easy was originally published in Remote Engineering Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many times, you do not want to actually let the users delete an entity. Rather, you want to soft delete it, or archive it, so that users can find it in the `trash`. There are several ways you can achieve this, and let’s see how you can achieve it while working with the Laravel framework.

Without any specific framework/language in mind, you can implement this by adding a boolean column archived in the desired table, and then fetch rows based on the value of this column. Easy, right?

Now, if you are using the Laravel framework, it provides out of the box support for soft deletes(i.e. archive). First of all, you need to have a deleted_at column in your table. Then, you can use it by simply adding use Illuminate\Database\Eloquent\SoftDeletes; and then, inside the Model use SoftDeletes; which makes the model use the SoftDeletes trait, fetching all the helpers that it provides. Some of the helpers worth mentioning are withTrashed, onlyTrashed, which help you fetch all the rows, including the trashed ones, or only the trashed. By default, if none of the mentioned helpers are used in the query, it will only fetch the rows that are not trashed.

After using the trait, you need to define a route, a controller method, and a view for displaying the archive. This is pretty straightforward, as you woud add Route::get('/entity_archive', 'EntityController@archive');. You can organize this part as you wish. Then, at the controller method, you should query the model, and remember to use onlyTrashed() like below.

Now, you will be able to view only the archived rows from your entity. By default, when using $entity->delete();, Laravel will soft delete the entity row. It makes it possible to restore an archived row by running $archived_entity->restore();. If you want to delete permanently, you can run $entity->forceDelete();.

And that wraps it up. That's how easy it is.

Feel free to email me if you have any questions, challenging opportunities, or you just want to say hi.

Finally, be sure to follow me so that you do not miss any new stories I publish.

Creating an archive on your application easily was originally published in Remote Engineering Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

While I was developing a Laravel web application, as a feature, I had to implement the tree view of an Eloquent Model. What this means is that each model instance can be a parent, sibling or a child of another instance of the same model.

Normally, this would be implemented by adding a field parent_id in the corresponding table, which would hold the id of the parent. This is the easy part. The hard part, however, is implementing helper methods which fetch the parent, sibling(s), and child/children. Thankfully, there is a package which handles all this for you. It is called Laravel NestedSet. This package gives you many helpful helper methods out of the box, such as all the way from saving a node, to fetching a node as a tree.

Someone might say: Why is this special? Well, even though PHP, and Laravel have a huge community, developers do not always find packages like this, which give out of the box implementation of functionality. Comparing it to the Ruby, and especially the Ruby on Rails community, the PHP community falls a bit short of this aspect. Because of this, Ruby on Rails developers live a happy life, mostly configuring gems, which are packages in the Ruby world.

While having many benefits for developers, I see this as a threat. Why? Because it removes the challenging aspect of development, and makes it easy to implement almost anything using implemented gems or packages. This is great for developers, as they can come out with results really fast. But, while making their job easier, it also makes development seem like a job that only involves package or gem configuration, and it is not at all true. Software development involves a lot of problem solving and decision making, and these are the skills that make a great developer.

Personally, if a job is not exciting and challenging, I will not be attracted to it. While developing web applications with some frameworks, I find that I only have to find what package to plug in, and what configuration I need to make. Of course, this is not all there is to implementing a feature, as every software program has its special functionalities, which also brings new challenges for developers.

So, whether you like more challenges, or more configurations, you will have to choose between a community like the Ruby on Rails’, or one like Golang’s, which while being a relatively new language, has many packages, but also brings many challenges while developing. If you want to have many packages that make your life easier, I would not prefer to use a language like, say Elixir, which is a new language with quite a small community. But, if you prefer challenges more than having tons and tons of packages, you will choose regardless of the community.

This is not a rant against any community/language; rather it is an insight on how day-to-day development looks like when you are a part of a community which offers many packages, compared to other communities which do not.

I like using packages occasionally, especially when time deadlines are approaching. But, I prefer to implement things on my own, given that I have the time luxury to do so. The reason behind this is that I want to keep myself excited and learn all the time, which one can only do if one digs deeper and gets one’s hands dirty.

Feel free to email me if you have any questions, challenging opportunities, or you just want to say hi.

Finally, be sure to follow me so that you do not miss any new stories I publish.

Code packages are great, but they are also dangerous was originally published in Remote Engineering Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Being the most adopted Version Control System (VCS), Git makes contributing to open-source and teamwork as easy as a walk in the park. If you are a developer, you should definitely know it.

As software developers, many people tell us that we have to learn X or Y. This can quickly get overwhelming for new developers who are seeking for advice. The advice we get is not always right. However, there are cases when a technology is a must, and you will find that the majority of developers use it and advocate learning it. Version control systems (VCS) are such a technology. Everyone is using them (if not, they definitely should). Git is one of the most used version control systems. Let’s dig deeper into VCSs and Git and see why they are considered a must when developing.

The problem

If you have developed applications without using VCS, you most probably have had bad experiences synchronizing the files between the team members. I myself have had this problem, and I used to name files with a version number so that I differ between the files.

Besides looking bad, it also has many usability problems: finding the version you need, remembering the changes you made in each version, and sharing the files with the team. As a solution, there have been many systems which intend to make this process easier and safer. These systems are called Version Control Systems.

Version Control System(VCS)

For solving the mentioned problems, and many more, different types of VCSs were developed. Let’s talk about them briefly.

Local VCS

This type of VCSs enables users to store a history of the changes they made to their files locally, eliminating the problems regarding file history, but still leaving a big problem unsolved: the team collaboration.

Centralized VCS

Centralized VCSs solve the problem of team collaboration by centralizing the history and storing the versioned files in a server, where clients can access the files and get the latest snapshot of the history. For a long time, this has been the go-to VCS. While it offers many advantages compared to Local VCSs, it still has a major issue, which is also found in Local VCSs: there is a single point of failure — if the central server fails, the whole file history is gone for good.

Distributed VCS

Distributed VCSs bring all the good parts of the Centralized VCSs, and more. They eliminate the single point of failure by sharing the file history with each team member and not only get a snapshot, but get the full mirror of the repository. If any server dies, the history does not die with it, it can be restored from the clients, who have a full mirror of the repository (i.e. a full backup of the data). Being distributed, they offer a great possibility of developing in a non-linear manner and choosing one of several workflows.

Git

Git is a distributed VCS which was born as a need of the Linux development team. It is an open-source project started by Linus Torvalds (who also started Linux).

Getting Started with Git

**Disclaimer**

This will not be an in-depth tutorial about git, it will rather be a short tutorial about the basic git commands.

Starting the work

• If you are starting a new project, or have an existing project that you would like to add to git, run git init inside the project’s folder.
• If you want to work on a project which is already on git, get the git repository URL, and run git clone UR.

Git directories

Git organizes your repository in three directories: Working Directory, which contains the files, Index, which is the staging area and HEAD, which points to the last commit.

Git add & commit

To send your changes in a file to the Index, you run git add fileName. After adding all the changes, if you want to send them to the HEAD, you run git commit. But, the changes are still in your local repository.

Pushing your changes

To push the changes that you’ve committed, you run git push origin branchName.

Branching (GitHub Workflow)

Branches, as the name suggests, allow developers to work on different features independently. They help developers organize their workflow with ease. One of the popular workflows is GitHub workflow, which suggests that each time you want to work on a feature, you create a branch, commit the changes, and then merge the branch to the master branch. You create a branch by running git checkout -b branchName, which is a shortcut, explained here.

Staying up-to-date

Since git gives each person involved in the project a local copy of the repository, this copy has to be updated after someone pushed to the remote repository. You do this by running git pull. At times, this process is where problems may rise. As many people may be working on the same files, there may be some conflicts, which you will have to resolve. Resolving a conflict can be explained as telling git which changes to keep. You will then have to add and commit the resolved conflicts.

Log

To view the history for your repository, run git log.

Discard changes

If you have made some changes that you are not proud of, you can discard them by running git checkout fileName; you can discard ALL the changes by running git checkout ., which you should only use when you are sure that you want to discard all the changes. If the changes are in the Index (i.e. you ran git add fileName), you can run git reset HEAD -- <directoryName>, which will remove the directory from the staging area(Index), but it will not discard the changes (you will have to run git checkout).

Advantages

• FOSS(Free Open-Source Software)

Git is an open-source and free software, meaning that not only you are permitted to use it to fulfill your needs, but you can also configure it to your preference.

• Fast and small

Being distributed, it does not interact with the central server all the time, resulting in a very fast and efficient VCS. Although it mirrors the central repository locally, the clients’ file size is quite small

• Distributed VCS

Being a Distributed VCS, Git ensures that no data is lost, as the central repository is mirrored in each client, which enables restoring files from the client to the central server.

• Secure

For naming and identifying objects in its database, Git uses SHA1, which is a cryptographic hash function. Each file and commit has a checksum, which ensures that there is no change from the Git database without Git being aware of it.

• Flexible

This advantage comes as a result of Git being a Distributed VCS. Git enables users to choose whatever workflow they prefer, be it centralized, feature, git, forking, or other.

Git hosting services

The most popular service is GitHub (find me on GitHub: DhurimKelmendi) where you can find many interesting open-source projects. Alternatives to GitHub include Bitbucket, GitLab, etc.

Helpful learning resources

There are many awesome sites that help you learn git. Here are some of them:

• You can find many useful articles in the learn-anything site.
• git website
• git’s Getting Started Book
• Atlassian’s git tutorial
• GitHub’s interactive tutorial
• Codecademy’s free course
• Udacity’s free course
• GitHub Workflow by GitHub
• Another tutorial by Atlassian
• Git cheatsheet by Atlassian

The next step

After learning git, make sure you contribute to open-source projects and help the world while coding.

Feel free to email me if you have any questions, challenging opportunities, or you just want to say hi.

Finally, be sure to follow me so that you do not miss any new stories I publish.

Git — the superstar version control system was originally published in Remote Engineering Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

A while ago, I came across Dash, which is a great piece of software which makes browsing the documentation really easy. It is a native application, and unfortunately only for MacOS. I use Ubuntu(16.04 LTS) as my daily driver for developing with Ruby(Ruby on Rails) and PHP(Laravel).

There are plenty of really cool applications on Linux, but I think that MacOS makes the developers’ life easier by abstracting some functionalities and some dependencies. As a result, I have found that many times, it is harder to install an application in Linux when compared to MacOS. As I see it, this comes as a result of the user base of both the OS, Linux being the OS for the more experienced developers, who like to handle all the details themselves, and MacOS, which can be considered as the OS for the hipsters, who do not want to deal with all the nitty-gritty details. And as a Linux user, I can’t blame developers for choosing MacOS, because most of the time, you do not want to ‘waste’ your time handling the dependencies and you just want to get things done.

While working with a new technology, we as developers often find ourselves surfing through the pages of the documentation for that technology. This process can be tedious at times, as not all the documentations are well written. This is where Dash comes handy. It makes it easy for developers to go through the documentation, or just search through it. And while finding out that it is a great application, I also found out that it does not work for me, because I use Linux. Luckily, I came across Zeal, which is a Linux and Windows alternative of Dash. It uses Dash’s Docsets, and we can say that it is based on Dash, providing its service to Linux users as well. FYI, Dash is also a Code Snippet Manager, beside being a documentation browser.

I strongly encourage all developers to check out Dash(if they use MacOS), or Zeal(for the Linux guys). I must say that I find it very useful when I want to quickly check out some detail in the documentation, and I do not have to go to a site, and depend on having an internet connection.

As for Windows, I honestly do not recommend it for developers, unless they are developing applications for the Microsoft technologies. I strongly encourage them to keep Windows for gaming, and use Linux/MacOS for development.

This is just my two cents on this topic, and I would really appreciate your opinion on the matter, so feel free to respond below, or tweet at me.

Feel free to email me if you have any questions, challenging opportunities, or you just want to say hi.

Finally, be sure to follow me so that you do not miss any new stories I publish.

Zeal — The Dash alternative for Linux and Windows was originally published in Remote Engineering Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is it? Should we do it? When should we do it? How do we do it? The manager does not like it… Let’s talk about these issues one at a time.

Human beings are prone to mistakes. Because of that, we need a phase to review and improve our work, so that the final product is of high quality. In software engineering, this phase is called refactoring.

This article will be an explanation of refactoring in software engineering. We will be elaborating theoretical terms, and then give an example of refactoring from real-life. But, no explanation is complete without clarifying the benefits and challenges that the subject brings, so we will do that too.

Let’s get to it, shall we?

Definitions

The theoretical concepts mentioned in this article will be extracted from the real experts; Refactoring: Improving the Design of Existing Code book and several articles in the IEEE Software Magazine, Issue 6, 2016 which focuses on Refactoring.

One of the most important traits of a software product is that it is easy to upgrade in the future (maintainable). To achieve it, developers spend a lot of their time during the software process designing the system to be maintainable. But, as humans, developers are prone to mistakes. So, it is crucial that we leave some time after implementing the design (software, not graphic design) to improving the system.

“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.”

— Martin Fowler

Based on several articles from IEEE Software, we can say that refactoring is a very important phase in the software process, and a core practice in agile methodologies (read more) and especially in Extreme Programming (read more).

It is considered as an implicit component of agile development, where developers are expected to continuously improve the code quality (read more). Another case where refactoring is required is when software requirements evolve, and the developers need to adapt the system (read more).

The need to refactor

How do we now if we need to refactor? We determine the need for refactoring based on code smells, which are best described by this quote:

“If it stinks, change it.”

— Grandma Beck, discussing child-rearing philosophy

Let’s see some of the code smells that Martin Fowler, Kent Beck and other authors of the book Refactoring give us:

• Duplicate Code

As the name suggests, this is the case when you end up with the same piece of code in several places. That is duplicate code. This can be fixed by extracting the code and turning it into a method, and then calling that method instead of copy-pasting the code. This solution is known as Extract Method.

• Long Method

In this case, we have a long method which is composed of many implicit methods, that is, when we have many different processes being completed inside a single method. Most of the time, we can use Extract Method to, well, extract the implicit methods and make them real methods, and this way we end up with a much more decomposed method with a clearer purpose.

• Large Class

This smell breaks the Single Responsibility Principle (SRP); the ‘S’ in the SOLID principles. This principle states that each class should only have one reason to change, which means it should only have one responsibility. And when we have a large class, that means it has more than one responsibility, which is bad, because it makes the purpose of the class unclear. To follow the SRP, we use the Extract Class, where one class plays the role of two classes, or Extract Subclass, where a class has features that are used only in some instances.

There are more code smells, and if you are interested, we definitely recommend the Refactoring book.

But, should you refactor every time you encounter code smells? Here is what Martin Fowler tells us:

Smells don’t always indicate a problem. Some long methods are just fine. You have to look deeper to see if there is an underlying problem there — smells aren’t inherently bad on their own — they are often an indicator of a problem rather than the problem themselves.

— Martin Fowler

When?

Again, as most of the concepts presented in this article, we will be referring to the Refactoring book, from where we can also get the when of refactoring. The book recommends that refactoring is done continuously, in short bursts rather than specifying a certain time during the work process only for refactoring. Also, we do not decide to refactor, it comes as a result of having to do some other task.

Cases when we should refactor include:

• The rule of three

Three strikes and you refactor. — Martin Fowler

That means, you have to refactor after you duplicate something twice, because the first time you duplicate is tolerable, but when that is repeated, this immediately shows that the duplicated code should be refactored (see above for tips on how to do it).

• When we add a function

This is the most common case, when we have to add a new functionality to the system. Refactoring in this case helps us understand the system and the other thing is that we might not appreciate the design choices we see, so we decide to refactor; making the addition of the feature a straightforward process.

• When we are fixing a bug

Again, refactoring in this case helps us understand the system and that helps us find the bug. Bugs are indicators that we need refactoring, because if we understood the code, we would not have introduced a bug.

• When we are doing a code review

Instead of giving tips on how to improve the code, Martin Fowler suggests that we actually implement the changes; in other words, we refactor. This gives the code review concrete results and the proposed solutions are not abstract, rather they can be seen and examined instead of being imagined.

Benefits

Refactoring does not fix every defect in software, but it definitely helps improve many aspects of the software.

• Improves the system design

Software, after some time, will start to decay. To avoid it, we do refactoring, as it keeps our code healthy and in good shape. Having poorly designed software may be good in the short-term, but it definitely has a long-term effect; this effect is called technical debt. Basically, it tells us that if we make cheap and quick choices instead of implementing the best practices, they will hunt us down in the future. If we take an analogy with dish washing, the technical debt would mean that we do not clean the dishes today, but leave them for tomorrow. This is not a big problem if we do it sometimes, but if we always do it, our kitchen will be a real mess, which would look something like the picture below, or worse?!

Refactoring helps us clean our kitchen (analogy with software), keeping it clean and easy to work with in the future.

• Makes the system easier to understand

Refactoring helps us understand the system, because it makes our code readable, helping others understand our code. And another way refactoring improves understandability is when we are looking at unfamiliar software. Instead of looking at the code and trying to figure out what it does, we refactor it to fit our understanding and then test it to see if we understood it correctly.

• Makes bugs easier to be found

Logically, understanding the code makes bugs very easy to be found. So, refactoring also helps us find bugs. And, even though we might not be great at finding bugs, by having good habits as refactoring, we achieve better results.

“I’m not a great programmer; I’m just a good programmer with great habits.”— Kent Beck

• Software development process is faster

The most important benefit of refactoring is that it speeds up the development process. Although this might sound counter-intuitive, by understanding the aforementioned concept of technical debt, this makes a lot of sense. If we wash our dishes regularly, we avoid having a large pile of dishes to wash. The same goes for our software. If we refactor all the time, we will have a very low technical debt, which implies that we will spend time on developing software rather than fixing issues introduced from poor choices in the past.

Challenges

Even though we, as developers, want to refactor, we might face a challenge: the Manager (or the Client, if you are a freelancer). Because refactoring is time-consuming, convincing the manager to include it in the development process can be a very difficult task. Martin Fowler tells us that if the manager is tech-savvy, or genuinely quality oriented, we should convince them by showing the benefits of refactoring; that it saves time and improves quality, etc.

However, if the manager is one of the people who claims to be quality oriented, but is actually schedule oriented, Martin Fowler says that we should not tell them that we will be refactoring. It is our job to develop software as fast as we can, and if we need to refactor in order to achieve that, we refactor. After all, they are schedule oriented, so time will be their most valuable asset.

Real-life example with Laravel

Tired of theory? Alright, let’s see a real-life example of refactoring. This example will show the Duplicate Code smell, and fix it as suggested above, by Extract Method. It is rather a simple example, just to show the practical aspect of some of the concepts introduced in the article.

While developing a web application using the Laravel framework of the PHP language, I needed to parse the date of many objects in many views. I was using the great Carbon library for parsing the date, but the problem was that I started duplicating the code. Here’s what the code looks like, written using Laravel Blade templates:

Then, I decided to define a helper method and, as a result, eliminate the duplicate code. I defined a parse_date method, which took two parameters, the date, and the date format.

After defining the helper method, I removed the duplicate code and just called the method instead. This improves the code quality, because if I decide to change the way I parse dates, I do not have to make changes in many places, rather I just change the method. Here’s what the code looks like after refactoring:

Although it is a small change, it makes sense to extract duplicate code into a method and call the method instead. You can go one step further, by removing the format parameter and specifying the date format inside the method, but in our case, I needed to specify different formats for different models. As you can see from this simple example, refactoring is a very domain-specific process, which means that there is not only one correct solution, it all depends on what you want to achieve.

Feel free to email me if you have any questions, challenging opportunities, or you just want to say hi.

Finally, be sure to follow me so that you do not miss any new stories I publish.

Refactoring — From Zero to Hero was originally published in Remote Engineering Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.

Some terms tend to be very confusing to new programmers. From my experience, terms concerning testing, and especially TDD were those confusing and seemingly hard to understand terms. That was until I was reading a great book about System Analysis and Design by Craig Larman [1]. It described TDD and gave some benefits that it brings to developers. In this article, we will elaborate the definition of TDD, some of its benefits, some potential obstacles, and a real-life example of writing code by following TDD.

Let’s dive into definitions, shall we?

TDD is an agile software development practice which puts software testing as the first step toward completing the software development. Does this mean that we test the code before we write it? Yes! That is what TDD basically stands for. This is the software development process according to TDD [2]:

1. Write the test for a small unit of a desired functionality
2. Write the code that makes the test pass
3. Refactor the code(change the code internally, without changing its external behavior)
4. Repeat the steps above for the next desired functionality

For many, this is very non-intuitive, as we are supposed to first write the code, and only write the tests after we finish writing the code. Obviously, it has many benefits, which we will discuss below.

Benefits

TDD brings us the benefits of testing, and some more. These are some of the main benefits of the TDD to the development process.

1. Developers are forced to actually write the tests

To ensure that the system does what it is supposed to do, and does not do what it is not supposed to do, we write tests. As you can see from this definition, tests are very important, and yet many developers neglect writing them. By writing tests before writing code, developers are forced to test all their code [1].

To find out more about why developers avoid writing tests, read this great article written by Fatos Morina, a good friend of mine and a colleague at MozaixLLC.

2.The system design is clearer

By writing tests first, the developer will be thinking a lot about classes, and class methods, their names and their contract (signature, return type, parameters). This will help design the system and have a clearer view of each component of the system. So, while writing tests, the developer also makes design decisions, which will make writing code easier, as many design decisions have already been made while testing [1].

3. Programmer satisfaction

If we were to write our code first and then write the tests, we would not feel satisfied as much as we would when we write tests first, and then make them pass. This is a psychological aspect, and it should not be ignored, as it makes programmers like testing their code [1].

4. Test coverage is very large(if not 100%)

Test coverage is the percentage of code that is tested. Having a large test coverage has substantial benefits, some of which you can see below.

4.1. Maintainability

We can easily say that the most important benefit of testing is that it makes the system very maintainable. This means that it is safe for developers to refactor the code, because if you do not change the external behavior, the tests will pass [1].

4.2. Reliability

Large test coverage also makes the system reliable, because when one sees the large test coverage, he immediately assumes that the system works as it should (this can be said if we assume that tests are written correctly) [1].

Theory becomes clear when we put it in practice, correct? Let’s go and do just that with a real-life example from everyday development, which I actually developed following TDD myself.

A TDD Example in Ruby on Rails

We at MozaixLLC love working with Ruby on Rails, so that is the framework that this example will be written in. Rails follows the MVC (Model-View-Controller) architectural style, so we will be focusing on developing a Model. For writing tests, we will use RSpec, which is a great gem (library) for testing Rails apps (you can also use Minitest). Another gem that is used in this example is FactoryGirl, which is a gem for using objects as test data (i.e. simulating the creation of an object for testing purposes). We also need data, and there is a gem that does just the job for us, that is the Faker gem. For installing the aforementioned, please read the corresponding documentation.

Our task

We will define a Model (the M in MVC), more specifically a User model, which contains a name, gender, email, a field of study and a role. Following TDD, we want to make sure that the creation of the user goes as we want it to, so the system should check which fields are mandatory and not allow the creation if they are not specified. In short words, we will validate the parameters while creating a user, making sure that each user that is created has valid data.

To keep the example short and to the point, we will assume that the required field for the user is only the user’s name. Also, we will assume that we already generated the user model and controller using the Rails generator. Let’s do this!

Step 1: Write the tests

We are using RSpec, so we will need to define a model spec, which is used to describe the model behavior [3]. First, we create a Factory using FactoryGirl. That is done by creating a new file called users.rb in /spec/factories/. In that file, we define a new factory for users, and inside we give it the fake data generated by Faker. You can see the code in the picture below (yes, you guessed that right — I love cats :)).

Then, we we create a file called user_spec.rb inside the /spec/models folder. In this file we will define methods that test the behavior of the model according to the data that is passed during the creation. We first test for the success scenario, and then also test for the cases that we want it to fail(for example: if name is a required attribute, creating a user with no name should not be allowed). For this example, we will assume that only the name is a required attribute for a user(this system specific). You can see the code below.

Now, we have written all the tests that we need. Initially, the Rails model does not have validation, because it is specific for each application, so our tests will fail. We run the tests by going to our Terminal and running: rspec spec/models/user_spec.rb. You can see the output in the image below.

As expected, the tests fail. The error shows us that user creation is allowed even if name is set to nil. That is something we do not want to allow to happen. To fix this issue, we go to Step 2, where we will have to write the code that makes the tests pass.

Step 2: Write the code that makes the tests pass

In our example, making the tests pass will be fairly easy, because of the way the Rails framework is structured. We will simply go to the user model (user.rb) and add one line of code. And that line is: validates :name, :presence => true. This tells Rails that the name attribute should be present when creating a new instance of the user model object.

Let’s check if the tests pass. We run the same command in the Terminal, and get the result as in the image below.

Voila! There you have it! Now, we can say that it is safe to create users.

We can continue with the next step(Step 4), refactoring the code.

Step 3: Refactor the code

Refactoring is a process that alters the internal structure of a part of code without changing its external behavior [4]. In our case, this step is not necessary. In another scenario, this step, as the definition of refactoring suggests, would be to improve the quality of the code without changing its external behavior.
After completing all 3 steps, it is time to move forward, and that’s what step 4 is about.

Step 4: Repeat for the next desired functionality

After finally implementing the desired functionality, we pick the next desired functionality and start working with it from Step 1 and then continue the aforementioned steps.

We recommend TDD! But…

With all the aforementioned benefits, you should definitely try TDD. But, you have to consider that if you are a team, everyone should follow it, or you will end up breaking each-others code and not fixing it, and this would bring unwanted problems [2]. And if every member commits to it, you will have a great time doing TDD. Nobody wants to be this guy, right?

One of the obstacles of writing code is that it is hard to justify to the client, as it does not add any functionality. But, we simply have to show our clients that testing helps us write code and it makes the system maintainable and reliable. So, we just have to show them the benefits testing brings to us.

Feel free to email me if you have any questions, challenging opportunities, or you just want to say hi.

Finally, be sure to follow me so that you do not miss any new stories I publish.

References

[1] C. Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3nd Edition), Prentice Hall, 2005.

[2] The Art of Agile Development: Test-Driven Development, James Shore

[3] RSpec documentation

[4] Refactoring.com — Martin Fowler

What’s this TDD people talk about? was originally published in Remote Engineering Academy on Medium, where people are continuing the conversation by highlighting and responding to this story.