Me acabo de casi terminar "Clean Code", de Robert C. Martin. Posiblemente lo he leído muy tarde, puesto que casi todo lo que se cuenta ya me sonaba de haberlo leído en otros libros o resúmenes, por lo que no me ha aportado nada especialmente nuevo.
Trata principalmente de cómo hacer un código legible para otros programadores, de forma que no necesiten gastar mucho tiempo navegando por él para entenderlo y puedan abordar fácilmente las posibles modificaciones o mejoras que tengan que implementar.
En los primeros capítulos nos cuenta las reglas más o menos conocidas por todas: nombres largos de clases, métodos y variables, lo suficientemente descriptivos, tratar de que no sean necesarios los comentarios por el código lo suficientemente claro y eliminarlos, evitar listas interminables de parámetros en los métodos prefiriendo realizar más métodos con nombres más descriptrivos pero con menos parámetros, etc, etc. Una regla si me ha llamado especialmente la atención y es la de tener las clases a distintos niveles de profundidad en la lógica del programa, es decir, debe haber clases de alto nivel con vocabulario muy cercano al usuario y clases de más bajo nivel con vocabulario muy cercano a los programadores pero, lo más importante, es no mezclar ambos vocabularios en una misma clase.
La segunda parte del libro es muy farragosa. Pone código real de ejemplo sacado, por ejemplo, de Fitnesse, JUnit, … y se dedica a mostarnos, paso a paso y con detalle como se puede ir mejorando ese código a base de refactorizaciones pequeñas para dejarlo más entendible. Lo realmente importante de esta parte no son los pasos que se van dando en sí, aunque siempre se aprende algo de alguno, sino el hecho de que el código se deba refactorizar no sólo para evitar duplicidades en él o reorganizarlo de otra manera mejor, sino símplemente por el hecho de hacerlo más entendible. Como el autor dice, "el programador que da su código por finalizado cuando funciona no es un buen programador. El buen programador dedica tiempo a arreglar su código para que sea entendible por otros". Y por entendible se entiende que otro programador pueda entender qué hace el código sin tener que andar entrando en todas y cada unade sus clases y métodos.
En cuanto a la tercera parte… me la he saltado. Tras el cansancio de la segunda y ver que empezaba a meterse con problemática concreta de determinados códigos (Threads en concreto), me dio la pereza y pasé a otro libro.