Libro: Refactoring, Improving the Design of Existing Code

Recientemente terminé de leer este libro. Había leído algunos fragmentos sueltos, algunos refactorings del catálogo, pero resulta que el libro es mucho más que el catálogo. Toda la primera parte del libro explica diversos conceptos de refactoring y diseño orientado a objetos en general.

Entre lo que más me gustó del libro (más allá de algunos refactorings) están el capítulo 2 (Principles) y el capítulo 3 (Bad Smells in Code).

El autor del libro es Martin Fowler pero hay capítulos en los que colaboraron otros autores. Destacan las colaboraciones de Kent Beck, en esos capítulos se evidencia el mismo tono de «charla de café» que en los libros Beck (TDD by Example, Extreme Programming Explained, etc)

Dada la época en que se escribió el libro (2001), los ejemplos y las menciones a lenguajes de programación están en torno a Smalltalk, C++ y Java (versión 1.2).

Importante aclaración: hay 3 ediciones de este libro una de 2001 y otras 2 de 2018 (una es la actualización de la versión 2001 y la otra es una versión ajustada a Ruby). Yo leí la versión 2001 porque me interesaba entender el tema desde la raíz, sin embargo si alguien está interesado en leer este libro le recomiendo leer la versión 2018.

Libros de Ingeniería de Software que 2022 merecen una mirada

En los últimos años han sido publicados algunos libros sobre ingeniería de software que a mi parecer son de consideración obligada para todo docente de esta temática.

Software Engineering at Google: publicado por O’Reilly en 2020 y con versión digital (pdf) fue liberada gratuitamente hace un par de día. Cubre cuestiones de cultura, procesos y herramientas. Un punto para destacar de este libro es que tiene varios capítulos dedicados exclusivamente al tema testing. Paso a comentar. Curiosidad: el primer capítulo comienza con una cita de Borges.

The Art of Agile Development (segunda edición) escrito por James Shore y con colaboración de varios referentes. Es básicamente un libro de Extreme Programming. Su primera edición fue en 2007 y me pareció de lo mejor. El año pasado James decidió hacer una nueva edición cuyos borradores fue compartiendo en forma temprana para obtener feedback y refinarlos. Tuve la oportunidad de participar de esa iniciativa y me pareció un idea excelente. Esta nueva edición no solo actualiza algunos contenidos sino que en un punto es un «major update» ya que también incluye algunos nuevos capítulos en los que trata temas como «DevOps» y «Scaling».

Modern Software Engineering: escrito por Dave Farley(autor del ya clásico Continuous Delivery) y publicado a comienzos de 2022. A diferencia de los dos libros anteriores, este me resultó un más conceptual/filosófico. Propone un enfoque muy pragmático y contrastante con los libros clásicos de la temática como los de Pressman y Sommerville.

Trabajos en «tech», cursos cortos y carreras universitarias

«Trabajar en tecnología» es uno de los temas de moda. Trabajar en «tech» le dicen. Si bien el término «tech» podría sugerir trabajos en las diversas áreas de ingeniería y ciencias aplicadas, la realidad es que en la actualidad el término «tech» se utiliza para referirse a todas aquellas profesiones/disciplinas relacionadas al mundo IT: programación, testing, diseño gráfico/UX, administración de sistemas, datos, IoT, etc..

Este tema ha disparado diversos debates en redes sociales que incluyen posiciones muy variadas como:

  • «cualquiera puede trabajar en tech»
  • «no es necesario ir a la universidad para trabajar en tech»
  • «si querés trabajar en tech mejor no vayas a la universidad»
  • «todo lo que necesitas para trabajar en tech es perseverancia, ver videos de YouTube y practicar React»
  • «leer libros no sirve»
  • «no trabajes en tech si no amas la tecnología»
  • «aunque no te guste programar podes trabajar en tech»

Algunas de estas frases son hechos concretos mientras que otros son ideas , a mi entender, disparatadas.

En primer lugar hay un hecho: existen en la actualidad muchísimas oportunidades de trabajo en «tech». Al mismo tiempo hay incontables casos que demuestran que no es necesario contar con formación universitaria para conseguir un trabajo en «tech».

Personalmente no creo que la formación universitaria conspire contra conseguir un trabajo en «tech», al contrarío, yo creo que todo estudio, conocimiento y experiencia siempre suma. Sobre todo porque la universidad nos da mucho más que contenido. De hecho creo que es justamente «todas esas otras cosas» lo que marcan la mayor diferencia entre estudiar en la universidad o estudiar en alguna otra institución no-universitaria.

Sin embargo, si lo que uno está buscando es una oportunidad laboral y ponemos en la balanza la relación costo/beneficio en el corto plazo, es muy posible que la balanza se incline a hacia hacer una carrera corta y/o curso intensivo en lugar de una carrera universitaria. Explicito «en el corto plazo» porque una carrera universitaria demanda más tiempo que un curso o carrera corta y al mismo el retorno de la inversión de una carrera universitaria es a largo plazo.

Es posible que hoy en día, en muchas organizaciones tener un título universitario no represente un requisito de ingreso. Personalmente creo que el título universitario habilita una mayor proyección. O sea, de alguna forma conseguiste entrar, ahora el punto es hasta donde podes llegar. Ser programador («individual contributor«) puede estar bien para muchos y estoy de acuerdo que en muchos casos se puede prescindir de una carrera universitaria. Pero un rol de manager/liderazgo requiere de otras habilidades y formación que a mi parecer no son tan fáciles de conseguir con cursos informales.

No estoy seguro si es causa, consecuencia o simple coincidencia, pero este auge de las carreras en «tech» coincide con la «segmentación/especialización» de las incumbencias. Si miramos 20 años atrás la gente que trabajaba en sistemas eran literalmente analistas/licenciados/ingenieros en sistemas/computación, era gente que había pasado por una educación formal. Ea mucho menos habitual encontrarse con gente trabajando en sistemas que no hubiera pasado por la universidad. Tal vez había una porción de profesionales que no había completado su carrera pero al menos tenían algunos años de educación formal. Hoy en día la situación es bastante distinta, empieza a ser más habitual encontrar con gente que nunca hizo el intento de una carrera formal en sistemas. Es aquí donde entra en juego la «segmentación/especialización»: en general esa gente que no pasó por la educación formal en sistemas, es típicamente un especialista: desarrollador backend, tester, devops, desarrollador frontend o incluso más especialista aún «desarrollador React» (#graciasJavaScript). De hecho mientras lo escribo, dudo de que el término correcto sea «especialista», pues pienso en la medicina: el pediatra es médico, sabe de pediatría pero también tiene conocimientos generales de medicina. El desarrollador frontend ¿sabe de cuestiones generales de desarrollo (algoritmia, configuration management, testing, etc)? Tengo mis dudas, pero al margen de eso tal vez la situación actual del mercado/industria no requiere que el desarrollador frontend sepa nada más que frontend. Es aquí donde aparece una diferencia importante con las carreras universitarias de sistemas: no forman «especialistas».

Claro que el perfil de un egresado UTN es distinto al de un egresado de UBA Ingeniería, pero ambos son a los ojos del mercado/industria dos generalistas. La universidad no forma programadores, ni testers, ni devops. La universidad forma profesionales mucho más generalistas y que tienen a su vez la capacidad de auto-formarse en cualquier especialización. Este ha sido un punto clásico de tensión entre industria y academia. La industria muchas veces pretende que la universidad ya «le de gente» que sepa Cobol/React/Andriod (o la tecnología de moda) y la universidad (al menos la pública) siempre ha insistido en formar gente con conocimiento «más profundo y duradero» que la tecnología de moda. Hoy en día esto ha llevado a que (parte) de la industria ya no busca gente en la universidades y al mismo tiempo lleva a la universidades a replantearse la formación que otorga (mmm, no creo que todos en la universidad se esten planteando esto, pero si algunos).

En fin, creo que es un tema que aún da para mucha charla. La gran duda que me surge es con que nos entraremos dentro de 3 o 4 años cuando tengamos que evolucionar esas aplicaciones construidas en gran medida (o incluso en su totalidad) por gente que tuvo una forma rápida/no universitaria en sistemas.

Continuará….

Test-Driven Development for Embedded C

Ayer terminé de leer este libro. En una palabra: Excelente.

Lo había tenido en radar por mucho tiempo pero recién ahora con el envión de mi trabajo de investigación sobre TDD decidí invertir tiempo en leerlo. El autor del libro es James Grenning, uno de los 17 autores del Agile Manifesto pero lo que puso el libro en mi radar fue la charla de Grenning «TDD Guided by ZOMBIES» en la cual propone una heurística para definir el orden de la secuencia de tests al hacer TDD.

El hecho de que el título del libro haga referencia a Embedded C es en gran medida anecdótico ya que casi todo el contenido es directamente aplicable a cualquier lenguaje o eventualmente fácilmente extrapolable. Es cierto que algunos capítulos están muy centrados en C y en el desarrollo de software embebido, pero varias de las problemáticas relacionadas a la dependencia del hardware son fácilmente extrapolables a las dependencias de infraestructura que uno se encuentra en el desarrollo de aplicaciones de más alto nivel.

Al margen de TDD, creo que el libro resulta muy valioso para gente trabajando en software embebido ya que provee un conjunto de técnicas que sin duda facilitan/aceleran el desarrollo del software embebido. De hecho lo interesante de las técnicas que propone son aplicables a todo desarrollo a bajo nivel, sea o no embebido. Personalmente he trabajado muy poco con software embebido pero sí he hecho desarrollo en C/C++ y de haber sabido las técnicas mencionadas en este libro creo que habría obtenido mejores resultados.

El libro me ha parecido muy completo, explica los fundamentos de TDD, trata con suficiente detalle las cuestiones de tooling para poder automatizar pruebas en C, escribir código modular y hasta implementar mocking en C. También trata cuestiones de patrones, code smells y trabajo con código legacy.

Para mi es 10 puntos, muy recomendado.

Y un día volvimos al aula…

Todos con tapabocas, con menos distanciamiento que el recomendado pero con puertas y ventanas abiertas, el pasado lunes 21 de marzo volvimos al aula. Si bien creo que nos adaptamos muy bien a las clases online no hay como la interacción dentro del aula.

Algunas clases de MeMo2 claramente conviene que sean virtuales, principalmente aquellas que incluyen actividades de programación. En esos casos resulta muy conveniente que el alumno pueda trabajar sobre su propia computadora. Del mismo modo, hay otras clases en las que la presencialidad es un valor diferencial. Un claro ejemplo de esto es la primer clase de curso, donde conocemos y comenzamos a intentar generar una relación de confianza que facilite el proceso de enseñanza-aprendizaje.

Llevamos 2 semanas de clase y hasta el momento tengo en claro que la primera clase debería ser presencial (por lo que mencioné previamente) mientras que la segunda debería ser virtual, para que los alumnos puedan hacer el setup de sus computadoras durante el tiempo de clase y que eventualmente podamos asistirlos en vivo.

Como de costumbre, en la primera clase les pedimos a los alumnos que completen la encuesta de perfil. Una vez más nos encontramos con situaciones incómodas como ser el tener alumnos con cantidades muy dispares de materias aprobadas: en un extremo 15 y en el otro 32.

También tenemos disparidad en la edad: gente de 21 y gente de 42.

Un rubro en el que notamos un cambio respecto del histórico de la materia es en el laboral. Este cuatrimestre tenemos que el 81% de los alumnos ya trabaja en un actividad afín de la carrera, porcentaje que tradicionalmente estaba en torno al 70%.

Cierre y estadísticas del desarrollo de Fira

El lunes pasado fue la presentación formal Fira, el trabajo final de carrera de Facundo Gertsner y Matias Feld y del cual fuí director. La presentación la hicimos presencialmente en la facultad acorde a la normativa vigente pero adicionalmente fue transmitida por Twitch, donde quedó disponible para posterior visualización.

Comparto algunas métricas que pueden resultar de interés para otros alumnos:

  • 23 iteraciones de desarrollo
  • Más de 860 horas de desarrollo
  • Más de 600 pruebas automatizadas
  • ~1300 commits
  • Más de 20 GB de assets

A estos números hay que contextualizarlos considerando:

  • Desde que comenzamos a hablar sobre el trabajo con los alumnos (fines de 2020) hasta que se presentó el trabajo (mazo 2022) pasaron más de 14 meses.
  • Adicionalmente a las horas de desarrollo, los alumnos invirtieron una cantidad no menor de horas en capacitación e investigación, principalmente dedicadas a aprender Unreal (el motor sobre el que está construido el juego)

Algunas otras cuestiones que me parecen interesantes para destacar por no ser tan habituales en los trabajos finales de carrera:

  • Matias y Facundo decidieron aprovechar el trabajo final de carrera para comenzar un emprendimiento comercial. Esto resulta muy interesante pero trae también algunos desafíos como ser el hecho de regular las potenciales tensiones entre el aspecto comercial y el aspecto académico. Ejemplo: comercialmente el producto podría requerir más tiempo de desarrollo que el inicialmente estipulado; al mismo tiempo desde el punto de vista académico pretendemos que los alumnos terminen su formación en un tiempo acotado. Es justamente en este tipo de cuestiones donde el director debe guiar a los alumnos.
  • Al momento de finalización del trabajo académico, el producto no se encontraba comercialmente finalizado pero sí había tenido una validación de mercado (como director no habría podrido dar el trabajo por finalizado sin esta validación). El juego tuvo ~400 descargas de la versión beta y más de 25 mil visitas a la página de promoción.
  • El desarrollo de un juego de este tipo requiere del desarrollo de piezas artísticas (imágenes, texturas, animaciones, sonidos, música, etc). Esto implicó que parte del trabajo de los alumnos incluyera la gestión con los artistas/profesionales proveedores/creadores de estas piezas. Este trabajo de gestión es una tarea habitual para un ingeniero pero resulta algo casi inédita en un trabajo final de carrera.

Bueno, esto es todo sobre Fira. Felicito a Matias y Facundo por el trabajo realizado y les agradezco por haberme permitido ser parte de esta aventura.

El desafío del profeta en su tierra

Una hay famosa frase que dice «Nadie es profeta en su tierra» que hoy en día me resuena muy frecuentemente. Durante 10 años trabajé como consultor, mis clientes me llamaban para resolver ciertas cuestiones. En cierto modo, los equipos con los que trabajaba me venían como «el profeta» que traía «la palabra». Más allá de que nunca me sentí cómodo en ese rol, me resultaba muy curioso que en más de una ocasión mis propuestas no eran muy distintas a las que algún miembro del equipo ya había hecho. Pero claro, nadie es profeta en su tierra. Por alguna razón, si la sugerencia la viene un compañero con el que trabajas a diario, es como que la sugerencia tuviera menos valor. Pero si la sugerencia la hace alguien externo, es como si resultase de mayor valor.

Hoy en día, estoy trabajando en un equipo y me encuentro en la situación inversa a la que me encontraba antes. Propongo algo y no se le da mayor importancia, pero eso mismo lo dice un externo y es palabra santa. Pero el problema no termina aquí. Hay una gran cantidad de cuestiones (casi todas) para las que no hay un consultor externo y en esos casos me encuentro yo solito intentando convencer a mi equipo. Durísimo, en gran medida porque en el equipo somos todos «veteranos de guerra», gente con ~20 años en la profesión, cada uno con sus experiencias, mañas y gustos e intentando trabajar en un esquema bastante horizontal en lo que refiere a las decisiones técnicas.

El desafío me resulta interesante pero también desgastante y hasta frustrante por momentos. En una ocasión llegué a tener una discusión porque un colega insistía en que hacía demasiadas pruebas y que eso hacía más lento el desarrollo. Y por ello pretendía que yo escribiera menos pruebas. Yo no podía creer lo que estaba escuchando. De hecho inicialmente no lo entendí. En un momento me sentí como Fantino diciendo: «Pará pará pará, ¿vos me estas diciendo que queres que yo escriba menos pruebas?». Naturalmente al hacer TDD uno suele escribir más pruebas que cuando se agregan las pruebas a posterior, con lo cual podría decirse que es cierto «hago muchas pruebas». Pero de ninguna forma creo que eso haga más lento el desarrollo, al menos no en un grado relevante. O sea, es cierto que si hiciera menos pruebas podría llevarme menos tiempos ¿pero cuanto menos? ¿5 horas en lugar de 6? No creo que esa diferencia en tiempo justifique «romper» mi proceso. Trabajo de una forma que me da seguridad y me permite trabajar de una forma eficiente, confiable y predecible.

Menos mal que uno ya está curtido y muchas balas no le entran, porque este tipo de cuestiones no hacen más que poner en tela de juicio las aptitudes personales y podrían destruir la autoestima y motivación de gente más sensible.

Por suerte, más allá de las diferencias profesionales, es toda gente bien intencionada y hablando (casi siempre)se puede logran consenso, pero no es fácil.

En fin, esta situación me llevó a buscar ayuda, por un lado hablando con algunos colegas y por otro buscando en biblioteca donde encontré un librito muy útil aunque no muy popular: «Driven Technical Change» (de Terrence Ryan) que me dió algunas ideas que estoy probando. En un par de semanas (o meses) les cuento que tal me va.

Presentación de Fira, un videojuego con raíces académicas

Comenzamos las primeras conversaciones a fines de 2020. El primer mail en la lista de correo del equipo data de febrero de 2021. Presentamos la propuesta formal a la comisión curricular a comienzos de junio 2021. La primera iteración de desarrollo comenzó el 23 de agosto de 2021. Fueron un total de 24 iteraciones. Fueron más de 800 horas de desarrollo a las que hay que sumar el tiempo invertido en estudio/capacitación (los chicos tuvieron que aprender Unreal) que se invirtió antes del inicio formal del desarrollo.

Finalmente, este lunes 28 será la presentación formal del trabajo y con ello Facundo y Matias completarán su carrera de Ingeniería en Informática. La presentación será a las 17:00 hs. en la sede Paseo Colón de la Facultad de Ingeniería y también será transmitida por Twitch por el canal del departamento de computación.

¡Nos vemos!

Diseño ágil con TDD

Ayer terminé de leer la edición 2020 de este libro escrito por Carlos Blé. Ya había leído (parcialmente) la edición anterior allá por 2011, pero el año pasado Carlos tuvo la gentileza de regalarme esta nueva versión (¡gracias!) y me comentó que tenía modificaciones importantes así que aproveché que estaba estudiando TDD para mi tesis de maestría y decidí leer el libro de punta a punta.

En una oración: el libro me gustó mucho. Sentí mucha afinidad en la forma de trabajo que relata y también en los consejos que el autor ofrece a título personal.

Encontré un punto de contraste interesante con otros libros de TDD. Creo que la mayoría de los libros que he leído sobre TDD (al igual que la mayoría de charlas, cursos y videos sobre TDD que he visto/presenciado) tienen un tono muy extremo, muy «todo o nada», muy «esto es así» (creo que yo mismo muchas veces peco con ese tono) pero este libro (y creo que Carlos en general) tiene un tono «de mesura», un matiz que me resultó muy ameno y que imagino puede resultar mucho más efectivo a la hora de intentar convencer a alguién de utilizar TDD.

Otra cuestión destacable del libro es no se queda en la explicación de la técnica sino que también trata sobre el uso de la técnica en distintos contextos «reales» de aplicación: en qué tipos de proyectos utilizarla TDD, cómo utilizar TDD en proyectos de código legado, como empezar a utilizar TDD, etc. Trata también la clásica rivalidad de los estilos Chicago vs London de sin necesariamente tomar partido (menciona su preferencia pero no la considera una bala de plata para todo contexto).

Otro punto no menor a destacar es que es uno de los pocos libros (¿acaso el único?) de TDD en castellano.

Creo que es un recurso interesante para aprender TDD, tal vez no entra en tanto detalle como otros libros de TDD pero al mismo cubre muchas más cuestiones, o sea: va más en anchura que en profundidad lo cual me parece bueno para un libro introductorio.

El libro está disponible en formato digital en LeanPub. Muy recomendado.

Desafíos en la formación de un equipo docente

Hace unos 20 años que estoy en la docencia. En todo ese tiempo he sido parte de varios equipos docentes en distintas materias e instituciones. Hace unos 10 años tuve por primera vez un curso a mi cargo. Pero recién en 2019 estuve en la situación de conformar un equipo estable de más de 2 personas. Hasta ese momento siempre había dictado las materias a mi cargo yo solo o en compañía de otro docente. Estando solo no había opciones, todo el trabajo debía hacerlo yo mismo. Siendo 2 y ambos con muy similar experiencia y perfil, en general dividimos el trabajo en parte iguales apuntando a que ambos podamos dictar todos los temas de la materia. No hacemos distinción entre teoría y práctica porque en la dinámica de nuestra materia no existe tal distinción.

Pero hoy en día, en el equipo de la materia a mi cargo en FIUBA, somos 10 personas con distintos perfiles y experiencia. Graduados, estudiantes, rentados y no-rentados. Esto, a mi entender, hace que la distribución de tareas no sea tan simple. Me pregunto si alguna capacitación para docentes incluirá este tipo de cuestiones: armado de una equipo docente. Me late que no. Como docente responsable formalmente a cargo del curso, soy responsable de todo lo que ocurre en la materia. Claro que puedo delegar tareas, pero si algo no van bien, «me vendrán a buscar a mi».

Hay dos cuestiones que me resultan muy desafiantes en este contexto:

  1. De cara a los alumnos el mayor desafió que veo es la uniformidad. Siendo varias personas en el rol docente dentro de un mismo curso uno esperaría cierta uniformidad de criterios. Obviamente que puede haber diferencia de matices pero hay un conjunto de cuestiones centrales en las que todos deberíamos estar alineados. En este contexto entran los criterios de evaluación. Debería ser irrelevante para los alumnos que docente realiza la corrección de una entrega pues todos deberíamos aplicar el mismo criterio y por ende el resultado debería ser el mismo.
  2. De cara hacia el propio equipo docente encuentro un desafió importante en la distribución de tareas. Dentro del curso hay distintos tipos de tareas que varían en dedicación, responsabilidad y experiencia/conocimiento. Una cuestión que condimenta este tema es el hecho de que parte del equipo docente no está rentado. Esta situación de docentes no rentados es una práctica habitual en las universidades públicas argentinas, pero excede este artículo, ya lo trataré en otro.

Respecto de la primera cuestión creo que he encontrado una estrategia efectiva con la que estoy conforme. Respecto de la segunda, venimos operando de una forma que funciona pero que no termina de convencerme.

Al margen de estas cuestiones operativas formar un equipo implica muchas más cosas, más complejas y más profundas. Cuestiones de principios, solidaridad, vínculos, valores, sentido de pertenencia, etc, etc. Estas cuestiones de índole «más humano» requieren tiempo y oportunidades de interacción, dos elementos escasos cuando todos los miembros del equipo tiene una dedicación muy acotada en el contexto de la materia. Yo personalmente como responsable del curso dedico entre 5 y 10 horas semanales, pero un colaborador no rentado difícilmente dedique más de 5 horas por semana. Y como condimento adicional le sumamos la situación de pandemia que nos quitó el vernos en persona, un condimento importante para establecer vínculos personales.

Continuará…