Entradas

Más y más pruebas

¿Te imaginas un modo de desarrollar software que ponga en primer lugar las pruebas antes de hacer otra cosa? Yo tampoco, pero hoy te voy a contar que hay gente que lo hace y parece ser que le va bien haciéndolo. Seamos sinceros, a primera vista esto no parece buena idea pues lo tradicional es hacer las pruebas hasta tener algo de software medianamente funcional pero hoy en día si no te actualizas lo más probable es que fracases como un buen desarrollador, así que sin más, hablemos un poco de DPP. Esto es extremo, viejo via GIPHY La práctica de primero probar antes de desarrollar es una de las principales prácticas de XP y también de la metodología Agile, no, no estamos hablando de la mejor versión de Windows sino de Extreme Programming . Quizá al principio te parezca un poco confuso el hecho de probar algo que aún no esté hecho pero bueno, esta es una manera muy simple de verlo, lo que realmente se hace es plantear y hacer las pruebas por las cuales tendrá que pasar nues

Probando ando

Una vez que ya tienes tu software medianamente funcional hay una parte que quizá puedes pasar por alto y cuando tengas que liberar la primera versión te lamentes por no haber hecho las cosas de la manera correcta, sí, estoy hablando del testing. O las pruebas cool para los amigos. Probar las cosas es una muy buena forma de saber si las cosas funcionan de la manera en la que esperamos pero a veces esto no es suficiente para hacer buen software, mucho menos si el nuestro está orientado a objetos. Prueba antes de avanzar via GIPHY Una vez que el paradigma orientado a objetos cubrió gran parte del panorama de desarrollo surgieron grandes interrogantes alrededor de el y uno de ellos fue la parte del testing y no era para menos, al ser las clases una de sus características más interesantes mucha gente comenzó a preguntarse cómo es que se iban a probar estas por separado cuando muchas de estas formaran parte de una funcionalidad más grande. Otra de las cosas que también comenzó a

Hagamos un breve repaso

¡Hey! ¡Cuántas semanas sin vernos! ¿Me extrañabas? Estoy seguro de que no, pero qué le vamos a hacer, después de tantas semanas sin escribir regresamos a la rutina de siempre y qué mejor que comenzarla por el final... ¿De qué me estás hablando? Bueno, esta es la última semana de clases y por ende también este es el último capítulo del libro así que lo vamos a despedir de una manera adecuada y esta es, haciendo un breve resumen de todo lo que aprendimos a lo largo del semestre. Si no lo repasas, no lo aprendes via GIPHY Una de las primeras cosas que vimos en el primer capítulo fue la diferencia entre requerimiento y característica la cuál radica en... ¡Hey! No estabas prestando atención, ¿verdad? Lo sé porque si estuvieras prestando atención rápidamente hubieras detectado que esa era una pregunta con trampa, realmente no hay mucha diferencia entre estos dos conceptos pero si no te acordabas que no tenían ninguna diferencia dudo mucho que recuerdes de qué es lo que van, a

No seas estúpido

Alguna vez escuché que cuando leías un libro estabas siendo mucho más inteligente que la persona que lo escribió y sinceramente nunca lo entendí hasta hace unos días, el punto es que mientras que el autor dedico muchos años de su vida a hacer investigaciones, a escribir, corregir y publicar el libro, lo único que hiciste tú fue ir a una librería, pagar unos cuantos pesos y listo, leer verdades absolutas sin saber todos los detalles. Este capítulo quiere lograr que tengas un pensamiento similar y para esto irrumpe diciéndonos que la originalidad está sobrevalorada, y tiene mucha razón. Sigue leyendo si quieres saber por qué a veces el ser original no está bien visto. No hay mucha gloria en ser estúpido via GIPHY Al principio me pasaba mucho, cada vez que estaba leyendo un tema nuevo siempre me retaba a mi mismo y en vez de leer el ejemplo que me proporcionaba el libro intentaba llegar a el mediante mi razonamiento y después, al compararlo, si este no era igual me frustraba bas

¿Quién mató al cliente?

En cualquier ámbito de la vida la gente siempre estará ansiosa por ver resultados de manera casi inmediata si no pregúntale al actual presidente de México, así que lo más sensato es que si quieres mantener a tu cliente contento, entonces tienes que mostrar resultados sí o sí lo más rápido posible pero claro, todo esto sin comprometer tus buenas prácticas que te llevarán a hacer un software de calidad, ¿quieres saber como lograrlo? Entonces no dejes de seguir leyendo. Lo que realmente importa via GIPHY Bien, en este punto del libro ya hemos aprendido muchísimas cosas e incluso ya hemos visto bastantes ejemplos de cómo se aplican diversos principios de desarrollo pero si somos sinceros, esto le importa bastante poco a nuestro cliente, él sólo se concentra si el software funciona en la forma en la que lo debería de hacerlo. Antes de que tires tu computadora y tu monitor por los aires y te preguntes qué demonios has estado haciendo leyendo los anteriores 8 capítulos no te confund

Vvvvvvvvv

Imagen
¡Hey! Cuánto tiempo sin escribir y vernos por aquí, ya sabemos que no nos extrañabas pero de cualquier modo estamos de regreso y sólo por poco tiempo, porque ya vienen vacaciones de nuevo y nos iremos de nuevo así que hoy te hablaremos de un tema mega divertido: verificación y validación, eso que muchas personas lo dejan hasta el final como la escritura de todas estas entradas  pero como veremos hoy, es un proceso continuo que se tiene que hacer durante todo el proceso de software y no únicamente antes de que se vaya a liberar, ¿qué? ¿No te habías enterado? Bueno, precisamente para eso son estas entradas, sin más que decir, adentrémonos en este mundo de locura de la validación y la verificación. V&V via GIPHY No, no se trata de esa marca de chocolates que tienen comerciales muy cool, estamos hablando de V&V y no de M&M's, V&V se trata de las siglas de Verificación y Validación que incluyen a todos los procesos de comprobación y análisis que llevan a asegur

Revisar todo antes de salir

Revisar, revisar, revisar... Qué tarea tan complicada. Al hacer un examen escrito revisar es una de las recomendaciones que más nos hacen nuestros maestros y con justa razón, pues a pesar de que sepas hacer todo el procedimiento de manera correcta un sólo error de dedo te puede llevar a reprobar el examen si tus resultados no son los correctos. Cuando uno está dado los primeros pasos en la creación de software esto no es tan dramático pues a pesar de que se cuenta con una limitación de tiempo el resultado a nivel de usuario pocas veces se ve afectado si no revisamos nuestro código, pero espera... ¿Me estás diciendo que no debería de refactorizar mi código? Va a ser que no, pero para que te enteres de lo que realmente te estoy tratando de decir, te invito a seguir leyendo. Revisando y aplaudiendo via GIPHY Revisar código no se limita a ir a revisar función por función a ver si no cometiste un error de nuevo que esté haciendo que tu producto no esté funcionando de la manera