A continuación presentamos algunas recomendaciones para los programadores, estas están basadas en el libro “97 Things Every Programmer Should Know”, en este caso presentamos solo algunas recomendaciones que podrían evitarle complicaciones en el desarrollo de software e incluso simplificar el tiempo de desarrollo de los proyecto.
“Hacerlo bien” o “hacerlo rápido”
Al inicio de una iteración de desarrollo, posiblemente no se puede evitar estar bajo presión y de pronto encontrarse ante la disyuntiva de “hacerlo bien” o “hacerlo rápido”, muchas veces cayendo en “hacerlo rápido”, teniendo en cuenta que lo puede revisar y corregir posteriormente. Luego al iniciar la segunda iteración, aparecen nuevos problemas que requieren su atención. Este tipo de errores que se arrastran de una iteración a otros hacen que llegado un momento el número de errores o fallos sea difícil de manejar. Bien dicen, un buen edificio se basa en buenas bases.
Estos errores son denominados “deuda técnica”, la cual en el corto plazo puede brindarle beneficios, pero a la larga genera intereses que serán cobrados luego. Esto hace más difícil agregar funcionalidades o re escribir el código.
Recomendación: pagar la deuda técnica lo antes posibles, en caso contrario puede ser imprudente.
Aplicar principios de programación funcional
Recientemente se ha presentado un renovado interés por este tipo de programación; por ejemplo Java 8 y las expresiones lambda o la implementación en lenguajes como Scala presentan a este paradigma como una alternativa a utilizar.
En la programación funcional, una función depende de la entrada y arrojara el mismo resultado no importando de qué parte del software sea llamado, esta principalmente por el uso del concepto de valores inmutables. Muchas causas de defectos en el software son atribuidos a las variables que pueden cambiar de valor.
Es un hecho también que paradigmas como la orientación a objeto son muy útiles, dependiendo del entorno de programación, luego el aprender de programación funcional se debe utilizar para, en forma adecuada, elegir si utilizar una forma de programar u otra. Así, en este caso se convierte en una herramienta adicional al resolver un problema.
Pregunta: “¿Cuál es la necesidad del usuario?” (Usted no es el usuario)
Los programadores muchas veces tardan mucho tiempo tratando de ponerse en el lugar del usuario. Es claro indicar que, los usuarios no piensan como los programadores. Incluso utilizan la computadora en forma diferente a los usuarios.
En este punto me permito mencionar a las metodologías ágiles, en las cuales los usuarios son parte del equipo de desarrollo, en el caso de Scrum por ejemplo se tiene al Product Owner quién es el responsable de definir las características del producto, así mismo se propone una comunicación permanente entre los programadores y el Product Owner.
Es recomendable que, cuando el usuario se encuentre brindando las recomendaciones, no sea interrumpido con sugerencias de cómo debería trabajar el software, muchas veces en el momento de realizarlo, el entiende la recomendación, más no es su modo natural de pensar y luego al utilizar el software tal vez no entienda como funciona este.
Automatice sus estándares de código
Muchas veces al iniciar el desarrollo de un proyecto, todos inician con buenas intenciones de hacerlo bien. En el caso de programación incluso, al iniciar el desarrollo se cuenta con un estándar de programación, más a finalizar el proyecto el código se presenta como un completo desorden.
¿Cuándo empezó el desorden? Existen muchos puntos donde esto pudo suceder. Posiblemente al iniciar el proyecto y presentar el estándar de programación, algunos no estuvieron atentos, o tal vez otros no estuvieron de acuerdo e iniciaron sus propios estándares, o tal vez durante el proyecto se integraron nuevos programadores que nunca vieron el documento de estándares.
Esto siempre puede suceder, la mejor manera de tener el estándar como parte del código es automatizando estos estándares. Así:
- Se debe tener el evaluar el formato del código como parte del proceso de construcción
- Utilizar código que busque anti patrones en su código
- Utilice herramientas que permitan explorar en su código
- Utilizar herramientas de pruebas
Realice esto para cada parte que considere importante. Finalmente, el estándar que se dio al inicio puede que evolucione en el tiempo y puede no ser necesariamente el mejor al final del proyecto.
En posteriores artículos continuaremos tocando recomendaciones para programadores. ¿En su empresa siguen alguna de estas recomendaciones? ¿Puede indicar cual de ellas considera más útil?
