miguel jimenez en español // MVP C#

Estaba leyendo un post de Perci Reyes, inspirado en un post sobre como comprender el código en Coding Horror. Después de leerlo, junto a todos los articulos relacionados (lo que piensa Joel y el post de Peter Hallam), creo que tengo algo que añadir y que parece no importar a nadie...

En primer lugar, estoy deacuerdo con los autores sobre las estadisticas presentadas de las actividades de un desarrollador... y quizás sea cierto que empleamos mucho tiempo en comprender código existente. Por defecto, los programadores somos tan narcisistas que necesitamos sentir que hemos creado algo, y somos propensos a cambiar cualquier cosas que no comprendamos a una solución más apropiada y personal, siempre bajo nuestro punto de vista. Todo el mundo parece discutir acerca de este narcisismo y los programadores deseando reescribir código en lugar de comprenderlo, pero yo tengo algunas dudas sobre si es un problema de los desarrolladores o del código en sí...

Es decir, es el código demasiado complejo para comprenderlo? Puede que lo sea. Personalmente he visto miles de lineas de código imposibles de seguir y comprender porque la arquitectura elegida, las capas de negocio o datos, el modelo de presentación o incluso la capa de UI no estaban diseñadas de manera correcta o ni siquiera existian. Esto añade mucha complejidad, pero debeis admitir que no esta relacionado con el desarrollador que modifica ese código. Es el propio código. Ese código fue escrito por un desarrollador que lo pensó como la mejor solución a un problema de negocio (o quizás era la mejor solución posible que podia implementarse con determinadas restricciones del proyecto, solución o el propio desarrollador; o quizás debido a una falta de experiencia o conocimiento del desarrollador que escribió el código)

Supongo que un equipo de desarrollo que trabaja en una solución lo hace de la mejor manera posible, usando patrones conocidos, desacoplando el código e interfaz de usuario, y refactorizando clases y métodos. Siguiendo algunas sencillas reglas deberiamos ser capaces de no encontrar cosas como un metodo con 400 líneas o una clase con un único método de 2000 líneas de código. Y prometo que este tipo de código existe, lo he visto muchas veces.

En ese caso, yo probablemente cambiaría y reescribiría el código que "huele". No porque lo prefiera hecho por mí, sino porque esta falta de diseño nos conduce a la locura y descontrol durante el desarrollo; pero lo más importante, sino se corrige frustrará el trabajo de futuros desarrolladores que tengan que mantenerlo o extenderlo.

Mi opinión acerca del hilo de posts es que simplemente hay que tener en cuenta que los desarrolladores somos narcisistas pero también somos capaces de leer código que sea comprensible. El problema para mi es la introducción de software mal diseñado, que desgraciadamente se puede encontrar por todos lados. Necesitamos tener en mente que cualquier pieza de código que desarrollemos se pondrá en producción en algún momento, y será mantenida o soportada por un equipo de desarrolladores (probablemente distinto al que lo desarrollo) que necesitará comprenderla.

Mi consejo personal es (y esto es lo que yo hago cuando escribo código en cualquier proyecto) que cada desarrollador ahí fuera debería escribir codigo de la mejor forma posible pero siempre haciendolo perfectamente legible y comprensible. El código debe hablar por sí mismo, no a través de comentarios añadidos para comprenderlo, y debe ser refactorizado y simplificado hasta que sea legible por simples humanos. No es tan dificil. Hay muchas prácticas que permiten conseguir este objetivo y además, bajo mi punto de vista, hacernos mejores desarrolladores; pero mi frase favorita es:

"si sientes la necesidad de añadir un comentario, simplemente refactorizalo para que el comentario sea supérfluo. de esta forma tu código será más simple y facil de comprender"