What I got from Clean Architecture as a FE... (1-5)

I decided to start writing about my reading experiences. I have tried to pick up the habit of reading for a while and I decided that since my goal is to become a better dev, I will read and document software development books.

To give context, I am a Frontend Developer with more than 3 years of experience. I am one of those bootcamp developers. However, since the beginning, I tried to keep up with the content that is clearly missing from those bootcamps.

How is this going to work... I will try to write here what I am understanding from each chapter of this book by Robert C. Martin. Keep in mind, this is something I am doing for myself. However, if you want to comment on this with your thoughts, questions or tips on better understanding this book, feel free!

Chapter 1 - What is design and architecture?

The first chapter, he compares design and architecture to conclude that they are the same. He makes sure to emphasize the importance of a good design and architecture of a software. Furthermore, he continues to say that without quality, performance will dramatically decrease. He uses the story from the rabbit and the turtle to explain why over confidence and coding in a rush is always a bad choice.

Chapter 2 - A tale of two values

In the second chapter, Uncle Bob talks about two main values of a software, the functionality/how it works, and the architecture. He proceeds saying that most developers and tech workers tend to forget about the most important one, which is architecture, to focus on the other. We all know how it is "if it works, don't touch it". However, developing a software like this will have many implications. A good architecture permits that changes and improvements can be made to the software without impactful additional costs. He adds that the Eisenhower's matrix can be used.

While architecture is both urgent and important, functionality tends to be "just" urgent...

Chapter 3 - Paradigm Overview

In chapter three, the differences between the three paradigms (Structured Programming, Object-Oriented Programming, and Functional Programming) get overly summarized, but with the purpose to conclude that they are all important for software architecture.

Chapter 4 - Structured Programming

In this chapter, Uncle Bob talks about how the structured programming was proved useful. In general, he mentions that structured programming is basically separating concerns or practicing functional decomposing, which is separating big things into small modules so they are "testable". (Will have to read more about this)

Chapter 5 - Object-Oriented Programming

Reading chapter 5 from the perspective of a Javascript/Typescript developer, can be challenging if you have no previous experience working with classes (Why learn them if we can just "rfce" on VSCode and create our functional components, right?). However, the author gives a brief explanation of the three principles related to OOP. One is encapsulation. Encapsulation is the method of bundling data and functions inside an object. Encapsulation helps hiding internal state of such object.

class Car {
  constructor(make, model) {
    this.make = make;
    this.model = model;
    this.speed = 0;
  }

  accelerate(speedIncrement) {
    this.speed += speedIncrement;
  }

  brake(speedDecrement) {
    if (this.speed - speedDecrement >= 0) {
      this.speed -= speedDecrement;
    } else {
      this.speed = 0;
    }
  }

  getSpeed() {
    return this.speed;
  }
}

In this example, while you can view the properties, they can only be controlled through 'accelarate', 'break', and 'getSpeed'.

The second principle is inheritance, which by the name should be simple to figure out. This is a mechanism that a class inherits properties and methods from other classes.

class Animal {
  constructor(name) {
    this.name = name;
  }

  speak() {
    console.log(`${this.name} makes a noise.`);
  }
}

class Dog extends Animal {
  speak() {
    console.log(`${this.name} barks.`);
  }
}

Last principle is Polymorphism, considered to be the most important one. Polymorphism allows objects of different classes to be treated as objects of a common superclass. This relates to inheritance, however in the example below we can see polymorphism with the method makeSound() as it behaves differently based on the type of animal object it is called upon.

class Animal {
  makeSound() {
    console.log('Some generic sound');
  }
}

class Dog extends Animal {
  makeSound() {
    console.log('Woof');
  }
}

class Cat extends Animal {
  makeSound() {
    console.log('Meow');
  }
}

I will end this first portion here. Next time I will go from Chapter 6 until Chapter 10. This book has 34 chapters, let's see if I will be a better architect by then...