Según diferentes estudios los desarrolladores dedicamos al menos un 50% de nuestro tiempo a "leer código".
Sin embargo, cómo leemos código es un tema muy poco tratado. La mayor parte de confs, libros, posts y conversaciones se centran en la construcción y no en la comprensión.
Sin embargo, cómo leemos código es un tema muy poco tratado. La mayor parte de confs, libros, posts y conversaciones se centran en la construcción y no en la comprensión.
Siendo la comprensión del código la actividad más cara en el desarrollo de software, es sorprendente la poca atención que recibe.
Ni siquiera desde #SoftwareEconomics veo suficiente atención sobre estos temas. Quizá @artolamola tenga alguna explicación o refs que no conozco.
Ni siquiera desde #SoftwareEconomics veo suficiente atención sobre estos temas. Quizá @artolamola tenga alguna explicación o refs que no conozco.
Si leemos el código es como un medio para ayudarnos en la toma de decisiones respecto de sistemas de software.
Creo que tiene sentido que empecemos a entender el desarrollo de software más como una actividad de toma de decisiones que de construcción.
Creo que tiene sentido que empecemos a entender el desarrollo de software más como una actividad de toma de decisiones que de construcción.
Además, necesitamos mejores formas de entender un sistema de software, es decir, de tomar decisiones, que leer el texto de su código fuente.
El tamaño del software crece exponencialmente (según estudios con TCAC entre 1.11 y 1.29), pero nuestra velocidad de lectura es lineal.
El tamaño del software crece exponencialmente (según estudios con TCAC entre 1.11 y 1.29), pero nuestra velocidad de lectura es lineal.
Recuerdo que en la @pamplonaswcraft 2019 tuvimos un debate sobre este tema llamado "Software habitable. ¿Cómo lo leemos?".
Entre otras cosas hablamos sobre #MoldableDevelopment y creo que actualmente sigue siendo una de las pocas respuestas serias a esta problemática.
Entre otras cosas hablamos sobre #MoldableDevelopment y creo que actualmente sigue siendo una de las pocas respuestas serias a esta problemática.
La tesis de #MoldableDevelopment es que nuestras herramientas deberían ofrecernos mejores respuestas para comprender un sistema de software.
Como las preguntas serán muy contextuales, no podemos basarnos en respuestas genérica y precocinadas como las de los IDEs actuales.
Como las preguntas serán muy contextuales, no podemos basarnos en respuestas genérica y precocinadas como las de los IDEs actuales.
La propuesta es que como parte del flujo de desarrollo, tanto devs como no técnicos, serán capaces de extender fácilmente sus herramientas (moldearlas) para obtener las respuestas adecuadas a su problema (dominio) y poder tomar decisiones.
La clave está en la facilidad (ergo coste) de esas extensiones.
El tamaño medio de las más de 700 extensiones que incluye GToolkit (la implementación de #MoldableDevelopment que ha desarrollado @girba y su equipo) es de 12 LoC.
El tamaño medio de las más de 700 extensiones que incluye GToolkit (la implementación de #MoldableDevelopment que ha desarrollado @girba y su equipo) es de 12 LoC.
Si te ha interesado el tema, aquí dejo referencias:
* Charla @girba:
* Tesis de @Chis_Andrei: scg.unibe.ch/archive/phd/ch…
* Ejemplo de uso en nuestra librería Bloom Filters: osoco.es/thoughts/2019/…
* Charla @girba:
* Tesis de @Chis_Andrei: scg.unibe.ch/archive/phd/ch…
* Ejemplo de uso en nuestra librería Bloom Filters: osoco.es/thoughts/2019/…
