Barrapunto

Creo que el código bién hecho, se lee como un buén libro, ya seá una aplicación para comprar tomates B2B o el código de un kernel.

Exactamente, crees, la realidad es mucho más dura. Lo que pasa es que te dará la sensación de que todos los códigos de medianos a grandes están mal hechos. Es rara la aplicación que puede ser leida "como un libro". Eventos, hilos, sincronización, árboles de herencia de 12 niveles... Todas estas cosas y más aparecen fácilmente en proyectos entre medianos y grandes y por mucho que te esfuerces en hacerlo legible, NO es legible. Ya si hay cosas como multiprocesador, que esté compuesto por varios procesos (como arquitecturas cliente-servidor), etc, entonces te puedes olvidar.

Un buen código es solo la mitad para poder entender el programa, es la documentación la que marca la diferencia. Si la documentación es buena, añadir una funcionalidad a una aplicación muy grande puede ser cosa de unas horas. Si te tienes que leer 20mil lineas de código solo para empezar a meterle mano (y encima luego darte cuenta de que algún evento por ahí perdido dispara una función que hace tal y te jode vivo, vuelve a empezar..), ese código solo vale para limpiarse el culo.

Para comprender la aplicación entera se necesita una buena documentación pero para concentrarte en un pequeño detalle que está bien imbricado en el conjunto sólo necesitas conocer los requerimientos de ese pequeño detalle.

Y ese pequeño detalle pueden ser llamadas a 50 métodos de 6 clases distintas y tú puedes necesitar saber que pasa en cada una exactamente para meterle mano. Ese pequeño detalle, antes de modificarlo, tienes que saber que quieres buscarlo y tienes que ser capaz de encontrarlo. Es la documentación lo que lo permite.

Las dependencias deben ser pocas y estar bien acotadas, si no, serían inmanejables.

Las dependencias pueden ser muchas y seguiría siendo manejable (documentado). De hecho, cuanto más grande sea la aplicación, con más y más complejas son las dependencias.

Lo que tú llamas la realidad son aplicaciones que están mal diseñadas, mal implementadas y mal documentadas.

Lo que tú dices es cualquier aplicación entre mediana y grande mal documentada.

La programación no es algo puramente mecánico, siempre hay que hacer elecciones. La única manera de comprender y ser capaz de moverte por esas elecciones es la documentación. En un proyecto de 1000 lineas, con saber que hace cada función te sobra. En un proyecto con 100000 lineas de código, además necesitarás diagramas de clases y demás parafernalia.

Un código sin documentar te obliga a leer todo aquello que quieras saber que hace: funciones, clases, módulos, todo. Si documentas que hace cada una de estas cosas, solo tienes que leer esa documentación, no necesitas ponerte a leer código que no vas a tocar. Eso te da agilidad y velocidad de movimiento por el código.

Es el tema de las capas, para según que cosas necesitarás diagramas de clases, para otras con conocer los métodos te vale, etc. Solo en última instancia necesitarás mirar el código.