Para el TP1 de Algo3 vamos a pedir a los alumnos que logren 100% de cobertura s0 en el código entregado. Si bien durante la clase explicamos como medir la cobertura usando Pharo, surgieron algunas consultas en la lista de correo que me motivaron para grabar un breve screencast mostrando esta cuestión. El screencast está disponible aquí.
Espero les resulte útil.
¡Que pregunta! Se podrán imaginar que siendo profesor de una materia con este nombre mi respuesta es sí.
Pero no todo el mundo piensa lo mismo. Una de las personas que cuestiona la existencia de dicha disciplina no es más ni menos que David Parnas, quien el pasado octubre publicó un artículo titulado: «Software Engineering – Missing in Action: A Personal Perspective». En dicho artículo Parnas repasa brevemente el surgimiento del término ingeniería de software y expone ciertas razones por la cuales duda de que el desarrollo de software tenga el caracter de ingenieria. El artículo me resultó por demás interesante, ya que también toca a la pasada cuestiones como ingenieria vs. ciencia, la estructura de la profesión y la educación del profesional del software.
Sumando a este argumento, mi colega Gabriel Falcone me compartió hace un tiempo este video de la conferencia Scotland Ruby, donde disertante afirma:
«Software engineering as it is taught in universities simply does not work. It does not produce software systems of high quality, and it does not produce them for low cost. Sometimes, even when practiced rigorously, it does not produce systems at all. That is odd, because in every other field, the term engineering is reserved for methods that work.»
¡uffff! Duro, pero bastante realista. En realidad si uno mira el video completo (unos 45 minutos), se encuentra que en realidad el punto de este individuo es que lo que realmente funciona para construir software son los métodos ágiles y que mucha gente tilda a los métodos ágiles como «anti-ingenieriles». A pesar de no compartir algunos de los puntos expuestos en este video, la sesión me gustó y la recomiendo (de hecho he sacado algunos bullets para mis clases).
Personalmente creo que existe la ingenieria de software como disciplina, pero con una concepción distinta a la que le dan muchas universidades (en general a nivel académico hay cierta «creencia» de que por llamarse ingenieria debe tener una fuerte carga de ciencia básica,cosa que no comparto). Al mismo tiempo creo que es aún una disciplina joven ya que las prácticas/métodos que aumentan la probalidad de éxito de los proyectos – y que por ende podrian poner a la ingenieria de software a la altura de las otras ingenierias- recien se han comenzado a popularizar en los últimos 5 años.
Definitivamente algunos meses habría pasado hambre y creo que algunos otros no habrían cobrado ni un solo peso, ja!
Más allá de lo chistoso (o lo triste) del título, este post es una continuación de otro que escribí hace un par de dias sobre esta misma temática. En dicho post compartí algo de teoría junto con algunos links interesantes (el de artículo de Marrick es excelente) y en los cuales he encontrado justificación para algunas de las ideas que compartiré a continuación. Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en el tema de la cobertura de código lo cual me ha llevado a una reflexión profunda sobre el tema.
Si desarrollamos nuestra aplicación siguiendo un enfoque TDD extremo, siempre mantendremos un alto grado de cobertura, pues solo agregaremos código cuando haya una prueba que lo ejercite.
Si procuramos seguir las buenas prácticas de diseño la relación entre nuestros componentes será por medio de interfaces, lo cual nos permitirá utilizar mocking y asi superar la infantil excusa «No lo puedo testear porque tiene dependencias».
Si nuestros métodos son cohesivos y hacen usa sola cosa, entonces será más simple testearlos.
Si hechamos mano del polimorfirmo, seguramente podamos evitar algunos «if» en nuestro código lo cual también ayudará con la cobertura.
Para cerrar este post, les comparto una situación que viví hace unos dias. Resulta que una de las personas que estuve capacitando durante la semana pasada hizo una demo de la aplicación que desarrolló como parte de la capacitación. La demo venia bien y en un momento le pedimos que mostrara una funcionalidad particular que no habia sido mostrada. Resulta que cuando la va a mostrar, la aplicación ¡pincha!, ja! a lo que le pregunto: ¿y los tests? adivinen….no había tests para esa funcionalidad. Y cuando pregunto por el porcentaje de cobertura de la aplicación, resulta que no superaba el 40%. ¡Que mejor forma de ilustrar la importancia de estas cuestiones! Espero que este colega haya aprendido la lección.
Por último quiero agradecer a David Frassoni quien la semana pasada me dió la idea de escribir este post.
El siguiente post de esta serie lo dedicaré a analizar las implicancias/consecuencias de tener una alta cobertura y de definir un shipping criteria en base al mismo.
Continuará…
Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en la cobertura de código. Esto me ha motivado a compartir algunas ideas sobre este tema y para setear el contexto y las expectativas, voy comenzar este post compartiendo algunos conceptos básicos y luego en otro post voy a volcar algunas ideas/experiencias personales.
¿Qué es la cobertura de código?
La cobertura código es la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas. O sea, ejecuto las pruebas de mi aplicación y si hay alguna línea de mi código que nunca fue ejecutada en el contexto de las pruebas, entonces dicha línea no está cubierta. Si mi código consta te 100 líneas y solo 50 líneas están siendo ejecutadas al correr las pruebas, entonces mi cobertura es del 50%. La pregunta que viene a continuación es:
¿Qué beneficio tiene medir la cobertura? y más específicamente ¿que beneficios tiene tener una alta cobertura?.
Una respuesta genérica podría ser que aumenta la calidad de mi aplicación. Siendo más concreto podría decir que si tengo una alta cobertura, significa que gran parte me mi código está siendo probado y por consiguiente podria tener cierta certeza sobre el correcto funcionamiento de mi aplicación. Al mismo tiempo medir la cobertura podria ayudarme a detectar código innecesario en mi aplicación, ya que no se ejecuta.
La pregunta que surge a continuación es:
¿Qué porcentaje de cobertura es suficiente?
La respuesta no es única, existen distintos criterios y pueden resultar bastante polémicos por eso voy a tratarlos en otro post. Pero por ahora solo diré que para SimpleCov, lo idea es de al menos 90% y en Southworks soliamos perseguir el 80%.
¿Una cobertura del 100% asegura que mi código no tiene bugs?
De ninguna manera, una cobertura del 100% solo nos dice que todo nuestro código está siendo cubierto por pruebas, pero puede que las pruebas no esten contemplando algunas situaciones, o sea, me falta pruebas.
¿Qué necesito para poder medir la cobertura?
En primer lugar es necesario escribir pruebas y en segundo lugar contar con alguna herramienta que permita medir la cobertura.En la actualidad los lenguajes más populares cuentan con herramientas para medir la cobertura. Si trabajamos con C# y escribimos nuestras pruebas con MSTest, entonces el Visual Studio nos ofrece la posibilidad de habilitar la medición de cobertura de código. Si en cambio trabajamos con Ruby, podríamos utilizar RSpec para escribir nuestras pruebas y SimpleCov para medir la cobertura.
Esto es todo por ahora, les algunos links interesantes sobre el tema:
En el siguiente post voy hacer algunos comentarios sobre estos artículos.
Durante el año pasado mientras estudiaba para las materias que cursé en la maestría de la UNLP, se me ocurrieron dos artículos que me gustaría desarrollar para presentar en algún congreso y casualmente recien empezado el año tengo tres posibles eventos donde presentarlos.
El primero es ArgenCon, organizado por la sección argentina de IEEE. El mismo se desarrollará del 9 al 13 de Junio en Córdoba. La fecha límite para el envío de trabajos es el 15 de Marzo.
El segundo evento es la edición 41 de las JAIIO, este año organizadas en conjunto con la UNLP entre el 27 y 31 de Agosto. La convocatoria de trabajos trabajos esta abierta hasta el 30 de Abril.
Finalmente el tercer evento que tengo en el radar es Foro Mundial de Educación en Ingenieria (WEEF: World Engineering Education Forum). Sinceramente nunca había nunca había escuchado hablar de este evento (tal vez porque no siempre se realiza en Argentina). El mismo será organizado por UTN y se desarrollará en Buenos Aires del 15 al 18 de Octubre. La fecha límite para el envio de trabajo es el 2 de Marzo.
Volviendo a los trabajos que tengo en mente, el primero es sobre el enfoque que estoy utilizando en UNQ para dictar ingeniería de software. El otro es sobre algunas ideas que he venido madurando para la enseñanza de la programación en los cursos introductorios de programación.
Finalmente el lunes pasado cerramos la materia. Entregué las notas he hicimos una retrospectiva. Si bien la materia no salió exactamente como la había planeado, estoy conforme con el resultado. Creo que logré transmitir conceptos importantes y algunas herramientas concretas para el desarrollo profesional, la organización personal y el trabajo en equipo. Comencé el cuatrimestre con 15 alumnos y lo terminé con 12. Por lo que pude hablar con algunos alumnos, aquellos que dejaron la materia lo hicieron principalmente porque tenían otra expectativa respecto de la dedicación que la materia requería. Incluso los alumnos que completaron la materia, también coincidieron en este punto. Esto me parece totalmente entendible, pues hubo efectivamente un cambio de docente y con el ello también un cambio de dinámica. Varios alumnos venian con la expectativa de una materia más tradicional: asistir a clase, realizar un serie de trabajos prácticos y rendir un examen. En lugar de ello se encontraron con tareas semanales, muchas lecturas y varios entregables. Todo esto de forma constante a lo largo de todo el cuatrimestre. Y fue explícitamente así, pues a mi entender los proyectos se hacen día a día TODOS los días, de forma constante. Al mismo tiempo les pedí a los alumnos que dieran visibilidad constante y temprana, avisando cada vez que iban a faltar a clase o llegar tarde. Los alumnos que completaron la materia, comprendieron el objetivo de este pedido y reconocieron su importancia. La importancia no radica en avisar si faltan a la materia, sino en generar el hábito, hacer que los alumnos se acostumbren a dar visibilidad. En el contexto de toda actividad uno puede sufrir atrasos, imprevistos, etc, pero lo que NO puede hacer bajo ningún punto de vista es no dar visibilidad.
En fin, por ahora, esto es todo, más adelante comentaré algunas conclusiones de la retrospectiva.
Finalmente les dejo la foto de mi primera promoción de Ingeniería de Software, ¡felicitaciones estudiantes! (y gracias por aguantarme)
(parte 4 de la serie: Ingeniería de Software en UNQ)
Pasó la primer semana, o sea, las primeras dos clases. En el curso hay 15 inscriptos, pero solo 14 asistieron a clase. En su gran mayoría sin experiencia laboral en desarrollo de software, pero con sólidos conocimientos de programación y conocimientos al menos básicos en temas relacionados como patrones de diseño, base de datos y uso de controladores de versiones.
Durante esta primera semana el foco estuvo en establecer las expectativas del curso, entender el contexto profesional de un técnico en programación y algunas características y fundamentos de la ingeniería de software. El libro de la semana fue The Mythical Man-Month de Fred Brooks.
Por último, al finalizar la primera clase pedí feedback con la clásica técnica de las caritas y este fue el resultado.
continuará…
(parte 3 de la serie: Ingeniería de Software en UNQ)
Este es el nombre formal de la materia que voy a dictar el próximo cuatrimestre en UNQ. La materia está en el contexto de la Tecnicatura en Programación Informática, una carrera de pre-grado de 6 cuatrimestres de duración cuyo objetivo es:
Formar técnicos/as capaces de elucidar e implementar soluciones en un amplio espectro de problemas asociados a las tareas de diseño/programación dentro del desarrollo de software, en un alcance razonable para un egresado/a pre-universitario, siendo capaces de aprovechar los conceptos aprehendidos en la carrera para pensar y resolver situaciones concretas, y basados en una amplia experiencia práctica obtenida durante el recorrido de la carrera.
He resaltado con negritas algunos puntos importantes que se reflejan claramente en el dictado de las materias, según me he hablado com docentes y alumnos.
Si bien en la UNQ no existen correlatividades, en el plan sugerido de cursada, la materia está ubicada en el 4 to cuatrimestre de la carrera. Al mismo tiempo, la inscripción en la materias se realiza personalmente con un docente tutor, quien tiene la posibilidad de no anotar al alumno en un materia, si considera que el alumno no está en condiciones de cursarla. El punto es que en general, los alumnos que llegan a cursar esta materia, vienen con sólidos conocimientos de en lo que respecta a programación orientada a objetos, patrones, algoritmia y base de datos, pero sin conocimientos en cuanto a requerimientos, arquitectura, gestión de proyectos y demás cuestiones «blandas» de la ingeniería de software. Otro punto a considerar es que en el resto de las materias de la carrera, los alumnos siguen aprendiendo cuestiones técnicas como programación concurrente, construcción de interfaces de usuario y tienen una materia llamada Desarrollo de aplicaciones que auspicia en cierto modo como materia integradora. Esto hace que Elementos de Ingeniería de Software sea la única materia en la que ven cuestiones generales de ingeniería de software que no son de índole técnica.
Luego de haber analizado todas estas cuestiones y haber consultado con varios profesores, ya tengo una idea como encarar la materia. Como libros de texto voy a utilizar Software Engineering de Pressman y The Art of Agile Development de Shore. Dado el contexto de la materia, no voy enfocarme en cuestiones de management (aunque si las vamos a ver) si no más bien en cuestiones de self-management que todo programador tiene que poder hacer:
Para todos estos puntos voy a tomar como referencia complementaria el Personal Software Process de Humphrey. Tengo la intención de que estos temas no queden solo en la teoría y para ello planeo hacer un par de coding dojos/katas y algunas otras actividades de índole práctica para poner justamente en práctica cada uno de los temas que vayamos viendo.
Por otro lado, también voy a dar algunas cuestiones un poco más técnicas relacionadas a arquitectura, atributos de calidad y diseño de alto nivel, principalmente porque no hay ninguna otra materia en la que se vean.
Finalmente hay una serie de temas complementarios que quiero dar como ser:
Para todos estos temas complentarios y también para algunos de los temas principales, pienso convocar a algunos profesores invitados. En particular quiero invitar a gente de la industria a contar como llevan a la práctica las cuestiones que vamos a estudiar en la materia. Y para esto mi idea es traer representantes de empresas de distintos tamaños:
Bien, creo que esto es todo por el momento. A medida que se me vayan ocurriendo más cosas las iré publicando.
(parte 2 de la serie: Ingeniería de Software en UNQ)
Como ya mencioné en una entrada anterior, durante la segunda mitad de este año voy a dictar ingeniería de software en UNQ. Esto me ha llevado a plantearme explícitamente mi visión de esta disciplina.
Estoy absolutamente convencido que la ingeniería de software es una disciplina con un gran contenido social/humano más allá del contenido técnico. Si bien seguramente haya gente desarrollando software en «forma aislada», creo que no es lo más común, en general el software se desarrolla en equipos de personas. En forma más o menos directa el software es utilizado por personas. Y aunque no suene muy lindo, podríamos decir que la materia prima del software son las ideas/experiencias de las personas que participan en el proceso de construcción.
Del párrafo anterior se desprenden algunos corolarios.
El trabajo en equipo requiere de ciertas habilidades «blandas» que en determinados contextos pasan a ser incluso más relevantes que las habilidades «duras o técnicas».
Puede que las personas sean más importantes de lo que parece a simple vista. Y ya que hablamos de las personas no puedo dejar de recomendar este sorprendente video sobre motivación.
No estoy solo en esta posición, pues de hecho no la «invité» yo sino que la «escuche» de Tom De Marco y Fred Brooks y he tenido la posibilidad de confirmarla día a día en los años que llevo trabajando tanto en la industria.
Por último repito la frase que puse en mi página personal
Estoy absolutamente convencido de que el principal factor para el éxito de los proyectos no es ni el software ni el hardware, sino el peopleware, y es por eso que adhiero fervientemente al manifiesto ágil.
continuará…
(parte 1 de la serie: Ingeniería de Software en UNQ)
A comienzos de este año comencé a dar clases en la Universidad Nacional de Quilmes (UNQ). Por diferentes razones, me tocó sumarme a la materia Objetos 1, en la cual se enseña Programación Orientada a Objetos. Fue una experiencia muy interesante que ya contaré en otra entrada. El tema ahora es que con el comienzo del segundo cuatrimestre hubo una re asignación de profesores y como consecuencia de ello, el próximo cuatrimestre voy a dictar Ingeniería de Software :-).
En realidad el nombre formal de la materia es Elementos Ingeniería de Software y hasta el momento la venia dictando Gabi Arévalo quien tubo la amabilidad de pasarme el material que ella venia utilizando para el dictado de la materia. Por lo que vi de este material y lo que hablé con Gabi, la materia está basada en los clásicos libros de Pressman y Sommerville, con algunos agregados adicionales.
Esta nueva responsabilidad (con gusto asumida ya que yo mismo sugerí el cambio) me llevo a plantearme como encarar la materia. Después de revisar el material que me pasó Gabi, comencé revisando los objetivos de carrera, el perfil de los egresados y el plan de estudio. Luego me planteé explícitamente cual es mi visión de la ingeniería de software, cosa que nunca había hecho formalmente o si lo había hecho nunca lo había escrito. Finalmente me reuní con los profesores de la materias que dictan las material relacionadas. Es a partir de todo esto que comencé a diseñar la materia. En próximas entradas voy ir compartiendo lo que vaya generando.
continuará…
Blog de NicoPaez 