5 pasos para codificar para el siguiente desarrollador

La mayoría de nosotros probablemente no pensamos en el desarrollador que mantendrá nuestro código. Hasta hace poco, yo tampoco lo consideraba. Nunca escribí intencionalmente código obtuso, pero tampoco dejé ninguna pista.

Kent Beck sobre buenos programadores:

Cualquier tonto puede escribir código que una computadora pueda entender. Los buenos programadores escriben código que los humanos puedan entender.

Douglas Crockford sobre buenos programas de computadora:

Todo se reduce a la comunicación y las estructuras que utilizas para facilitar esa comunicación. El lenguaje humano y los lenguajes de computadora funcionan de manera muy diferente en muchos aspectos, pero en última instancia juzgo un buen programa de computadora por su capacidad de comunicarse con un humano que lee ese programa. Entonces, a ese nivel, no son tan diferentes.

Descubrir el propósito e intención es difícil incluso en el código mejor escrito. Cualquier pista dejada por el autor, comentarios, nombres verbosos y consistencia, es inmensamente útil para los siguientes desarrolladores.

Comienzo buscando patrones. Los patrones se pueden encontrar en muchos lugares, incluyendo nombres de variables, diseño de clases y estructura del proyecto. Una vez identificados, los patrones son perspectivas sobre la intención del desarrollador anterior y ayudan a comprender el código.

¿Qué es un patrón? Un patrón es una solución repetible a un problema recurrente. Considera una puerta. Cuando un espacio debe permitir que las personas entren y salgan y aún así mantener el aislamiento, se implementa el patrón de puerta. Ahora esto parece obvio, pero en algún momento no lo era. Alguien creó el patrón de puerta que incluía la manija de la puerta, las bisagras y la colocación de estos componentes. Entra en cualquier hogar y puedes identificar cualquier puerta y sus componentes. Los estilos y colores pueden ser diferentes, pero los componentes son los mismos. El software es igual.

Hay patrones de software conocidos para problemas comunes de software. En 1995, se publicó Design Patterns: Elements of Reusable Object-Oriented Software describiendo patrones de software comunes. Este libro describe problemas comunes encontrados en la mayoría de aplicaciones de software y ofreció una forma elegante de resolver estos problemas. Los desarrolladores también crean sus propios patrones mientras resuelven problemas que encuentran rutinariamente. Aunque no publican un libro, si miras lo suficientemente cerca puedes identificarlos.

A veces es difícil identificar los patrones. Esto hace que comprender el código sea difícil. Cuando te encuentres en esta situación, inspecciona el código, ve cómo se usa. Comienza una reescritura. Pregúntate, ¿cómo lograrías el mismo resultado? A menudo, mientras recorres el proceso de pensamiento de un algoritmo, obtienes información sobre la implementación del otro desarrollador. Muchos de nosotros tenemos la inclinación de reescribir lo que no entendemos. ¡Resiste este impulso! La implementación existente ha sido probada en batalla y la tuya no.

Algunos códigos son simplemente molestos, comunícate con un colega — un segundo par de ojos siempre ayuda. Recorre el código juntos. Te sorprenderá lo que los dos encontrarán.

Aquí hay 5 consejos para dejar pistas para los siguientes desarrolladores

1. Patrones
Usa patrones conocidos, crea tus propios patrones. Mantente con un paradigma consistente en todo el código. Por ejemplo, no tengas 3 enfoques para el acceso a datos.

2. Consistencia
Este es, con mucho, el aspecto más importante de la codificación. Nada es más frustrante que encontrar código inconsistente. La consistencia permite hacer suposiciones. Cada vez que se encuentra un patrón de software específico, debe asumirse que se comporta de manera similar a otras instancias del patrón.

El código inconsistente es una pesadilla, imagina leer un libro donde cada palabra significa algo diferente, incluyendo la misma palabra en diferentes lugares. Tendrías que buscar cada palabra y gastar grandes cantidades de energía mental descubriendo la intención. Es frustrante, tedioso y doloroso. ¡Te volverás loco! No hagas esto al siguiente desarrollador.

3. Nombres Verbosos
Este es tu lenguaje. Estas son las palabras de tu historia. Teje bien.

Esto incluye nombres de clases, nombres de métodos, nombres de variables, nombres de proyectos y nombres de propiedades.

No hagas:

if(monkey.HoursSinceLastMeal > 3)
{
    FeedMonkey();
}

Haz:

int feedInterval = 3;

if(monkey.HoursSinceLastMeal > feedInterval)
{
    FeedMonkey();
}

El primer ejemplo tiene 3 codificado en la sentencia if. Este código es sintácticamente correcto, pero la intención del número 3 no te dice nada. Mirando la propiedad contra la que se evalúa, puedes deducir que son realmente 3 horas. En realidad no lo sabemos. Estamos haciendo una suposición.

En el segundo ejemplo, establecemos 3 en una variable llamada ‘feedInterval’. La intención se indica claramente en el nombre de la variable. Si han pasado 3 horas desde la última comida, es hora de alimentar al mono. Un efecto secundario de establecer la variable es que ahora podemos cambiar el intervalo de alimentación sin cambiar la lógica.

Este es un ejemplo inventado, en una gran pieza de software este tipo de código se autodocumenta y ayudará al siguiente desarrollador a entender el código.

4. Comentarios
Los comentarios son un arma de doble filo. Demasiados comentarios aumentan los costos de mantenimiento, muy pocos dejan a los desarrolladores inseguros sobre cómo funciona el código. Una regla general es comentar cuando el desarrollador promedio no entenderá el código. Esto sucede cuando las suposiciones no son obvias o el código es fuera de lo común.

5. Código Simple
En mi opinión profesional, escribir código complejo es el mayor error entre los desarrolladores.

Steve Jobs sobre la simplicidad:

Simple puede ser más difícil que complejo: Tienes que trabajar duro para limpiar tu pensamiento para hacerlo simple. Pero vale la pena al final porque una vez que llegas allí, puedes mover montañas.

La complejidad viene en muchas formas, algunas de las cuales incluyen: prueba futura, implementaciones excesivamente complejas, demasiada abstracción, clases grandes y métodos grandes.

Para más información sobre escribir código limpio y simple, consulta el libro Clean Code de Uncle Bob y Code Simplicity de Max Kanat-Alexander

Conclusión

Leer código es difícil. Con algunos pasos simples puedes asegurar que el siguiente desarrollador comprenderá tu código.