Ver por etiquetas
Todas las etiquetas »
Productividad »
Conceptos (
RSS)
Esa es la pregunta que lanzé en el sitio Software Quality Assurance and Testing de StackExchange.com en cuyas respuestas pude ver que existe cierto desacuerdo entre la comunidad de testers sobre ese tema y si bien yo tengo una idea clara al respecto, lo que en verdad quería conocer eran las argumentaciones de aquellos que piensan que sí deberían arreglar defectos (algunos defectos) y aquellos que piensan que no deberían para así hacer una síntesis. No obstante, al poco tiempo otro usuario inicia...
Cuando el build se rompe con demasiada frecuencia o permanece en ese estado por mucho tiempo, el equipo se ve impedido de avanzar cómodamente. Pero la razón principal por la que se rompen es sin dudas el descuido: no compilar antes de subir, no correr las pruebas antes de subir y no prestar la suficiente atención al mergear entre otras cosas. Esto es porque existe un exceso de confianza en los miembros del equipo. Para ayudar a mitigar esto, en mi equipo anterior creé este premio semanal con el que...
ElBruno ha escrito un interesante artículo en su blog titulado “ [#ALM] DEMOSTRANDO CON NÚMEROS PORQUÉ ES CONVENIENTE REALIZAR PAIR PROGRAMMING ” en el que, mediante lo que considero un ejercicio de razonamiento, intenta demostrar el incremento que esta práctica puede generar en la productividad de un equipo con una configuración ficticia, aunque bastante común, de 2 Devs. Srs. y 4 Devs. Jrs. Recomiendo su lectura (y además, es condición necesaria para entender de que se habla en esta entrada...
Introducción La historia del software está plagada de ejemplos de proyectos que fracasaron estrepitosamente, estos por lo general han excedido el presupuesto estimado, el esfuerzo estimado y el tiempo estimado en muchas veces y si bien parece que la industria viene haciendo avances importantes en estos problemas, aún hoy es común ver u oír de proyectos que fallan de manera espectacular. Voy a introducir solo algunas de las razones de por qué esto sigue sucediendo, de cómo puede solucionarse...
A mi anterior entrada la titulé “Las plantillas T4 son basura” cosa que respondió más a mi estado de bronca contra éstas que a su verdadero valor como herramienta. Muchos me preguntaron sobre el por qué de tal calificación y la verdad es que ese por qué es demasiado largo de explicar pero voy a mostrar la punta del ovillo para que a quien le interese pueda descubrirlo por sí solo. Veamos un par de ejemplo muy sencillos, el primero...
Actualmente tengo a cargo un proyecto en el que somos 13 desarrolladores en distintos lugares de Argentina y en Colombia. Por esta razón, lo primero que pensé es en armar un servidor de integración continua. Cuando lo planteé, la condición fue que no debía requerir licencias de software (salvo la de Windows). No tenía mucho tiempo para esta tarea así que fui a lo conocido: CruiseControl.Net, Subversion, MSBuild, NUnit, Wix, TortoiseSVN y un sin fin de scripts, xslts y herramientas propias. Hasta...
La dinámica de una empresa puede evaluarse quizás por el número y diversidad de los canales de comunicación que ofrece a su gente. Así, en empresas en las que la comunicación tiene canales formales bien definidos, la cooperación entre equipos y áreas siempre es más difícil que en aquellas con diversidad de canales horizontales. Uno de esos canales los constituyen las listas de correo (viejo pero actual, todavía). Y ayer he tenido una muestra de ello. Resulta que en la semana he tenido que realizar...
La creación de pruebas unitarias requiere al menos lo siguiente: Un framework de pruebas unitarias que debemos dominar. Por lo general son muy simples. Código testeable. Típicamente esto implica código susceptible de ser “aislado”. Nada que decir con respecto al primer punto. Ahora, en cuanto al segundo punto, ¿qué significa que el código pueda ser “aislado”?. Bueno, esto significa que sus dependencias deben poder ser reemplazadas. Esto lo logramos bien por medio de inyectarle sus dependencias o...
Voy a tomar prestado las palabras señal y ruido del campo de las telecomunicaciones para explicar una situación que nos afecta de cerca. Entendamos la palabra señal , en el contexto de esta entrada, como el mensaje, lo importante, lo esencial y como ruido lo indeseable, lo molesto, lo que encarece y entorpece al mensaje. La señal, o el mensaje en este caso, que deseamos transmitir, por lo general todos los que hemos estado en esto durante algún tiempo (y que nos hemos equivocado terriblemente una...
Desarrollo un sistema para la planificación, ejecución y seguimiento de encuestas en el que uno de los requerimientos es poder crear encuestas de manera sencilla y veloz. Además las mismas deben seguir un workflow (algo informal) de revisión. Otro dato importante es que el cliente diseña encuestas que van desde aquellas con solo algunas pocas preguntas hasta esas otras que nos tienen todo un domingo respondiendo acerca de alguna ginebra o algún nuevo centro comercial. Para rematar debo decir que...
Las recientes experiencias en la industria confirman que para obtener mejoras sustanciales mediante pruebas unitarias es necesario incorporar TDD (Test-Driven Development) como práctica integral del desarrollo. Aunque TDD no es una práctica nueva, solo experiencias recientes en Microsoft, IBM, HP y Ericsson comprueban la efectividad y factibilidad de ésta en proyectos reales y de reputación mundial. Los números de los resultados en realmente asombrosos. Les recomiendo leer las siguientes publicaciones...
En mi entrada Fluent Interfaces y TDD presentaba una prueba de concepto sobre un DSL interno que estaba desarrollando para encapsular varios detalles de la manipulación de documentos en el proyecto en el que trabajo actualmente. Luego de avanzar un tanto me doy con un problema muy común en la mayoría de las interfaces fluidas que he visto, a este patrón lo llamo sentencia única . Esto significa que una sentencia de un dsl interno no interactúa con otras del mismo. Veamos un ejemplo: Dh.Using.AnimalControl...
Hoy todos reconocemos el potencial que tiene (LOP) Language Oriented Programming, pero no solo eso sino que muchos ya están invirtiendo para hacerse con las ventajas prometidas por este paradigma(?). Muchos incluso diseñan la sintaxis de aquellos lenguajes que entienden, pueden hacerles alcanzar la productividad, calidad y mantenibilidad que buscan. Ahora bien, una vez decididos a crear el lenguaje (textual) propio para un dominio particular, hay que implementarlo. Aquí es donde deben estudiarse...
Hace poco gravé un pequeños video en el que explicaba una realidad que he visto en muchos proyectos respecto de las pruebas unitarias. En síntesis lo que comentaba era que en esos proyectos, los beneficios de las pruebas unitarias no eran visibles mientras que los costos sí lo eran. En problema aparente era la calidad de las pruebas, pero en realidad, el problema de fondo es la estrategia de hacer las pruebas luego de terminado el código. Por lo general, los programadores escriben piezas de código...
En mi último post presentaba una métrica (verdaderamente muy mala) sobre mi productividad en un proyecto realizado completamente utilizando TDD de manera estricta. Esta mostraba aproximadamente 9 LOC/Hs. Al mismo tiempo, y como las pruebas y el código los escribí interactivamente, escribía 11 LOC/Hs de pruebas. Esto hace un total de 19 LOC/Hs. Ahora bien, cada 2 o 3 pruebas el código era refactorizado para eliminar duplicaciones, del mismo modo que luego de observar un patrón común en un conjunto...
Hace poco comencé un nuevo desarrollo y decidí grabar algunos videos de los cuales solo publiqué los primeros tres. Sucede que el hecho de saber que alguien me estaba mirando me hacía prestar mayor atención a mis palabras que al código que debía escribir. No obstante a ello, continué grabándome para tomar el tiempo y estudiarme. La primera parte de ese desarrollo está completado y estos son los números: 66 pruebas unitarias. 15 clases. (solo 4 centrales, el resto son datacontracts, excepciones y...
Tanto se los he dicho que ya están empezando a darse cuenta de que realmente no entienden las necesidades del negocio. Al parecer ellos se meten en la programación desde chiquitos y el mundo se les achica tanto que no comprenden que hay compromisos asumidos y que el cliente está esperando el producto. Pero bueno, yo sigo explicándoles y varios lo entienden bien pero hay un par que verdaderamente no parecen estar muy convencidos. Lo peor de todo este asunto es que cada vez trabajan más lento y cada...
Intro Como ya sabemos, un DSL es un lenguaje de programación que se construye para atacar una familia de problemas que se presentan habitualmente en un dominio particular. Aunque su denominación actual (DSL) es relativamente nueva, estos han sido utilizados desde siempre, en particular los que Martin Fowler llama “external DSL” los cuales muchas veces los utilizamos dentro de otro lenguaje huésped. Por ejemplo, es muy común encontrar SQL, XPath, RegEx, Xml...
He querido compartir en este video de 7 minutos mis experiencias con la implementación de test unitarios cuando la inversión en capacitación es escaza. Que peligros encierra una pobre capacitación y ante que escenario nos podemos encontrar es de los objetivos de este video. Lucas Ontivero
El correo electrónico es una de las herramientas más importantes de trabajo, todos tenemos un cliente de correo que chequeamos varias veces al día ya sea en nuestro trabajo o en nuestros hogares. Es tanto un medio de comunicación como un sistema para recibir alertas y recordatorios, todos los sistemas se comunican con nosotros mediante correo electrónico, " se te ha asignado un nuevo ticket ", " quedan 3 días para renovar las licencias ", " inscríbete para el curso de seguridad...