Here is where it all begins for me as an engineer.

Introduction

Since I was a kid I had this feeling of creating new things. It could be anything. But I had to create. I remember that my and I were always drawing some cards on paper and we created a new card game like Yugioh or Pokemon. I wanted my own card game, with my own rules and my own characters. I was only 7 or 8 years old.

Here is how we created a successful startup.

Doors were about to be opened

We had a dummy app, an idea, and determination. That was everything we needed to put our idea on paper and move forward. First, we needed to know how to connect mobile phones to doors, which seemed hard for us at the time. Some research led me to a weird thing called Arduino, an open-source electronics platform that allows us to interact with the physical world, read inputs like light sensors, and provide an output, like blinking a LED or send a message through the internet. We could prototype hardware with a sensor and send commands using our mobile phones using Arduino. We could use Bluetooth for that. For some reason, we didn’t like Bluetooth, we just thought that BT wasn’t going to work, so we decided to use NFC. NFC was trending, it was a new technology, and we saw many opportunities. Contactless payments like it’s common today were not common at the time, not everyone used or even knew about them.

Here is how we failed another access control. And also how we destroyed a successful startup.

What to do and what not to do

The project was great. Another ambitious one. The bank already had an access control system. More than 4000 branches around the entire country. The main goal was simpler. We needed to build a web application that would interact with the doors of the branches. Easy, we had a private network, from one of the biggest banks in the country, it would never be slow like MonKey was. MonKey’s problem was a network problem, it would never be bad untested code. But we would do things differently. To prevent the frontend from being slow, we used Ember.js, not AngularJS anymore. Now we would get a performative frontend. Besides network issues, MonKey had framework issues. AngularJS was not good enough for our application. It was too complex for AngularJS, which was the reason behind the framework change.

Large Classes

Usually we start coding small classes. While the codebase evolve, classes get bigger. And bigger. And bigger… They get bloated.

We can do the following to refactor large classes.

Extract Class

We can separate a large class into multiple smaller classes.

1
2
3
4
5
6
7
8
9

    class Person {
        private name
        private areaCode
        private officeNumber

        function getTelephoneNumber() {
            // Get the phone number
        }
    }

We can extract data from Person into another class.

Long Methods

Those are methods that contains a significant amount of code. There’s no rule for this smell, how long? 10, 20, 30 lines? Each case must be analyzed in its context.

It’s important that the method follows the Single Responsibility Principal, here’s a great video from Uncle Bob Martin about Solid Principles which covers SRP.

If we want to reduce the length of a method body

Extract Method

Suppose we have this code:

Introduction

Code Smells

Code smells indicate that the code needs to be refactored. This means that, while refactoring code, we need to find and get rid of code smells. This will allow more speed and quality in the development. Code will become hard to maintain and dirty, and features will require more time to implement. The team will feel that it would be better to start the project from scratch instead of evolving the current project.