Recomendaciones: El libro negro del programador

Es bastante sencillo encontrar libros sobre cualquier tipo de tecnología, herramienta o lenguaje de programación, pero al momento de localizar literatura sobre desarrollo profesional (o empresarial) de software dentro de un ambiente “real” (es decir no académico), es bastante más complicado y si además, estamos hablando de materiales en español, se vuelve una tarea completamente imposible.

El libro negro del programador, de Rafael Gomez Blanes, es una obra que nos ofrece una visión práctica, profesional y realista del desarrollo de software en un ambiente laboral. El libro no profundiza en ningún aspecto tecnológico en particular, si no en las buenas y malas prácticas en la construcción de sistemas.

Al leer el libro del programador, cualquier desarrollador, con un mínimo de experiencia laboral, se sentirá identificado con los problemas tratados allí. Generalmente la parte difícil no es reconocer que hay un problema en la forma de desarrollar sistemas en nuestra empresa o equipo, eso es bastante obvio cuando se acumulan las horas extras, el software de baja calidad, y la tensión palpable en el ambiente, el acierto del libro es listar las circunstancias que nos llevan a dichos problemas. Es necesario leer sobre nuestros problemas y escenarios laborales para poder comprenderlos completamente, aunque los estemos viviendo en primera persona.

El libro hace hincapié, entre otras cosas, en los siguientes temas:

• La importancia del refactoring y la creación de software que pueda ser mantenible.
• La capacidad de un sistema para ser probado y depurado.
• Que el éxito no es tener un sistema que funcione en producción, sino un sistema de calidad, que además permita evolucionar con las necesidades de nuestro cliente.
• Que no hay que trabajar muchas horas, sino ser productivo.

Por todo esto considero que El libro Negro del Programador es un texto que todos los desarrolladores debieran tener en su escritorio, para que no les olvide como hacer buen software.

Puedes obtener más información en http://mybook.to/elndp.

Regla N°13 de la Ingeniería de Software: Simplifica las cosas

Cuanto te enfrentes a un problema grande, simplifícalo en problemas más pequeños. Si estos problemas siguen siendo demasiado grandes repite el proceso hasta que tengas un problema lo suficientemente pequeño para poderlo resolver.

Lo anterior parece un consejo bastante razonable, no solo para la ingeniería de software, sino para cualquier circunstancia en general. Sin embargo parece que es difícil entenderlo al momento de enfrentar un nuevo desarrollo software.

Es común que caigamos en el error de ver los sistemas como un todo unido de enormes dimensiones, pero como ingenieros debemos ver las partes que componen un sistema, y centrarnos en el diseño y la construcción de dichas partes, de forma unitaria, además de en su correcta interacción.

Para simplificar partimos siempre de un problema grande que es irresoluble en su tamaño actual, e identificamos las partes que lo componen. Lo dividimos en pequeños problemas que son más fáciles de resolver, repitiendo el proceso hasta que podémonos identificar dichos problemas con una solución clara y sencilla, y además que solo sirva para resolver exclusivamente una necesidad.

En la medida que las “mini-soluciones” estén bien diseñadas será más fácil juntarlas, para resolver nuestros problema de origen (Curiosamente cuando más “desacopladas” sean, más fácil será unirlas).

Las ventajas de la simplificación son las siguientes:

• Nos obliga a ser ordenados y metódicos a la hora de resolver un problema.
  
  
• Con la simplificación es más fácil distribuir el trabajo dentro de un equipo de trabajo con varios recursos.
  
  
• Cuando comenzamos a resolver los problemas identificados, estos, por su tamaño nos permiten concentrar nuestro esfuerzo en un solo “tema” a la vez, y son además lo suficientemente pequeños para ser manejables.
  
  
• Cada solución aportar una funcionalidad concreta y finalizada al sistema.
  
  
• Las soluciones se deberían poder probar de forma individual. Las pruebas unitarias nos garantizan que todo funciona correctamente antes de integrarlo al conjunto global. Igualmente el sistema es modificado nos permite probar los elementos por separado, evitándonos realizar un complicado flujo hasta llegar al punto que deseamos probar.
  
  
• Simplificar nos permite desarrollar un sistema más desacoplado. Un sistema desacoplado permite que se cambien los componentes por otros que agreguen funcionalidad o la mejoren, sin afectar al resto de los componentes. Cuando más desacoplado e un sistema más mantenible es.