Si es un desarrollador de software, en algún momento debe haber oído hablar del «código limpio». Puede provenir de sus líderes técnicos o sus colegas, pero cada vez que se entera de ello, siempre va seguido de una lista de «mejores prácticas», «debe hacer», «no debe hacer», «código legible», «convenciones de nomenclatura». «y otros términos y prácticas con los que puede estar familiarizado o no. Y si en este momento no ha leído el libro Código limpio de Robert C. Martin, esta publicación es para usted.
Entonces, ¿qué es Clean Code? – Mi opinión: es un código que funciona de manera eficiente y está completamente probado y también que otros pueden leer, comprender, sentirse bien y usarlo sin problemas.
Pero ese soy solo yo, Robert Martin nos trae algunas otras definiciones de programadores conocidos y profundamente experimentados, y entre ellas está la de Michael Feathers:
Podría enumerar todas las cualidades que noto en un código limpio, pero hay una cualidad general que conduce a todas ellas. El código limpio siempre parece haber sido escrito por alguien a quien le importa. No hay nada obvio que puedas hacer para mejorarlo. El autor del código pensó en todas esas cosas, y si intentas imaginar mejoras, volverás a donde estás, sentándote apreciando el código que alguien te dejó, código dejado por alguien que se preocupa profundamente por el artesanía.
Michael Feathers, autor de Working Effectively with Legacy Code
Y ese es el gancho del tío Bob: «… alguien que se preocupa profundamente por el oficio».
Hasta esa línea, estaba muy orgulloso de ser programador y luego subió el listón, ahora me da vergüenza … porque tal vez no me importaba lo suficiente mi código (¡a conciencia!). Entonces, será mejor que sigamos leyendo.
Siguiente idea que había escuchado antes: dejar el campamento más limpio de lo que lo encontró. – La regla de los Boy Scouts. Para tener una mejor base de código, es necesario no solo escribir código limpio, sino también realizar limpiezas y mejoras constantes. «Como profesionales», dice Bob, «no tenemos otra opción aceptable que hacer nuestro mejor esfuerzo para mejorar nuestro trabajo con el tiempo».
En el otro lado de la idea anterior está la pereza del desarrollador. Tal comportamiento seguirá pudriendo el código hasta que sea imposible cambiar una característica o pequeña función sin perder el sueño pensando: ¿qué más hemos roto ?. Ningún equipo o desarrollador debería tener este tipo de preocupación, por eso siempre debemos impulsar las mejores prácticas y un código limpio.
¿Qué más hay en el libro?
El libro está organizado en un conjunto de 17 capítulos que comienzan con temas más fáciles de entender, como «Nombres significativos», «Formato», «Manejo de errores» y «Pruebas unitarias», mientras que los temas más difíciles están por delante, como «Concurrencia» y «Diseño de sistemas». «. Esta combinación de capítulos es el resultado de lo que Bob dice que es la Escuela de Pensamiento: opiniones absolutas seleccionadas sobre cada tema reunidas entre Bob y sus compatriotas.
Repasemos algunas de las ideas, si se necesita código, traeré el mismo código que en el libro.
Nombres significativos
El capítulo dos trata sobre cómo elegir un nombre para una variable, clase o función. Se supone que debemos escribir nuestro código de una manera que otros puedan leer como la prosa. Además de las estructuras de control de nuestro lenguaje, todo lo que tenemos son nuestras propias clases, funciones o variables para decirnos qué está pasando. Veamos el ejemplo en el libro:
int d;
¿Qué es la variable d? – Aparte del hecho de que es un número entero, no podemos decir más sobre él. Vamos a mejorarlo un poco:
int d; // tiempo transcurrido en días
¡Ahora sabemos qué es! – Bueno, busquemos esta variable nuevamente 50 líneas de código a continuación:
list.add (d);
Sí, esa es una lista y se ha agregado nuestra d. Espera, ¿cuál fue la variable de nuevo? una lista de que?
Los comentarios no resolverán nuestro problema semántico, necesitamos poder leer cualquier línea de código y comprender lo que está sucediendo sin la necesidad de ir a ninguna parte. Necesitamos elegir nombres mejores y más significativos.
int elapsedTimeInDays;
int daysSinceCreation;
int fileAgeInDays;
¿Qué pasa con estas variables? ¿Sabemos cuáles son? – Exactamente.
Lo mismo ocurre con las clases, funciones, interfaces y objetos. Este capítulo le enseñará cómo elegir nombres de manera eficiente evitando errores comunes. Definitivamente una lectura obligada.
Funciones
¡Las funciones deben ser pequeñas! Eso es bastante obvio, ¿verdad? Bueno, todavía nos encontramos escribiendo frase tras frase, miramos a nuestro editor y hay 300 líneas. ¡¿Qué?! – Bueno, es largo pero funciona (hablando por pereza del desarrollador).
Por supuesto, debería funcionar, pero también tiene que ser limpio, fácil de leer y fácil de entender por otra persona. Nuestra función debe tener una única tarea, hacerlo bien y dejarlo claro. ¿Una función de 300 líneas sería fácil de leer y comprender? – Probablemente no, así que manos a la obra. Somos profesionales, nos preocupamos.
¿Qué pasa con los argumentos? – Cuanto menos hay, mejor. A medida que avancemos en el libro, encontraremos ideas que son bastante obvias al leerlas, pero ¿hemos reflexionado sobre esto antes?
Los argumentos son aún más difíciles desde el punto de vista de las pruebas. Imagine la dificultad de escribir todos los casos de prueba para asegurarse de que todas las diversas combinaciones de argumentos funcionen correctamente. Si no hay argumentos, esto es trivial. Si hay un argumento, no es demasiado difícil. Con dos argumentos, el problema se vuelve un poco más desafiante. Con más de dos argumentos, probar cada combinación de valores apropiados puede resultar abrumador.
Robert C Martin. Código limpio.
Prueba de unidad
Un buen código no puede existir sin pruebas automatizadas. Las pruebas son nuestra garantía de que el programa hace exactamente lo que se pretende hacer y nada más. Las pruebas son nuestro vigilante, nos harán saber si algún cambio está tratando de alterar nuestro código y nos dirán exactamente cómo solucionarlo.
Algunos equipos y desarrolladores todavía están luchando con las pruebas unitarias. «Es tiempo que no tenemos», dicen. Están equivocados, el código sin pruebas es código listo para romperse o errores disciplinados esperando el momento adecuado para hacer lo suyo. Ese tiempo que estaban ahorrando, lo necesitarán multiplicado después.
El tío Bob es un firme defensor de las pruebas unitarias y este capítulo trata sobre por qué debería hacerlo y cómo. Lectura realmente útil.
En algún momento, verá este acrónimo en el libro: F.I.R.S.T. – Sí, la primera vez que lo vi también. Se trata de reglas para pruebas unitarias limpias. Vamos a enumerarlos aquí:
- Las pruebas rápidas deben ser rápidas. Debe ejecutar su traje de prueba con mucha frecuencia, la prueba lenta lo desanimará a ejecutarlos con frecuencia o seguir escribiéndolos ya que a nadie le gusta perder el tiempo.
- Las pruebas independientes no deben depender unas de otras. Cada prueba debe poder ejecutarse de forma independiente y en el orden que desee.
- Las pruebas repetibles deben ser repetibles en cualquier ambiente o ambiente agnóstico. No querrás tener una razón como: «Las pruebas fallan porque no estamos en desarrollo».
- Las pruebas de autovalidación deben tener una salida booleana. O pasan o no.
- Las pruebas oportunas deben escribirse justo antes del código de producción que hace que la prueba pase. Hacerlo al revés hará que el código de producción sea muy difícil de probar, ya que no fue diseñado para ser comprobable.
Conclusiones
Clean Code es un libro de lectura obligada para todos los programadores. Introduce el concepto de «artesanía» o «artesanía». Cada capítulo lo llevará a experimentos sobre cómo las cosas podrían mejorar y cómo puede ser un mejor programador.
Siempre lo mantengo cerca y navego por los capítulos cuando necesito. No tomo sus enseñanzas como absolutas, pero definitivamente son una luz guía sobre cómo ser un profesional. Finalmente, me encantaría saber de usted y de su experiencia con el libro. ¿Qué piensas?