Diario de Programación

Cada vez estoy más escéptico con el tema de la planificación de proyectos. No me refiero a hacerla, revisarla periódicamente, rehacerla, que es "relativamente sencillo" (ni de coña, hace falta mucha disciplina y experiencia). Me refiero a hacer una planificación que luego se cumpla.

Quizás gente con experiencia en planificaciones puede planificar más o menos correctamente un proyecto que dure unos meses y con unos pocos programadores (dos, tres, quizás cuatro). Pero, en nuestro caso, estamos hablando de varios proyectos con funcionalidades similares, pero lo suficientemente distintas como para requerir modificaciones, todos en paralelo, con alrededor de treinta programadores en total y plazos de entrega de uno a tres años.

Cualquier cosa que leas de planificación que te dice que hagas tareas muy granulares, del orden de tiempo estimado de uno o dos días por tarea. Si echamos unas cuentas, treinta programadores durante dos años, con tareas de 1 día, son aproximadamente …. ¡¡Buff, ni me atrevo a calcularlo!!.

Obviamente, no se puede calcular a priori todas esas tareas. La solución supuestamente es fijar pequeñas entregas cada uno o dos meses, dividir a la gente en grupos y planificar las tareas para esos dos o tres meses. Estupendo. ¿Y el resto del proyecto? ¿Y las demás entregas?. Por supuesto, todas ellas están fatalmente planificadas, porque ni se han detallado lo suficiente, ni se tiene muy claro que es lo que se tiene que hacer. ¿De qué sirve tener perfectamente planificado el primer mes o reajustar la planificación del primer mes si no se sabe nada fiable del resto del proyecto?

Al final da la impresión de que lo que hay que hacer es tener claro qué cosas son importantes y dedicarse a ellas primero, dejando lo secundario para el final por si da tiempo. Al final es algo así como "estará lo que dé tiempo a hacer en plazo y el resto no se hace", por lo que efectivamente es importante hacer lo más importante primero para que al menos eso esté. Pero ninguna planificación nos dirá a priori cuántas de esas cosas van a estar hasta que estemos ya muy cerca del final.

Quizás hay que dividir el plazo total entre las funcionalidades a implementar y hacer entregas cada uno o dos meses con esas funcionalidades. Pero para que se cumpla el plazo total, va a haber que pasado el tiempo de la primera entrega, dejar las funcionalidades que entren en ella como estén y pasar al segundo grupo. Por supuesto, en cada momento habrá que decidir si se continúa con las que no se han acabado (a costa de quitar otras) o se dejan como están para seguir con las siguientes. En cualquier caso, NO es una planificación para que se cumpla, sino es más que nada saber cómo se va para asumir el retraso y quitar cosas.

Cada vez estoy más decepcionado con este tipo de cosas.

Veo en Arragonán, que a su vez viene de mcdonaldland, una referencia rápida de los patrones de diseño. Un jpg/pdf en el que tenemos un pequeño esquema y resumen de los patrones de diseño GOF.

Lo que cuento aquí está extraido del artículo de Martin Fowler de Inversión de Control, pero como es interesante, pues eso, lo cuento aquí.

La cuestión, a la hora de inicializar una clase, es si lo hacemos pasándole todo lo necesario a través del constructor o bien por medio de métodos set().

En principio, es mucho más claro usar los constructores. En un constructor está claro qué debemos pasar a esa clase para que funcione correctamente y desde el mismo momento que la instanciamos, esa clase está en condiciones de funcionar, ya que  tiene todo lo necesario. Con los método set() no tenemos esa facilidad. Puede haber métodos set() que no sean necesarios para el correcto funcionamiento de la clase, por lo que no tendríamos necesidad de llamarlos. Y al revés, un método set() obligado se nos puede olvidar y la clase no funcionaría. Además, si no conocemos la clase, no podemos saber con los métodos set() cuales son obligatorio y cuales no, mientras que en el constructor está claro.

Por todo ello, en principio es mejor usar constructores. Pero hay una pega.

A veces hay muchas configuraciones posibles para la clase, según qué parámetros pasemos. Eso obligaría a hacer varios constructores. Si además, usamos herencia, es posible que en nuestra clase, además de nuestros constructores, tengamos que redefinir los de la clase padre, por lo que el número de constructores puede llegar a ser abrumador. Incluso a veces, al llamar al constructor de la clase padre, es posible que no podamos construir sobre la marcha uno de sus parámetros.

En ese caso, posiblemente sea mejor usar los métodos set(). Y como propone Martin Fowler, quizás sea buena idea llamar initParametro() a los que son obligatorios o a los que sólo se puede llamar una vez, aunque rompamos la regla de los beans de java.

Por mi parte, siempre había tenido esta duda y me había tropezado con los dos problemas -no saber que métodos set() son obligatorios o tener que hacer varios miles de constructores-. Todo esto me ha parecido buena idea, -usar constructores si es posible o métodos init() para los obligatorios- así que trataré de aplicarla a partir de ahora.

Ando últimamente un poco preocupado. Supuestamente debo dedicarme a diseñar código y otros lo codificarán. El problema principal que veo es que hay mucha distancia desde el punto de vista teórico del diseño y "las trincheras" de la codificación.

Me explico.

Cuando haces diseño, sobre todo de grandes aplicaciones, no puedes meterte en los detalles del código. Puedes pensar una arquitectura, unos módulos, las responsabilidades de los modulos y las interfaces de los mismos. La implementación de dichas interfaces no puedes meterte en ellas, ya que ni eres capaz de prever a priori todo lo que hay que hacer, ni sabes los problemas de codificación que van a surgir.

Ahora llevo unos días codificando sobre código ya hecho y más o menos pensado por mi, pero codificado por otros. Estoy haciendo código nuevo aprovechando ese código ya existente. Y es complicado. A pesar de que más o menos había ideado yo la esctructura de todo eso, y más o menos la sigue, veo que los problemas que se encontraron al codificarlo los han ido resolviendo como han podido, unos mejor que otros. Veo que ese código, que teóricamente debería poder reutilizar tal cual, no me vale tal cual. Tengo que hacer cambios -no muy grandes, pero sí cambios-. La culpa es en parte mía, porque mi diseño inicial era válido para los proyectos que había en curso, pero no lo bastante como para estos nuevos. También es en parte culpa de los codificadores. Posiblemente movidos por la prisa que siempre les meten los jefes, muchas veces optaron por las soluciones rápidas en vez de las buenas.

Sobre todo veo código repetido, cosas que deberían ser comunes, que yo no había previsto como comunes y que los programadores, movidos por las prisas, acaban rápidamente con copy-paste. Y ahora me veo obligado a hacer yo también otro copy-paste de ese trozo para el nuevo proyecto -nuevamente movido por las prisas- o bien "refactorizar" -ignorando las prisas-. Tocar el código hecho, llevarme esas copias a un sitio común y probar que todo sigue funcionando -los test unitarios brillan por su ausencia-.

Todo esto me lleva a pensar que es muy difícil conseguir un diseño bueno a priori y que es realmente difícil conseguir que se siga. El diseñador debe estar muy metido en el día a día del código para ver lo que se está haciendo, lo cual hace imposible que pueda abarcar aplicaciones demasiado grandes. Metiéndose en el día a día, puede controlar el diseño de trozos relativamente pequeños.

Cada vez estoy más convencido de que las estructuras jerárquicas, en que uno hace arquitectura, otros hacen diseño detallado y otros codifican no llevan realmente a ningún sitio. Es mucho mejor un grupo de gente con mucha comunicación, que hagan un diseño previo y, sobre todo, que todos ellos sean programadores hábiles, a los que les guste programar y tengan muchísimo interés en hacer el código bien… ¡¡ y que no les metan prisa !!.

Perdón por el título, pero se me hace muy difícil traducir el título del artículo Inversion of Control Containers and the Dependency Injection  Pattern de Martin Fowler.

El caso es que en la Chuwiki he empezado a hacer una traducción al cristiano de este artículo de Contenedores de Inversión de Control y el patrón de inyección de dependencias … ¡¡buff!! … titulito.

Aunque el artículo es muy largo, voy a tratar de hacer aquí un pequeño resumen en cuatro líneas, o alguna más. La idea es la siguiente:

Supongamos que una clase A para realizar su trabajo necesita unos datos. Esos datos se los pide a una  clase B que los lee de un fichero. La forma directa de realizar esto es que la clase A haga un new de la clase B. Esto, sin embargo, hace que la clase A sea menos reutilizable, ya que depende totalmente de la clase B y sólo podrá leer los datos de un fichero en el formato que entiende la clase B.

Este patrón de inyectables nos dice que hagamos una interfaceB con los métodos interesantes de la clase B y hagamos que la clase B implemente esa interfaceB. Por otro lado, la clase A en vez de hacer directamente el new de B, recibe en algún método -el constructor o un método set()- la interfaceB. De esta forma, alguien fuera de la clase A hace el new de B y se lo pasa a A. Haciéndolo así, si algún día cambiamos el formato del fichero o bien deseamos leer los datos de una base de datos, sólo tendremos que hacernos una clase OtraB que implemente la interrfaceB y pasársela a A. La clase A, sin tocar su código, será capaz de leer los datos del nuevo fichero o de la base de datos.

A esto lo llama inversión de control o inyección de depedencia. En vez de ser la clase A la que decide de quien depende, alguien desde fuera le "inyecta" la dependencia a través de un método set().

Y eso es todo.

El resto del artículo se extiende en contarnos que muchos de los frameworks actuales, como Spring, PicoContainer o Avalon, se basan en esto. Esos framework se encargan de instanciar las clases A y B y de pasarle a A la clase B. Todo ello desde código o desde un maravilloso fichero de configuración en donde se les dice qué tienen que instanciar y qué tienen que pasar a quien.

El artículo también menciona otra forma de conseguir todo esto, que es por medio de un localizador de servicios, pero viene a ser lo mismo, aunque metiendo otra interface y otra clase por medio. La idea es que haya una interfaceLocalizador con un método getInterfaceB() que devuelve la InterfaceB. Y es esa InterfaceLocalizador la que le pasamos a A.

No sé, la verdad es que a mi todo esto en realidad me parece un simple patrón Estrategia, pero adornado. Y la verdad, es que el patrón estrategia me ha parecido que no es más que el polimorfismo de cualquier lenguaje orientado a objetos.

Como programador, después de años programando y participando en varios proyectos, veo claramente la necesidad de frameworks.

En la historia de un programador, primero hace su código en su primer proyecto. En su segundo proyecto ve la necesidad de tener componente reutilizables y librerías, para no repetir código. Cuando ya ha participado en varios proyectos similares, aunque distintos, ve que todos ellos tienen muchas cosas en común, aunque no se parezcan. Suele ser necesaria una autentificación de usuarios, suele haber accesos a bases de datos, suele haber clases o módulos configurables que se necesita instanciar y configurar, suele tenerse que establecer conexiones por red con otros módulos, las interfaces de usuario tienen un esqueleto similar, consistente en menús, áreas de trabajo, baras de botones, etc, etc.

Todo esto le lleva a plantearse la necesidad de una especie de "esqueleto" de la aplicación. Algo que no haga nada concreto, en lo que se pueda meter cualquier cosa, pero que nos diga claramente cómo hacer las cosas, cómo instanciar los módulos, cómo configurarlos, cómo establecer las relaciones entre ellos, cómo manejar la base de datos, etc, etc.

Y eso es precisamente lo que hacen los frameworks. Una librería/aplicación que nos facilita mucho la construcción de nuestro proyecto y nos da hechas muchas de las cosas que son comunes en las estructuras de muchos proyectos.

Sin embargo, puestos que estos frameworks no saben nada de la aplicación concreta que queremos construir, ya que podemos querer hacer un cajero automático, un juego de ajedrez o un programa de contabilidad, deben ser altamente configurables. Eso requiere que tengamos muchos o grandes y complejos ficheros de configuración y que nuestros módulos implementen determinadas interfaces para que se adapten al framework,

Y eso hace que las aplicaciones hechas con frameworks sean siempre algo más lentas que las aplicaciones hechas "a pelo". Siempre es menos costoso hacer un new de una clase específica nuestra que hacer un new de un framwork, esperar que el framework lea los ficheros de configuración para al final hacer el mismo new que hebríamos hecho nosotros en una sola línea. También hace, según lo complejo de esas interfaces que tengamos que implementar, que nos "casemos" con el framework y una vez empezado a usar, no podamos echarnos atrás.

Desde el punto de vista del programador, un framework es una maravilla, puesto que da mucho trabajo hecho. Pero desde el punto de vista del usuario final, un framework es algo que le hace más lenta la aplicación y tiene que soportarlo por la pereza del programador: "Tengo que aguantar esta aplicación lenta porque el programador no ha querido hacérmela a medida desde cero". Desde este punto de vista, los frameworks no son tan buenos.

Pero, incluso desde el punto de vista del usuario final, pueden tener sus ventajas.

Por un lado, si los programadores ahorran trabajo usando un framework, el precio del producto final debería ser menor.

Y por otro, si nos metemos en el mundo real y no el ideal en el que todos somos "buenos y maravillosos", el framework soluciona otro pequeño problema. Si no hay frameworks, la calidad de las aplicaciones será muy variable. Hay empresas que se esfuerzan en dar productos de calidad y otras que no tanto. Hay programadores estupendos y hay programadores chapuzas. Desgraciadamente, en los tiempos que corren, las empresas no se preocupan demasiado de la calidad, subcontratan programadores recien salidos y sin experiencia por sueldos irrisorios, dejan que los programadores con experiencia se vayan porque les salen caros, tienen mucha rotación de gente  y en la mayor parte de los casos, el software sale como sale, si es que sale.

El usar un framework desde luego no soluciona este problema, pero al menos, si el framework es bueno, una parte de la aplicación, normalmente la más importante que es el esqueleto, va a tener una cierta calidad. Si un programador chapucero hace un módulo defectuoso, es más fácil que sólo se vea afectado ese módulo y suele ser más fácil, en caso de necesidad, reemplazarlo completamente por otro hecho desde cero.

Supongo que como en el 100% de los casos, la solución ideal es un compromiso entre ambos extremos. Por un lado no "casarse" con un framework especialmente complejo y pesado, pero sí usar uno de calidad que nos ahorre una cantidad significativa de trabajo.

En el comentario #5 de este post de Programania veo una cuestión que me ha llamado la atención:

yo tengo una duda.
cuales son las ventajas y desventajas de NO utilizar patrones de diseño en mi aplicación web.

Es realmente curioso pensar cómo hay bastante gente cree que los patrones de diseño son como las herramientas o librerías que tienes disponibles para un proyecto. La realidad es muy distinta.

Una persona empieza de programador novato y a lo largo de su carrera profesional va participando en varios proyectos. A poco que sea espabilidado, verá que suele repetir una y otra vez trozos de código similares, se le presentan problemas similares y está haciendo una y otra vez lo mismo en distintos proyectos -no el mismo código, sino resolviendo los mismos problemas-. También va viendo como el ćodigo que hizo en el proyecto anterior se puede mejorar, se puede hacer más reutilizable e incluso se puede hacer con un diseño más elegante.

Después de doscientos proyectos, esa persona acaba encontrando unas soluciones o forma de hacer las cosas que le funcionan para todos esos problemas que se le presentan una y otra vez y, al final, adopta mecánicamente esas soluciones, sin necesidad de pensar mucho. Pues bien, esas soluciones, o unas como esas, son los patrones de diseño.

Aplicar o no aplicar patrones de diseño en un proyecto no es como decidir si uso o no uso una librería o una herramienta. Si no usas patrones de diseño, lo más probable es que no estés haciendo tu código de la mejor forma posible. Debes usar patrones de diseño siempre.

Otro tema es que un programador novato o con poca experiencia puede tener dificultades para elegir el patrón de diseño adecuado en cada caso. Es bastante probable, sobre todo cuando se descubren los patrones de diseño, que tiendas a aplicar patrones complejos a problemas sencillos y, de la que estás, matar esa molesta mosca de un cañonazo.

Ultimamente estoy alucinado a los niveles a los que llega el papelo de un proyecto.

Se nos encarga un proyecto. Ese proyecto lleva varios hitos de pago. Un diseño preliminar que hay que entregar en una determinada fecha. Posteriormente, en otra fecha, un diseño detallado con un preliminar del manual de usuario. Más adelante el software entregado y funcionando.

La política -incorrecta- que seguimos es que los programadores, sin apenas especificaciones y sin diseño alguno se ponen "ya" a hacer el código. Mientras, el responsable del proyecto y para el hito va preparando el diseño preliminar para entregar. Llega el hito del diseño preliminar, el código ha llegado hasta donde haya llegado y se entrega un documento que poco tiene que ver con el código real.

Luego llega el momento de entregar el documento con el diseño detallado y el preliminar de manual de usuario. Eso ya es excesivo para el responsable del proyecto. El nivel de profundidad en el código que requiere el documento se va de las manos de un jefe -¡¡cómo va un jefe a meterse en el nivel de las clases!! Si no tiene ni p..a idea-. Así que llega el momento de pedir ayuda.

El jefe coge a los programadores -a todos, incluidos los nuevos- y les pide que le ayuden a hacer el diseño detallado. El diseño detallado que hagan, por supuesto, debe parecerse al código que están haciendo, pero por supuesto también, no puede discrepar con el diseño preliminar que se hizo anteriormente.

Y ahí tienes a todos los programadores, parados dos, tres o cuatro semanas, haciendo ingeniería inversa -a mano o con herramienta- y luego eliminando clases que son de demasiado bajo nivel, cambiando nombres de paquetes para que coincidan con el nombre que se les dio en el preliminar, juntando clases de paquetes separados en uno solo, y haciendo malabarismos varios con los diagramas UML.

Aparte de todos los fallos evidentes de esta forma de trabajo y del caos que salta a la vista, hay dos pequeños detalles que me llaman la atención.

Por un lado, el diseño preliminar se supone que es una fase intermedia del diseño. Cuando se pasa al diseño detallado y se va profundizando más en el problema, el diseño preliminar debería ser perfectamente modificable. Sin embargo, el papelo -las ganas de evitar hacer la versión 2.0 del diseño preliminar- hace que el diseño detallado se haga mal a posta, sin parecido al código real que se está desarrollando en paralelo.

Por otro lado…. si vas a parar a TODOS los programadores varias semanas para pintar unos monos que no valen para nada… ¿no es mejor pararlos al principio, antes de que se pongan a codificar a lo loco, para pensar al menos un esbozo de diseño real?.

Ya lo dice el refrán, "vísteme despacio que tengo prisa".

En su día, cuando entré a trabajar en la empresa, empecé de programador puro y duro. Alguien me decía qué tenía que hacer y lo hacía. Eran tiempos felices.

Más adelante, me dieron un grupo reducido de gente, tres o cuatro personas, a los que organizar y controlar el trabajo. Yo seguía programando, miraba los programas de esos tres o cuatro, y seguía siendo feliz, aunque un poco menos.

Hace ya unos meses que pretenden que organice y controle el trabajo de treinta personas. Apenas programo y me resulta imposible mirar el código de todos ellos ni organizarlos. Llevo desde que escribí el post del principio de Peter dándole vueltas al asunto sin llegar a nada en claro. De hecho, por eso escribí lo del principio de Peter, porque creo haber llegado a mi máximo nivel de incompetencia.

Sin embargo, esta mañana se me hizo la idea féliz. Ya sé cómo controlar a treinta personas -o a las que se tercien-. Basta seguir la tradición de los jefes que he tenido hasta ahora y que supongo que son como los que hemos tenido casi todos. La idea básica consiste en entrar a trabajar por la mañana, elegir a uno de los treinta al azar, preguntárle

• ¿Qué estás haciendo?

luego preguntarle

• ¿Cómo lo estas haciendo?

 y finalmente soltarle la bomba.

• Así como lo estás haciendo no vale. Bórralo y hazlo de esta otra forma peregrina que se me acaba de ocurrir Además date prisa, porque sería bueno que hicieras también esta otra cosa estrafalaria que he visto en internet.

Bueno. Por supuesto, es broma … creo. Lo cierto es que es complejo organizar tanta gente. Y después de leer mucho sobre buenas constumbres de programación -test unitarios, diseño, UML, etc, etc-, cuando es responsabilidad tuya implantarlas y el si funcionan bien o no cae sobre tus hombros, te empizas a plantear si realmente son tan buenas cosas, si realmente son tan efectivas. Sobre todo, cuando no tienes pruebas reales ni estadísticas serias. Sólo lo que comentan los "gurus" sobre lo bueno que es todo eso.

Y también te entra la duda, cuando quieres implantar esas cosas, si la gente que programa no te verán como ese " jefe" que inventa cosas raras para fastidiarnos. Y te preguntas hasta que punto ellos están en lo cierto, al igual que tu lo estabas cuando juzgabas a tu jefe.

Me refiero a la documentación, a los diagramas UML y todo lo demás. Por supuesto, un programa si hay que pensarlo un poco antes de ponerse a codificar.

El tema es el siguiente:

Suponte que eres un programador listo, que sabes hacer bien el código, reutilizable, bien hecho y que funciona correctamente. Suponte también que trabajas tú solo en el proyecto. Posiblemente piensas en cómo vas a hacer el programa e intentas plasmarlo en una documentación con UML. Según lo haces, como eres inteligente, te vas dando cuenta de problemas de diseño y los vas corrigiendo. Al final tienes una documentación buena que te ha llevado un tiempo hacer. Luego te pones a codificar, pero no consultas en absoluto la documentación porque la conoces y tienes las ideas claras. Según codificas, vas haciendo pequeños cambios en el diseño, cosas que no previste anteriormente. Al final te sale un buen programa en condiciones … y has perdido el tiempo en hacer una documentación que no has necesitado y que ahora no es coincide exactamente con el código y tienes que arreglar.

¿Qué pasa si no hubieras hecho documentación?. Habrías pensado igualmente, quizás te habrías hecho unos esquemas en borrador para aclarar ideas, te habrías puesto a hacer el código, habrías ido corrigiendo y arreglando cosas sobre la marcha y al final llegarías a un resultado parecido e igual de bueno. Posiblemente lo hayas hecho en menos tiempo, ya que no lo has perdido en hacer una documentación formal. Basta con los esquemas en borrador para aclararte las ideas. ¿Necesitas la documentación ahora para el cliente? Una buena ingeniería inversa hace maravillas.

¿Y qué pasa si eres un programador torpe?. Da igual que hagas o no documentación. En cualquier caso tardarás mucho y no llegarás a un buen código. Si eres avispado, en cualquiera de ambos casos cogerás experiencia y la próxima vez lo harás mejor. La documentación mala que hagas no te ayudará  a hacer el código mejor y el código que has hecho seguramente no se parece en absoluto a la documentación que hiciste, porque no fuiste capaz de prever las cosas correctamente.

Vamos ahora a ser programadores en grupo. Si todos son experimentados, inteligentes y buenos programadores, posiblemente les baste con unas reuniones, unos esquemas en borrador y una pequeña planificación/distribución del trabajo. Cada uno cogerá bien la idea de lo que tiene que hacer y si se comunica con frecuencia con los demás, no habrá problemas graves de integración. Ganarán tiempo si no hacen esa documentación formal que posiblemente luego no miren y al final no se parecerá a la realidad y tendrán que corregir.

Si todos los programadores o algunos de ellos son torpes, nuevamente da igual hacer o no documentación. Las partes de ellos fallarán, irán peor o darán problemas.

Incluso aunque sólo haya un programador del grupo con conocimientos y experiencia suficiente, sería perder el tiempo. El diseño y documentación debería hacerlo él y los demás dedicarse a codificar estrictamente lo que ha diseñado el programador experimentado. Pero aún así ahorraría tiempo si en vez de documentos UML se dedica a escribir los esqueletos de las clases para que sus compañeros rellenen el código. Quizás herramientas como Together que según pintas UML genera esqueletos de clases sean más útiles, pero precisamente porque generan las clases.

Según voy cogiendo experiencia en el trabajo y me voy olvidando de "idealidades" , me voy convenciendo más de que es imposible convertir esas idealidades en realidad y que los métodos ágiles son mejores. Las metodologías deben ir orientadas a las personas, no a los procedimientos, no a generar documentación por generarla. Como he leído en algún sitio, "no hay mejor documentación que el código".

Mi experiencia me dice que a un grupo de programadores se les ayuda bien dándoles una especificación clara de lo que tienen que hacer en un lenguaje informal que les resulte agradable de leer. Se les ayuda viendo el trabajo conjunto de ellos por encima, de forma que les puedes advertir de cuándo dos de ellos están haciendo cosas parecidas o cuando puede haber conflictos entre lo que están haciendo. Funcionan bien cuando cada uno tiene bien definido qué tiene que hacer y como se relaciona con lo que hacen los otros. Y lo mejor es hacer todo esto de forma ágil, día a día. No con un documento formal al principio del trabajo.

¿Conoceis algún caso en el que una documentación formal haya resuelto algún problema? ¿En el que el tiempo de hacer la documentación más el tiempo de codificar y depurar sea menor que el de pensar informalmente, codificar y depurar?.