Categorías
Desarrollo

Clean Code para juniors

Al comenzar esta andadura en el mundo profesional de la programación, comenzaron a surgirme ciertas preguntas del tipo: ¿Será mi código bueno, legible, entendible?, ¿Esto es un batiburrillo que me va a quedar en vergüenza? y podría seguir con más…
Por ello, comencé a leer CLEAN CODE, de Robert C. Martin, libro que es de gran ayuda para establecer los cimientos de un código de calidad para los recién iniciados en el «mundillo», y del cual os voy a resumir los primeros capítulos.

Clean Code

«El código limpio, es más importante que el código rápido.»

¿Qué es un código limpio? El escritor, lo define como un código escrito por alguien que parece importarle, que presta atención a los detalles. Es aquel que es:

  • fácil de entender (limpio, organizado, con nombres de variables correctas y funciones significativas, sencillas),
  • fácil de modificar (al ser fácilmente entendible, es probable que los cambios se realicen correctamente)
  • y fácil de mantener (al ser sencillo de entender y de modificar, es más probable que no se vuelva obsoleto o que requiera de cambios importantes a futuro)

Robert C. Martin destaca que el código limpio es una buena inversión no solo en el presente, sino a futuro, ya que puede ahorrar tiempo y dinero, evitando la acumulación de «deuda técnica». Esta deuda, surge al elegir un código de baja calidad, lo que disminuye la productividad con el tiempo. La inversión en código limpio es esencial para evitar complicaciones y gastos adicionales a medida que el software evoluciona.

Meanigful Names

¡Los nombres de las variables, funciones y clases son importantísimos!

En este segundo capítulo, el autor se centra en la importancia de los nombres significativos; Sostiene que los nombres de las variables, funciones y clases, son una de las herramientas más valiosas que los programadores tienen para comunicarse entre si.

Los nombres significativos son aquellos que comunican la intención del código y deben ser:

  • Consistentes
  • Descriptivos
  • y Cortos.

Para elegir nombres significativos, R. C. Martin aconseja: elegir una palabra por concepto, evitar las abreviaturas y los nombres genéricos, destacando, que las clases deben contener nombres y no verbos y las funciones deben tener verbos.

// Correcto
public int calculateTotalPrice(int quantity, double unitPrice) {
    return quantity * unitPrice;
}

public void printInvoice(Customer customer, List products) {
    // ...
}

// Incorrecto
public int calc(int q, double p) {
    return q * p;  // Nombres de parametros poco descriptivos
}

public void invoice(Customer c, List p) {
    // ...
}

 Functions

«Functions should do one thing. They should do it well. They should do it only.»

En este último capítulo del que hablaremos, se hace énfasis en la importancia de que las funciones tienen que ser pequeñas y deben tener una sola responsabilidad (Single responsibility principle), ya que son más fáciles de entender, modificar y de mantener.

Una función pequeña es aquella que sólo hace una cosa y debe tener:

  • Una única entrada y salida.
  • Un único objetivo (sólo realiza una tarea).
  • Y un único bloque de control (que sólo tiene una secuencia de instrucciones, sin ninguna condición o bucle).

Se aconseja en el libro, que para escribir funciones siguiendo estas recomendaciones, deben evitarse las funciones de más de 20 líneas de código. De tener más, dividir la función en otras más pequeñas y refactorizar el código siempre.

Por último, también es importante controlar el número de argumentos que se pasan en la función. Lo ideal, sería pasar 0 argumentos y como máximo 3, más de esto, sería una aberración.

Cuando tenemos que pasar 2 o más argumentos en una función, lo ideal es hacerlo a través de un objeto, clase o una lista, ya que formarían parte de un concepto, el cual merecería su propio nombre.

Con esto, se consigue: mejorar la legibilidad, facilitar el mantenimiento del código y su debugging, reducir su complejidad, promover el diseño modular…

// Correcto
public class DataProcessor {
    public String readFile(String filePath) {
        // ...
        return "File content";    }

    public void validateData(String data) {
        // ...
    }

    public void processData(String data) {
        // ...
    }

    public void writeToDatabase(String data) {
        // ...
    }
}

// Incorrecto
public class DataProcessor {
    public void processFile(String filePath) {
        String fileContent = readFile(filePath);
        validateData(fileContent);
        processData(fileContent);
        writeToDatabase(fileContent);
    }

    private String readFile(String filePath) {
        // ...
        return "File content";
    }

    private void validateData(String data) {
        // ...
    }

    private void processData(String data) {
        // ...
    }

    private void writeToDatabase(String data) {
        // ...
    }
}

Para terminar, en la introducción del libro dice:
«…bicycle riding is practical and give you all the knoledge you need to make it work.» so…, para mejorar tu código, ¡¡PRACTICA!!