Cuando nos enfrentamos a un nuevo tipo de proyecto en el que vamos a usar tecnologías que no dominamos del todo o es la primera vez que las usamos en un proyecto profesional, suele ser un error que tu primer proyecto con esas tecnologías sea precisamente el que vas a entregar a un cliente; este, sin saberlo, va a ser un conejillo de indias del proveedor que decide con acierto o no los mejores frameworks y librerías para ese tipo de proyecto, si es que esta evaluación se ha llegado a hacer.

Lo peor se presenta cuando quien decide usar un stack de tecnologías en concreto lo hace no porque se ajuste a ese proyecto en particular, objetivamente, dada su naturaleza, sino por sencillo capricho y porque se presenta así una oportunidad maravillosa de aprender en el trabajo sobre aquello que fuera de él no se tiene tiempo... Esto lo he visto varias veces y es una tentación demasiado grande como para no hablar de ello; igualmente, quien cae en esa tentación se podrá considerar desarrollador de software, pero desde luego no profesional. En ocasiones, los desarrolladores de software parece que juegan en su trabajo en lugar de buscar realizarlo con la mayor profesionalidad posible.

No hace mucho he leído en un libro sobre AngularJS la siguiente sendencia, aplastante e ilustrativa:

"Software development is hard. As developers, we need to juggle customer requirements and pressure of deadlines, work effectively with other team members, and all this while being proficient with multitude of software development tools and programing languages. As the complexity of software rises so is the number of bugs. We are all human and we will make mistakes, tons of them. Lower-level, programming errors are only one type of defect that we need to constantly fight. Installation, configuration and integration issues will also plague any non-trivial project."

(Mastering Web Application Development with AngularJS)

No lo habría podido expresar mejor: durante el desarrollo de cualquier proyecto, una de las tareas a las que nos dedicamos es a desarrollar nuevo código de producción, pero esta es una tarea más; al mismo tiempo se realizan muchas otras tareas relacionadas con el proyecto pero igualmente importantes. No obstante, en ocasiones se trivializa la importancia de esas otras tareas pensando que poco tienen que ver con el proyecto y que en realidad lastran el escribir nuevo código; porque lo divertido, lo que más nos gusta a los desarrolladores de software es "escribir código", ¿no es así?

Eso podría pensar una mente ingenua recién llegada a un sector en el que mirar hacia atrás varios años es ver la prehistoria por una renovación continua de nuevas tecnologías, flujos de trabajo y, por qué no, incluso nuevos tipos de proyecto.

Desde hace unos años participo en cierta medida en asuntos comerciales además de mi dedicación casi completa a dirigir un equipo de desarrollo, involucrándome, cómo no, en todo tipo de tareas técnicas, decisiones de diseño y arquitectura, toma de feedback de clientes, etc.

En este tiempo me ha llamado mucho la atención cómo bastantes clientes pontenciales de los productos que comercializamos se interesan por conocer el motor de base de datos que usa nuestro software. Los hay quienes le dan todas las bendiciones a SQL Server, otros que no cambiarían Oracle por SQL Server y unos pocos que nos han preguntado si el sistema podría funcionar con Cassandra (...). Nada que objetar, salvo su percepción completamente errónea de que el producto va a ser rápido y eficiente o lento y poco escalable según la base de datos que use, nada más.

Esta suposición, entendible para cierto perfil no técnico, la he visto también en otro tipo de perfiles muy técnicos y entendidos en software, para mi asombro.

En El Libro Negro del Programador se insiste mucho (como en cualquier otro libro que nos enseñe a ser mejores profesionales) que la refactorización de código no es sólo una herramienta que debemos usar sino que ésta es un hábito que emplear en el día a día y que distingue a los mejores desarrolladores de software.

No obstante, el concepto de refactorizar se suele entender exclusivamente como un trabajo de modificar líneas de código y mejorarlo sin afectar a su comportamiento externo; conseguimos, efectivamente, limpiar en cierta medida el código para que sea de mejor calidad, más legible y mantenible.

Siempre insisto en que esto no es algo que se hace o no, sino que forma parte del hecho de programar una solución, es algo consustancial a la misma.

Cuando terminamos de implementar una nueva funcionalidad, siempre nos debemos preguntar ¿podemos mejorar lo que hemos implementado en algún aspecto?, ¿se puede simplificar?, ¿se puede mejorar en relación al proyecto general como parte que se pueda reutilizar?, etc. Lo sorprendente es que cuando te creas el hábito de plantearte este tipo de cosas apenas termina haciendo falta hacerlo al final de implementar algo, ya que tienes el hábito de hacer las cosas limpias desde un principio de modo que al final, es esfuerzo o tiempo que empleas como puro trabajo de refactorizar es mínimo.

No obstante, se suele entender por refactorizar el trabajo de mejora del código, pero ¿qué ocurre con la misma estructura de un proyecto que va creciendo y creciendo con el tiempo? No hablo de diseño, sino de cómo están organizadas las carpetas, subproyectos, etc.

Me sorprende a menudo cómo los desarrolladores de software nos complicamos la vida por no dar un paso atrás e identificar aquello que nos impide centrarnos en escribir código de producción y testearlo. Los problemas casi siempre surgen de no montar en entorno adecuado de pruebas que permita testear la nueva funcionalidad que incorporamos con comodidad. El extremo más radical de esto consiste cuando la única posibilidad de probar algo es ¡en el entorno de producción del cliente!. Me temo que sólo mecionarlo se me pone la piel de gallina, aunque lamentablemente lo he vivido y lo he visto en varias ocasiones.

Cuando comienzo un nuevo proyecto, aunque sea sencillamente probar una tecnología que desconozco y con la que comienzo a jugar, lo primero que hago es montar un entorno en el que trabajar con absoluta comodidad: si no lo hacemos así, a los problemas habituales de resolver errores y avanzar en aquello que no conocemos bien le añadiremos los inconvenientes de trabajar con ese entorno incómodo (o lo que es lo mismo, perderemos más tiempo en problemas con el entorno que en crear software útil).

Es recurrente la pregunta que me hacen según la cual siempre se pone en duda la necesidad de realizar software sencillo, fácil de entender (por nosotros y por los demás) pero sobre todo, mantenible. Muchos de quienes nos dedicamos a desarrollar software profesional no tenemos claro aún ciertos conceptos esenciales, como por ejemplo que un diseño matenible no tiene nada que ver con un diseño de algo que es imposible modificar, depurar, evolucionar, etc. Aun funcionando bien, el primero nos dará un mayor rendimiento del trabajo realizado, mientras que en el segundo caso el software pasa a producción moribundo y sin apenas solución de continuidad.

No obstante, nos cuesta reconocer la relación que existe entre la sencillez y la facilidad de mantenimiento.

Mantenible (palabra mantra en el Libro Negro del Programador) no significa trivial, que un principiante sin apenas esfuerzo pueda entender a la primera, sino coherente, un diseño eficiente que facilita los cambios en el futuro y que la adaptación a nuevos requerimientos relacionados son viables (a un coste asumible).

A diferencia del autor de un best-seller que cuando publica un libro que funciona bien recoge royalties según las ventas, cuando publicamos un producto software tendremos más o menos éxito si este puede evolucionar, si puede ser cambiado y fácilmente mantenido.

En Code Simplicity (libro que recomiendo aunque no se lea ni una línea de código) se pueden leer frases auténticamente reveladoras que el autor intenta sintetizar a modo de leyes comunes que gobiernan el desarrollo de cualquier software.

Hay diferentes maneras de aprender y mejorar nuestro trabajo como desarrolladores de software. El aprender una nueva tecnología (o mejorar las habilidades en aquellas que dominamos) requiere a menudo repensar cómo hacemos las cosas.

Hay quien se siente cómodo buscando en foros continuamente para resolver cualquier problema; esto para mí es algo así como aprender por prueba y error llevado al extremo. Hay quien, como yo, preferimos aproximarnos a una nueva herramienta o tecnología leyendo un buen libro de arriba abajo. Las opciones son diversas y como se suele decir cada maestro tiene su librillo.

No obstante, he visto durante mucho tiempo el que es un gran defecto de muchos programadores profesionales: cuando conocen en profundidad las herramientas, lenguajes, etc. que utilizan en el día a día, se anquilosan haciendo siempre, durante años, las mismas cosas y del mismo modo. El desarrollar software tiene un grado versatilidad y flexibilidad que difícilmente hay una única forma de hacer algo, todo lo contrario, siempre existen cientos de formas de resolver un problema; entonces, ¿por qué nos abstenemos de descubrir esos otros enfoques?.

En ocasiones me han preguntado por qué insisto tanto en que el código que se escriba sea lo más legible posible, que se pueda leer y entender sin que construcciones extrañas o clases de cientos de líneas te arañen la vista, por poner unos ejemplos.

Se pueden dar muchos argumentos a favor de añadir un poco de esfuerzo a nuestro trabajo para escribir código que otros puedan entender; de todos los posibles a mí me parece que hay un criterio fundamental que no siempre se tiene tan en cuenta.

La productividad de un equipo de trabajo en ocasiones viene dada por pequeños detalles que en sí mismos pueden parecer insignificantes pero sumados marcan una gran diferencia. El Libro Negro del Programador habla intensivamente acerca de cómo desterrar malos hábitos e incorporar buenos precisamente para aumentar la productividad. En ocasiones se entiende ésta exclusivamente como echar más horas: yo digo que trabajar con productividad tiene más que ver con usar herramientas correctamente, tener un equipo de trabajo bien organizado y buenos procedimientos.

Uno de estos procedimientos que pueden ahorrar muchísimo tiempo de esfuerzo inútil es subir correctamente al repositorio de código los últimos cambios introducidos. Como en muchas ocasiones, los mejores hábitos y técnicas son precisamente los más sencillos.

Las reglas para desarrollar buen software son en ocasiones de un total sentido común y están al alcance casi de cualquiera que se proponga realizar su trabajo en condiciones.

No hace mucho re-descubrí un conjunto de sencillas preguntas que nos dicen si tenemos un buen equipo de trabajo y trabajamos desarrollando software con un mínimo de calidad: es el test de Joel que resumo a continuación y que no es más que sentido común aplicado a nuestra actividad diaria:

Páginas

¿Por qué leer El Libro Negro del Programador?

Adquirir desde:
Amazon (kindle eBook / papel)
CreateSpace (papel)
PayHip (epub / mobi / pdf)

El libro negro del programador.com
Segunda Edición - 2017

Archivo

Trabajo en...