Adaptabilidad y mantenimiento

[English version]Este enlace se abrirá en una ventana nueva

Voy a decir una obviedad, el objetivo último del desarrollo de software es satisfacer las necesidades del negocio.

Si bien esto es totalmente cierto, no deberíamos caer en el extremo de supeditar absolutamente el cómo se hacen las cosas al qué se quiere hacer. Existen ciertos intangibles que, como profesionales, debemos tener en cuenta, tales como la adaptabilidad y la capacidad de mantenimiento a futuro.

La adaptabilidad es lo que permite que el sistema sea capaz de incluir nuevas funcionalidades no previstas a un coste razonable o aguantar cargas más elevadas de las inicialmente supuestas de forma escalonada. La capacidad de mantenimiento incide en la facilidad de incorporar cambios, con independencia de la persona que los realice, en la robustez frente a determinadas situaciones y en una minimización de costes para el cliente. En realidad, ambos aspectos, como podéis ver, tienen cierto grado de correlación, pero me parece interesante considerarlos por separado.

Para conseguir todo esto, he apostado, a lo largo de los años, por una forma de hacer o forma de trabajar, aplicada tanto en los productos como en los proyectos que hacemos en Divisa iT, y que busca maximizar el compromiso entre tecnología y negocio. Centrándome, para ello, sobre tres pilares fundamentales:

Patrones-esPatrones-es

En los siguientes apartados os detallo un poco más lo que hacemos dentro de estos tres principios.

Pautas y buenas prácticas

Bajo esta idea no intento englobar la idea de arquitecturas de software, creo que cada aplicación tiene sus propias necesidades e intentar definir una común puede ser, por generalista, una mala idea.

Ello no quita que no podamos identificar una serie de pautas comunes que podemos aplicar en los productos y en los distintos proyectos en los que participamos. Estas pautas tienen el doble objetivo de facilitar lo que os comentaba antes: adaptabilidad y mantenimiento.

Así, por ejemplo, y tanto en nuestros desarrollos de backend como los de frontend nos preocupamos de:

  • Separación de capas, principios SOLIDEste enlace se abrirá en una ventana nueva, orientación hacia API, utilización de tests desde el punto de vista funcional y de mejora de los mecanismos de diseño de la aplicación.
  • Normas bien definidas en cuanto a nomenclatura, documentación de código.
  • Principios de programación funcional (lambdas Este enlace se abrirá en una ventana nuevaen Java y JavaScript, uso de componentes funcionales en REACTEste enlace se abrirá en una ventana nueva).
  • Preferencias por tipos de lenguaje fuertemente tipados, TypeScript Este enlace se abrirá en una ventana nuevavs JavaScript en la parte de Frontend, por ejemplo.

Aseguramiento del cumplimiento

El objetivo fundamental que persigo con esta actividad es convencer, no imponer e intentar aprender. No os voy a negar que el porque si no sea a veces una respuesta, pero intento minimizar su aplicación, puesto que, para mí, el convencimiento y la retroalimentación son las únicas formas de conseguir un resultado positivo para todos y asegurar el crecimiento a futuro.

En este sentido suelo jugar con un conjunto de preguntas más o menos fijas que varían en función de la experiencia de la persona, y de la complejidad del problema en cuestión. Desde un ¿por qué crees que esa opción es la mejor?, ¿en el caso de que pasará algo de este tipo que ocurriría?, ¿cómo podrías verificar que el funcionamiento es el esperado con el planteamiento que has seguido?

Gracias a este tipo de cuestiones, creo que es posible tener un diálogo productivo, en el que se entiende lo que la otra persona quiso hacer, que ésta entienda porque tenemos una forma de trabajar definida y que podamos mejorar los procedimientos en el caso de que las nuevas ideas sean mejores.

Fomento de la creatividad

Creo que no hay nada más triste que tener a un conjunto de autómatas trabajando. Es cierto que, en ocasiones, cuando los plazos aprietan, no queda más remedio que controlar el proceso al mínimo detalle. Pero no es una situación en absoluto deseable. Soy un firme convencido de que cada persona puede aportar creatividad en lo que hace y uno de mis objetivos es que lo haga.

El cómo, dependerá de la persona. Así, en algunos casos, será un proceso endógeno. A modo de ejemplo, no soy un gran convencido de REDUX y su concepto de side effectsEste enlace se abrirá en una ventana nueva para el tipo de aplicaciones en las que solemos trabajar. Pero, jamás me he negado a que se utilice y de hecho cuando me han preguntado siempre he respondido de forma afirmativa, fomentando que lo utilicen en sus desarrollos y que determinen si es lo más adecuado para resolver su problema.

En otros casos será necesario empujar un poquito, dejando caer la necesidad de que igual es necesario cambiar procesos, herramientas o procedimientos. Como cuando abordamos la migración a gradle Este enlace se abrirá en una ventana nuevay git Este enlace se abrirá en una ventana nuevade nuestro sistema de construcción de aplicaciones.

En resumen

En Divisa iT intentamos aplicar una forma de trabajo que proviene de la experiencia - de la buena y de la mala –, que intenta fomentar lo mejor de cada persona para obtener el mejor resultado posible y siempre con el objetivo de satisfacer las necesidades del negocio y de nuestros clientes.

Si te interesa lo que hacemos y cómo trabajamos no dudes en aplicar a nuestras ofertas de empleo.

Créditos

Iconos cortesía de FlaticonEste enlace se abrirá en una ventana nueva