5 Pasos para Programar Pensando en el Próximo Desarrollador

1 de enero de 2015 • 6 min de lectura

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í código confuso intencionalmente, pero tampoco dejé pistas.

Kent Beck sobre los 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 los buenos programas de computadora:

Todo se reduce a la comunicación y las estructuras que usas 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. Así que a ese nivel, no son tan diferentes.

Descubrir el propósito y la intención es difícil incluso en el código mejor escrito. Cualquier pista dejada por el autor, comentarios, nomenclatura detallada y consistencia, es inmensamente útil para los próximos desarrolladores.

Empiezo 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 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 ubicación de estos componentes. Entra a 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.

Existen patrones de software conocidos para problemas comunes de software. En 1995, se publicó Design Patterns: Elements of Reusable Object-Oriented Software describiendo patrones comunes de software. Este libro describe problemas comunes encontrados en la mayoría de aplicaciones de software y ofreció una manera elegante de resolver estos problemas. Los desarrolladores también crean sus propios patrones mientras resuelven problemas que encuentran rutinariamente. Aunque no publiquen un libro, si observas 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 perspectiva sobre la implementación del otro desarrollador. Muchos de nosotros tenemos la inclinación de reescribir lo que no entendemos. ¡Resiste esta urgencia! La implementación existente está probada en batalla y la tuya no.

Algo de código es simplemente molesto, acércate a un colega — un segundo par de ojos siempre ayuda. Recorran el código juntos. Te sorprenderás de lo que encontrarán entre los dos.

Aquí tienes 5 consejos para dejar pistas para los próximos desarrolladores

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

2. Consistencia
Este es por mucho el aspecto más importante de la programación. Nada es más frustrante que encontrar código inconsistente. La consistencia permite suposiciones. Cada vez que se encuentre un patrón de software específico, se debe asumir 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 le hagas esto al próximo desarrollador.

3. Nomenclatura Detallada
Este es tu lenguaje. Estas son las palabras de tu historia. Téjelas 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 directamente en la declaración 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 suponer que realmente son 3 horas. En realidad no lo sabemos. Estamos haciendo una suposición.

En el segundo ejemplo, establecemos 3 a una variable llamada ‘feedInterval’. La intención está claramente establecida 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 artificial, en una pieza grande de software este tipo de código se autodocumenta y ayudará al próximo 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 entienda el código. Esto sucede cuando las suposiciones no son obvias o el código está fuera de lo ordinario.

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

Steve Jobs sobre la simplicidad:

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

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

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

Conclusión

Leer código es difícil. Con unos pocos pasos simples puedes asegurar que el próximo desarrollador comprenda tu código.