El principio de simplicidad define como será la fase de mantenimiento de software.

Resumen: El principio y final de un proyecto, son dos puntos más cercanos de lo que se piensa ya que en el momento que un equipo de desarrollo finaliza un proyecto, otro equipo, el de mantenimiento, lo empieza y esta fase, probablemente tenga más perdurabilidad en el tiempo. El principio de simplicidad (KISS) es directamente proporcional a la calidad del servicio de mantenimiento evolutivo.

En pocas ocasiones somos conscientes que el software, una vez desarrollado y desplegado, ha de ser mantenido.

El mantenimiento evolutivo del software, es una tarea que puede ser sumamente compleja en función de como se haya desarrollado la solución ya que si en la fase de desarrollo, no se ha tenido en cuenta este aspecto y se ha dejado de lado el principio de simplicidad podemos encontrarnos con códigos fuentes sumamente complejos y en definitiva difíciles de comprender.

Si ha esto se le suma la ausencia total de implementaciones de patrones de diseño, mecanismos que certifiquen la calidad del producto sobre todo a través de pruebas unitarias, la inexistencia de datos de prueba o el no haber aplicado las directrices de arquitectura y diseño formuladas por evangelistas de las tecnologías o fabricantes, encontramos que soluciones que en esencia deberían ser sencillas, son sumamente complejas.

Otro factor interesante en los servicios de mantenimiento es que en muy pocas ocasiones, el equipo que ha desarrollado un software posteriormente lo mantiene. Normalmente lo que sucede es que «los puntas de lanza», las personas con perfiles más altos y mayor experiencia salen del proyecto y se forman equipos que permiten ofrecer un servicio más ajustado en relación a la tarifa. Por lo tanto, nos encontramos con equipos de menor experiencia que van a encontrar muchas más dificultades a la hora de entender un software complejo, así pues, las frustraciones y apatía no tardan en llegar y está complejidad, estas piezas que desarrollamos (todos, como ególatras que somos los desarrolladores), ¿en que derivan? Pues básicamente derivan en piezas de código que nadie quiere tocar, que fallan durante años e inciden en la productividad y eficiencia tanto de nuestros equipos de mantenimiento como de nuestros clientes.

Y por supuesto, todo puede ser peor que lo dicho anteriormente.

La calidad del servicio de mantenimiento tanto preventivo como evolutivo siempre es directamente proporcional a la calidad del producto y el desarrollo realizado inicialmente. Por lo tanto, si estás en la tesitura de desarrollar un software que posteriormente ha de ser mantenido ten en cuenta que todo lo que sea seguir la linea de la sencillez, ya que posteriormente va implicar ofrecer un servicio de calidad y valor.

Ten claro que nada es reutilizable hasta que se reutiliza, que pocas soluciones genéricas se adaptan a todos los casos, que siempre va a ser mejor utilizar frameworks de terceros (Bootstrap, HTML5 Boilerplate, jQuery, Moq, Unity etc.) que el tuyo, ya que estos son mantenidos por equipos enteros y sobre todo, te presente siempre el principio de simplicidad, que hay que hacer refactoring, que las pruebas unitarias evitan muchas situaciones no deseadas, ya que son reproducibles, ejecutables en cualquier momento, documentan el código, y en muchas ocasiones, una evidencia de la calidad del producto que has desarrollado.

Cuando estés manteniendo software, no escatimes en esfuerzos, es un trabajo que puede ser muy complejo, así que valora el servicio como se merece, asegura la calidad del servicio y el software que escribes y mantienes, no escatimes en herramientas y sobre todo, aprende cada día ha hacerlo mejor.

Anuncio publicitario