SOLID and Clean Clode principles

The main goal of this repository, is to have shortcut knowledges and principles to mitigate or reduce technical debt.

📍Clean Code

1. Naming conventions
2. Name Types
3. Naming functions
4. Refactoring functions avoid else statement
5. DRY (Don't repeat yourself)
6. Single Responsibility Principle
7. Single Responsibility Principle - Composition over inheritance

📍 STUPID - Code Smells

1. Singleton
2. Tight coupling:
   • High coupling
   • Low coupling
3. Untestability
4. Premature Optimization
5. Indescriptive Naming
6. Duplication (no DRY)

📍 SOLID

1. Single Responsability Principle

Una clase o módulo debe tener una única razón para cambiar. Es decir, debe tener una única responsabilidad.

Indicios de violaciones:

- Nombres de clases o módulos demasiado genéricos.
- Cambios en el código suelen afectar la clase o módulo.
- Cantidad elevada de métodos públicos.
- Cantidad excesiva de líneas de código.

2. Open Closed Principle

Las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para su extensión, pero cerradas para su modificación.

Indicios de violaciones:

  - Cambios en el código suelen afectar la clase o módulo.
  - Cantidad elevada de métodos públicos.
  - Cantidad excesiva de líneas de código.
  - Cuando una clase o módulo afecta muchas layers (storage, presentación, etc.).

3. Liskov Substitution Principle

Siendo U un subtipo de T, entonces los objetos de tipo T en un programa pueden ser sustituidos por objetos de tipo U sin alterar las propiedades del sistema.

Indicios de violaciones:

  - Cuando una clase hija no puede ser sustituida por la clase padre.
  - Cuando una clase hija no puede implementar un método de la clase padre.

4. Interface Segregation Principle

Los clientes no deben ser forzados a depender de interfaces que no usan.

Indicios de violaciones:

  - Cuando una clase implementa una interfaz que no usa.
  - Está relacionado con el principio de responsabilidad única y con el principio de sustitución de Liskov.

5. Dependency inversion Principle

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones, que son las que vamos a utilizar en los lugares dónde necesitemos la implementación concreta.

Se suele utilizar la inyección de dependencias para cumplir con este principio, a su vez que se cumple con el principio de open and closed, y con la Sustitución de Liskov.

Indicios de violaciones:

  - Dependencias ocultas, es decir, cuando una clase crea una instancia de otra clase dentro de un método. Suele resolverse con inyección de dependencias.

📔 References

• Clean Javascript
• Refactoring Guru
• Clean Code Javascript Repo
• The Pragmatic Programmer