Análisis de libro – Clean Code (Código limpio)
Autor: Robert C. Martin (Uncle Bob)
Año: 2008
nº páginas: 464
tiempo estimado de lectura = 65 días
Contenido
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.
