Alrededor de seis horas a la semana invierten los profesionales informáticos en corregir los errores y deficiencias de las conocidas como deudas técnicas.
#1 Lidiar con la deuda técnica es parte del desarrollo.
En mi equipo tenemos claro cuánta tenemos, por qué la tenemos, y cuando toca pelearse con ella casi siempre elegimos romper con ello y hacerlo bien.
Si HOY rompo y arreglo mañana mis tiempos de desarrollo serán mucho más bajos.
No sé cuantas veces hemos dicho "sin prisa, esto lo tenemos que arreglar", pero no son pocas.
La cantidad de código mierda que se hace en una startup sus primeros dos años es alta. Necesitarás muchos más para ir quitándotela poco a poco.
Por cierto, no creo que en una empresa que se acepte y se permita el código legado "porque hay prisas" haya muy buenos programadores. Escaparían de ahí rápido.
Cuando tienes una solución sobre la mesa rápida y que no escala ni es especialmente legible. Y otra que sí escala y es simple y legible pero cuesta el doble (por decir algo), en una startup en sus inicios necesitas elegir la primera para aportar valor inmediato a los clientes.
El que pierda sólo 6h a la semana es porque no trabaja en una cárnica.
"a menudo por hacerlo rápido o por no haber llevado a cabo un buen control de calidad antes de lanzarlo" y más a menudo porque es código hecho por becarios sin supervisión.
Al final cuando ya estás curtido aprendes a lidiar con el legacy code. Mayormente, si está mal programado pero funciona, lo dejas y metes un nuevo desarrollo paralelo que se va a implementar desde ese momento en adelante y ya se implementará en la parte mal programada cuando haya que tocarla.
#6 Pues estas metiendo aún más código legado. Tú solución en sí misma es parte del problema.
Dentro de un tiempo, cuando llegue otro, dirá "qué mierda, está duplicado" y siguiendo el mismo patrón... lo triplicará.
Lidiar con el código legado es poner tests si es posible, si no es posible levantar la mano y decir "igual rompo esto, agarraos la entrepierna" y cambiarlo.
#10 "el ciiiiiiiiiiiiiiiclo sin fiiiiiiiiiiiiiiiin" 🎶
Es parte del problemaa medias. En proyectos pequeños o medios puedes refactorizar y avisar de que se puede romper algo (si hay tiempo, que es otra). En proyectos grandes ni se te ocurra, los efectos colaterales pueden ser brutales (yo lo vi varias veces y ninguna gracia). En los grandes, cuando pasa lo que yo te digo, si ves que hay algo sin referenciar, obviamente está obsoleto, y te lo puedes cargar. Mientras no te cargas uno de los dos usas la última versión.
Lo de los test, para mi, es harina de otro costal. No estuve en ningún proyecto según TDD, y en los únicos proyectos en los que estuve que tenían test fue porque los pidió el cilente específicamente y mi jefe de aquellas nos pidió específicamente que fuesen "cualquier chorrada de test que pasase"
#16 +1 Claro, si el proyecto es grande y hay bastante deuda técnica, toca sobrevivir. Haces lo que sea, que funcione, y arreu
Los tests... No tienes que hacer TDD. Las últimas veces que escuché sobre TDD se dio como una metodología fallida. Pero muchas veces puedes hacer tests que te ayudan a probar.
Por ejemplo, los unitarios. Si el desarrollo es front-back con formularios y poco más pues no vas a hacer muchos. Pero si tiene mucha lógica de negocio es una tontería no.hacerlos, ¿cómo pruebas si no todos los casos? ¿a mano uno a uno?
Una vez tuve que hacer la IA de un Parchís, cómo me lamento no haberlo hecho con tests. Era bastante prongadete y lo probaba forzando situaciones en el.juego y veía qué es lo que hacía la IA. Menudo trabajazo más chorra.
#17 No me refería a que tuvieses que hacer TDD. Sé de empresas dónde se estuvo usando TDD como norma general, pero a mi no me tocó nunca. Cuando me tocó hacer test para algún proyecto (unitarios, sin seguir TDD) fue porque el cliente los pedía específicamente y mi jefe de aquellas nos dijo específicamente que hiciésemos cualquier chapuza que resultase en test pasado. En mi experiencia, si el cliente no los pide específicamente nunca se hacen porque nunca hay tiempo, y nunca hay tiempo porque los plazos que imponen son -casi siempre- absurdos.
#19 Efectivamente. Y otra cosa que creo que ayuda mucho son las revisiones de codigo en un Pull Request, por ejemplo.
Solo el hecho de saber que el resto del equipo va a ver y revisar tus mierdas, hace que uno intente que el codigo este bien. Aparte de que cuando alguien se cantea con alguna cosa, se detecta rapido el tufo a podrido.
Estamos en la época dorada de los hackers, que explotarán las N mil vulnerabilidades de todo software en web y móvil. Serán ataques muy particulares y destructivos. Las inyecciones SQL por ejemplo pueden ser devastadoras.
#9 El código legado tiene mucho que ver porque fue construido en su época bajo ciertas condiciones tecnológicas y muchos lo están forzando a adaptarlo a los tiempos actuales. Por ejemplo, software creado en el paradigma cliente-serrvidor, donde es una aplicación nativa Windows, con formularios hechos con componentes de Windows y quieren moverla a Web. Algo tan sencillo como leer un campo numérico, es supremamente fácil en Windows, hay componentes para capturar números de arrastrar y soltar. En Web hasta la adopción general de HTML5, no existía el campo numérico, todos eran campos texto y había que validarlo con jQuery. Aún así, si la información se va por la URL (el método GET), pueden colarle texto donde debería ir números. En esos viejos tiempos, el código legado confiaba muchísimo en las validaciones de los formularios Windows, pero quitando eso, al pobre código legado le pueden llegar datos envenenados.
Se habla de la deuda técnica como algo malo, pero bajo ciertas circunstancias es algo necesario, solo hay que tener claro que la deuda técnica es como la deuda bancaria: en futuro si o si hay que pagarla y con generosos intereses
Comentarios
Casi no hay tiempo para hacer los desarrollos como para preocuparse por la deuda técnica.
#1 Lidiar con la deuda técnica es parte del desarrollo.
En mi equipo tenemos claro cuánta tenemos, por qué la tenemos, y cuando toca pelearse con ella casi siempre elegimos romper con ello y hacerlo bien.
Si HOY rompo y arreglo mañana mis tiempos de desarrollo serán mucho más bajos.
No sé cuantas veces hemos dicho "sin prisa, esto lo tenemos que arreglar", pero no son pocas.
La cantidad de código mierda que se hace en una startup sus primeros dos años es alta. Necesitarás muchos más para ir quitándotela poco a poco.
Por cierto, no creo que en una empresa que se acepte y se permita el código legado "porque hay prisas" haya muy buenos programadores. Escaparían de ahí rápido.
#11 en startups es normal escribir código rápido sabiendo que lo vas a reemplazar varias veces, seguramente igual que todo el producto.
Eso no quiere decir que sea una mierda de código.
#12 Puede que incluso peor
Cuando tienes una solución sobre la mesa rápida y que no escala ni es especialmente legible. Y otra que sí escala y es simple y legible pero cuesta el doble (por decir algo), en una startup en sus inicios necesitas elegir la primera para aportar valor inmediato a los clientes.
El cálculo de "dos años" ha sido a ojímetro.
Solo 6 horas a la semana. Yo hay semanas que dedico al desarrollo 6 horas y no seguidas que es lo peor, te rompe el ritmo.
El que pierda sólo 6h a la semana es porque no trabaja en una cárnica.
"a menudo por hacerlo rápido o por no haber llevado a cabo un buen control de calidad antes de lanzarlo" y más a menudo porque es código hecho por becarios sin supervisión.
Al final cuando ya estás curtido aprendes a lidiar con el legacy code. Mayormente, si está mal programado pero funciona, lo dejas y metes un nuevo desarrollo paralelo que se va a implementar desde ese momento en adelante y ya se implementará en la parte mal programada cuando haya que tocarla.
#6 Pues estas metiendo aún más código legado. Tú solución en sí misma es parte del problema.
Dentro de un tiempo, cuando llegue otro, dirá "qué mierda, está duplicado" y siguiendo el mismo patrón... lo triplicará.
Lidiar con el código legado es poner tests si es posible, si no es posible levantar la mano y decir "igual rompo esto, agarraos la entrepierna" y cambiarlo.
#10 "el ciiiiiiiiiiiiiiiclo sin fiiiiiiiiiiiiiiiin" 🎶
Es parte del problemaa medias. En proyectos pequeños o medios puedes refactorizar y avisar de que se puede romper algo (si hay tiempo, que es otra). En proyectos grandes ni se te ocurra, los efectos colaterales pueden ser brutales (yo lo vi varias veces y ninguna gracia). En los grandes, cuando pasa lo que yo te digo, si ves que hay algo sin referenciar, obviamente está obsoleto, y te lo puedes cargar. Mientras no te cargas uno de los dos usas la última versión.
Lo de los test, para mi, es harina de otro costal. No estuve en ningún proyecto según TDD, y en los únicos proyectos en los que estuve que tenían test fue porque los pidió el cilente específicamente y mi jefe de aquellas nos pidió específicamente que fuesen "cualquier chorrada de test que pasase"
#16 +1 Claro, si el proyecto es grande y hay bastante deuda técnica, toca sobrevivir. Haces lo que sea, que funcione, y arreu
Los tests... No tienes que hacer TDD. Las últimas veces que escuché sobre TDD se dio como una metodología fallida. Pero muchas veces puedes hacer tests que te ayudan a probar.
Por ejemplo, los unitarios. Si el desarrollo es front-back con formularios y poco más pues no vas a hacer muchos. Pero si tiene mucha lógica de negocio es una tontería no.hacerlos, ¿cómo pruebas si no todos los casos? ¿a mano uno a uno?
Una vez tuve que hacer la IA de un Parchís, cómo me lamento no haberlo hecho con tests. Era bastante prongadete y lo probaba forzando situaciones en el.juego y veía qué es lo que hacía la IA. Menudo trabajazo más chorra.
#17 No me refería a que tuvieses que hacer TDD. Sé de empresas dónde se estuvo usando TDD como norma general, pero a mi no me tocó nunca. Cuando me tocó hacer test para algún proyecto (unitarios, sin seguir TDD) fue porque el cliente los pedía específicamente y mi jefe de aquellas nos dijo específicamente que hiciésemos cualquier chapuza que resultase en test pasado. En mi experiencia, si el cliente no los pide específicamente nunca se hacen porque nunca hay tiempo, y nunca hay tiempo porque los plazos que imponen son -casi siempre- absurdos.
Eso es un problema del yo del futuro.
En mi equipo yo siempre he dicho: si es nuevo, hazlo bien. Si el codigo es antiguo y hay que tocarlo, dejalo mejor que estaba.
Sobre todo evitar eso de "como ya es una mierda le meto otra mierda mas"
#13 https://devtia.com/post/codigo-limpio-la-regla-del-boy-scout
#19 Efectivamente. Y otra cosa que creo que ayuda mucho son las revisiones de codigo en un Pull Request, por ejemplo.
Solo el hecho de saber que el resto del equipo va a ver y revisar tus mierdas, hace que uno intente que el codigo este bien. Aparte de que cuando alguien se cantea con alguna cosa, se detecta rapido el tufo a podrido.
1 dia, jaja?
Un sprint, por lo menos.
you know what I mean,,,
Estamos en la época dorada de los hackers, que explotarán las N mil vulnerabilidades de todo software en web y móvil. Serán ataques muy particulares y destructivos. Las inyecciones SQL por ejemplo pueden ser devastadoras.
#8 ¿Y eso que tiene que ver con el código legado?
#9 El código legado tiene mucho que ver porque fue construido en su época bajo ciertas condiciones tecnológicas y muchos lo están forzando a adaptarlo a los tiempos actuales. Por ejemplo, software creado en el paradigma cliente-serrvidor, donde es una aplicación nativa Windows, con formularios hechos con componentes de Windows y quieren moverla a Web. Algo tan sencillo como leer un campo numérico, es supremamente fácil en Windows, hay componentes para capturar números de arrastrar y soltar. En Web hasta la adopción general de HTML5, no existía el campo numérico, todos eran campos texto y había que validarlo con jQuery. Aún así, si la información se va por la URL (el método GET), pueden colarle texto donde debería ir números. En esos viejos tiempos, el código legado confiaba muchísimo en las validaciones de los formularios Windows, pero quitando eso, al pobre código legado le pueden llegar datos envenenados.
Se habla de la deuda técnica como algo malo, pero bajo ciertas circunstancias es algo necesario, solo hay que tener claro que la deuda técnica es como la deuda bancaria: en futuro si o si hay que pagarla y con generosos intereses
Un día la semana? Un día al día, y así estamos con las horas extra gratuitas.