Análisis de libro – Clean Code (Código limpio)

Clean code

Autor: Robert C. Martin (Uncle Bob)

Año: 2008

nº páginas: 464

tiempo estimado de lectura = 65 días

Resumen del libro Clean Code

Este libro es un referente para todos los programadores del mundo. Explica conceptos para mejorar la escritura del código, muestra casos de uso, contiene múltiples ejemplos de conversión de código y todo desde un punto de vista de un programador profesional.

Robert C Martin ha dedicado varias décadas a estudiar cómo crear reglas para hacer código limpio, ayudar a equipos y gestionar aplicaciones de gran envergadura, por lo que su conocimiento sobre la materia es excelente y queda patente en sus libros.

Los ejemplos están escritos en Java, pero son simples y se pueden seguir por cualquier programador, y por supuesto por cualquier pythonista. Se recomienda hacer una lectura detenida y comprender correctamente cada concepto explicado dado que no se repiten y son muy interesantes.

Pepitas de conocimiento de Clean Code

A continuación se muestran las principales lecciones que he podido extraer del libro.

Usar tests ayuda a desarrollar más rápido

Los tests son una de las herramientas más útiles que existen en el desarrollo de aplicaciones por los siguientes motivos:

  • Permiten garantizar que lo que está cubierto por los tests funciona.
  • Permite cambiar código que está cubierto por los tests, y si estos pasan tras los cambios se tiene seguridad de que el código cubre los mismos casos que cubría.
  • Cuando un sistema es muy grande, los cambios son lentos si no se tienen tests, dado que cualquier cambio puede afectar a diferentes partes del mismo pasando inadvertido.

Si se analizan los puntos explicados, se puede concluir que a medida que un proyecto agranda sin tests, cada cambio a realizar require más y más tiempo, llegando incluso a requerir reescrituras parciales o totales del sistema.

Por tanto, si se escriben tests se puede mantener el ritmo de trabajo, lo que a la larga hace que desarrollar sea más rápido con tests que sin ellos.

La regla del boyscout

Cuando se lee código, siempre es una buena práctica dejarlo mejor que como se encontró. Ya sea cambiando un nombre de variable, refactorizando una función con la misma lógica o simplemente cambian los nombres de variables por otros más descriptivos. Deja el código mejor de lo que lo has encontrado.

Regla de la menor sorpresa

Siempre que hagas un código intenta que quien lo lea se sorprenda lo menos posible

Principio de responsabilidad única

Cada función debería de hacer una y solo una cosa. De esta forma es fácilmente testable la función y el nombre de la misma es claro.

Con regularidad se hacen funciones que hacen múltiples operaciones diferentes y el resultado es que se crea código muy interconectado entre sí.

El código debería de estar en el mismo nivel de abstracción

En la lógica de una función no deben de mezclarse abstracciones de diferentes niveles. Un claro ejemplo esto sería el siguiente:

def print_options():
    option = input('Seleccione A o B')
    if option.upper() == 'A':
        print_a_colours()
    elif option.upper() == 'B':
        print_b_colours()

Como se puede ver en el ejemplo la función print_options tiene por un lado que lidiar a bajo nivel con cómo se selecciona cada opción, con la lógica de qué hacer con cada opción y luego de forma más abstracta llama a las funciónes que imprimen por pantalla dependiendo de la opción.

Una implementación en la que los niveles de abstracción son iguales sería la siguiente:

def print_options():
    option_selected = get_option()
    print_color_option(option_selected)

def get_option():
    return input('Seleccione A o B')

def print_color_option(option):
    if option.upper() == 'A':
        print_a_colours()
    elif option.upper() == 'B':
        print_b_colours()

Como se puede ver en este otro ejemplo, los niveles de abstracción de cada función son coherentes.

Las estimaciones son variables, las funcionalidades entregadas también

Las fechas de entrega las define el equipo de producto, con una serie de funcionalidades y el equipo de desarrollo se encarga de estimar e implementar las funcionalidades.

Si se estima y se crean las tareas pormenorizadas, se pueden ver la evolución del proyecto y quitar funcionalidades si fuera preciso sin modificar la fecha de entrega.

Sobre el autor de Clean Code

Robert C. Martin (también conocido como Uncle Bob) es un profesional del desarrollo de software. Comenzó su carrera en 1970 y desde 1990 ha trabajado como consultor internacional en empresas de primer nivel.

Es fundador y presidente de Object Mentor Inc, donde ofrecen servicios de consultoría para equipos en todo el mundo en diferentes lenguajes de programación, en el campo de la programación orientada a objetos, en patrones de diseño, metodologías ágiles y en eXtreme Programming.

Libros de Robert C. Martin

Compartir

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Ver más

  • Responsable: Oscar Ramirez.
  • Finalidad:  Moderar los comentarios.
  • Legitimación:  Por consentimiento del interesado.
  • Destinatarios y encargados de tratamiento: No se ceden o comunican datos a terceros para prestar este servicio. El Titular ha contratado los servicios de alojamiento web a ionos (1&1) que actúa como encargado de tratamiento.
  • Derechos: Acceder, rectificar y suprimir los datos.
  • Información Adicional: Puede consultar la información detallada en la Política de Privacidad.

Publicar un comentario