¿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 confundas, debes de ser un programador de calidad para hacer software de calidad así que si bien a tu cliente no le importa si eres un buen programador o un mal programador, si le interesa el resultado de tu software así que todo lo que has aprendido no ha sido para nada en vano.

Hemos visto bastantes metodologías, sobre todo en el mastery topic dedicado a las metodologías de desarrollo, si te lo perdiste lo puedes leer aquí, pero debes de tener en cuenta que sea cual sea la metodología que escojas, el desarrollo de software siempre sigue un patrón similar ya que el desarrollo tiende a ser iterativo, ¿qué significa que sea iterativo? Bueno, primero tienes que ver tu software a una distancia de 10000 pies de altura para tener clara la imagen general del mismo y así comenzar a iterar en pequeñas piezas de funcionalidad.

Cada vez que comiences a trabajar con una pequeña pieza entonces tendrás que hacer el análisis y diseño correspondiente al presente ciclo, ¿suena complicado? Pierde cuidado, hay diversos enfoques que puedes tomar para que tus iteraciones sean entonces, más digeribles:

• Use case driven development: este enfoque toma un caso de uso a la vez y se enfoca en completarlo incluyendo todos los escenarios que pueda tomar, esto antes de moverse a cualquier otra cosa en la aplicación.
• Feature driven development: se enfoca en una única característica y trabaja en su comportamiento hasta completarlo, aquí es cuando ya se puede mover a trabajar en otra cosa.
• Test driven development: se trata de escribir escenarios posibles para cada pieza de funcionalidad antes de escribir el código de la misma, este enfoque se trata de escribir el código de acuerdo a los escenarios propuestos. 

Show me what you got

via GIPHY

Una vez que hayas concluido una iteración lo que resta es probarle al cliente que tu código realmente funciona y que lo hace bien, para esto tendrás que crear una unidad que no es otra cosa que casos de prueba que tu software tendrá que superar de manera positiva, aunque esto quizá ya te esté sonando a que será un problema, ¿tu unidad tendrá que cubrir todas las posibilidades de entrada del mundo? Pues no, porque te llevarías todo el tiempo del mundo en escribir esta unidad y modificando tu código buscando que este funcione de manera adecuada así que usaremos dos tipos de programación que quizá no te suenen del todo:

• Program by contract: este estilo de programación define que los usuarios tendrán que comportarse de una manera previamente definida entre tu y el cliente para usar de manera eficiente el sistema. Por ejemplo, si tu software se dedicará a administrar ciertas cantidades de material, entonces tienes que definir con tu cliente que estos campos no aceptarán letras en vez de números, he aquí tu contrato. Este tipo de programación es muy efectiva para no cubrir casos que pueden hacer que tu código sea realmente extenso y que tu software funcione justo para lo que se necesita. 
• Defensive programming: ¿qué pasa cuando piensas que vas a programar para una panda de monos que no respetarán nada y lo único que buscarán es romper tu programa? Bueno, entonces tienes que utilizar una programación defensiva y blindar tu código no para la mayor parte de los casos en los que tu software se puede romper. 

Conclusiones

via GIPHY

Recuerda, no te decidas por un enfoque, si tu software es realmente bueno entonces tendrá un poco de los 3 según la etapa de desarrollo en la que se encuentre así que ya tienes más herramientas con las cuales trabajar de aquí en adelante, mi consejo como siempre es que las implementes en tus proyectos y te pongas manos a la obra. Nada mejor que la experiencia para tener una buena perspectiva de tus nuevos aprendizajes.

Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados.