Cómo mejorar la velocidad de desarrollo en tu empresa o equipo

September 09, 2019

...

Voy a contar una pequeña historia que, lo más probable, es que les resulte familiar. Comenzamos con un proyecto pequeño, nuestra querida startup, tenemos que construir rápido así que utilizaremos un framework que nos ayude con la tarea. Si tiene generadores de código aún mejor para que podamos avanzar más rápido. En un mes, o incluso menos tenemos un prototipo de nuestra aplicación. Nos sentimos muy orgullosos e incluso nos comparamos con otras empresas que les toma incluso un mes desarrollar un proyecto de cambio de contraseña (yo participé en un proyecto así). Nuestro proyecto ya anda, empezó a generar dinero pero aún le falta un poco, salen más clientes que necesitan más funcionalidades, entonces las empiezas a desarrollar. Los primeros cambios te resultan sencillos, pero a medida que empieza a avanzar el desarrollo te das cuenta de que es más difícil agregar nuevas funcionalidades. La empresa empieza a crecer por lo que empiezan a contratar desarrolladores, sin embargo a medida que avanza más el desarrollo de nuestra aplicación esta se empieza a volver cada vez más lento.

La cantidad de código que existe es gigante, solucionar errores toma muchísimo tiempo y nuestro software se rompe cada vez que realizamos pequeñas modificaciones. Por lo que traemos a un QA a nuestra empresa para que nos ayude a mejorar la calidad de nuestra aplicación.

No todas las empresas alcanzan la fase que menciono antes, muchas mueren antes por:

  • la incapacidad de poder comercializarla (construir algo que no se necesita)
  • encontrar un nicho donde tu aplicación necesita demasiadas funcionalidades para que salga a flote (esto sigue siendo incapacidad comercial).

Lamentablemente este post no esta diseñado para ayudarte en el primer caso, el cual es comercializar una aplicación, pero sí está diseñado para ayudarte cuando tu aplicación necesita demasiadas funcionalidades y también mejorar la mantenibilidad en un largo plazo.

Dadas las razones que te menciono antes he llegado al punto de estar obsesionado con poder avanzar cada vez más rápido o por lo menos a un paso sustentable. Estos consejos están basados en experiencias personales aunque también puedes encontrar algunos en el libro de scrum desde las trincheras. Lo importante es que esta enfocado en poder construir un proyecto rápidamente y que la velocidad sea mantenible o mayor en el largo plazo.

En el peor de los casos, una empresa se verá obligada a reescribir una aplicación completa ya que el nivel de deuda técnica es tan grande que el esfuerzo que habrá que dedicarle para saldar la deuda técnica es más grande que el esfuerzo para construir nuevamente la aplicación con una arquitectura acorde.

La calidad interna, luego la calidad externa

Esta opinión puede ser bastante controversial y antes de explicar el porque deberíamos enfocarnos primero en la calidad interna y luego en la calidad externa vamos a definir estos dos conceptos:

Calidad interna

La calidad interna refiere a todo lo que pueda facilitar el trabajo del desarrollador al momento de agregar funcionalidades, corregir errores, leer código o modificarlo.

Un desarrollador lee código un 90% del tiempo y lo escribe el 10% restante. Hay un tiempo escondido que se basa en entender el problema y este va a depender del tamaño de la herramienta, las reglas de negocio. De esto hablaremos en otro momento. Cuando el código cumple con buenos patrones para que este sea fácil de leer y fácil de entender puedes reducir la cantidad de tiempo que se pasa leyendo. Al eliminar anidación, bifurcaciones, loops, bloques try/catch, entre otras cosas haces que tu código siga con un flujo fácil de entender, siempre será de arriba hacia abajo y no deberas tomar distintos caminos al momento de leer. Incluso un if puede agregar más complejidad al código cuando este opera a gran escala.

Tratar de respetar todas las normas para que el código sea lo más reutilizable posible. Cuando tu código es fácil de leer estas reduciendo la primera brecha, que es la más grande, la de leer código, cuando quieres encontrar errores es mejor que tu código sea legible, pero que pasa cuando quieres agregar funcionalidades?

Un código con errores por lo general no son de sintaxis si no de la lógica que esta tratando de implementarse. La mejor forma de solucionar esto es poder ver inmediatamente la intención del código en lugar del detalle de la implementación. La intención revelará si hay un problema en la lógica.

Escribir código es costoso, toma tiempo, tienes que pensar en que enfoque le vas a dar ya que pueden ser miles de decisiones las que puedes tomar pero siempre existirá una que es más acertada. Es imposible saber cual va a ser la mejor forma ya que para eso, necesitas saber como se va a ver el software cuando este finalmente terminado, siempre deberás ir construyendo sobre la marcha y, con el tiempo te darás cuenta, de que existe mucho código que podría ser refactorizado. En la realidad, tratar de poner sobre la balanza con el área de negocio que necesitas realizar un refactor para avanzar más rápido la respuesta casi siempre será negativa. Por lo que tomar un enfoque donde todo este pensado en reutilizarse desde sus cimientos hará que sea más fácil que tu reutilices el código que escribes. Para eso hay muchas técnicas y que estaremos viendo con el tiempo pero por ahora, piensa que debiese ser reutilizar primero siempre.

Dentro te las herramientas que existen para que tu código sea, reutilizable primero, están: la herencia, composición, subrutinas entre otras. Independiente del paradigma o técnicas de reutilización que tomes asegúrate de tomar por lo menos uno. Sin embargo un desarrollador con experiencia podrá ver el valor de todas estas e implementarlas cuando y como mejor convenga

Que este se encuentre con las pruebas necesarias para asegurar el correcto funcionamiento de este. El código en el futuro siempre cambia, tener que volver a modificar algo que rompiste por un despiste no es algo gracioso, te hace perder tiempo en agregar la funcionalidad, despliegue, hacer rollback, corregirlo y luego volver a desplegar. Además de que el area de negocio no estará feliz si cada cosa nueva que sacas rompe otras cosas y por ende debes arreglar constantemente tu trabajo. Por lo que debieses tener pruebas fidedignas que te permitan avanzar con seguridad de que no estas rompiendo nada.

Nada le entrega mayor confianza a un desarrollador al momento de desplegar que un código con pruebas apropiadas.

Calidad externa

La calidad externa es lo que ve negocio. La interfaz de usuario, que cumpla con los requerimientos, que tenga buen rendimiento en caso de necesitarlo, el texto que aparece en pantalla y que haga sentido el flujo de la aplicación.

Porque primero calidad interna?

Acá ya muchos deben estar molestos por esta opinión pero quédense conmigo, la explicación tiene su lógica.

Un desarrollador necesita de código para poder crear, tiene que indicarle a un computador (posiblemente el ser más estúpido de la creación) cómo debe realizar su trabajo. Cada vez que él escribe código existen miles de posibilidades de que se estén ingresando errores, por lo que él desarrollador debe ser sumamente cuidadoso al momento de redactar código. Debe preocuparse de los casos borde y también del caso general. Esta es una tarea que realiza todos los días, el desarrollo no es fácil, pero es fácil que se introduzcan errores. Por lo que él debe tener las herramientas necesarias para asegurarse de no ingresar errores.

El desarrollo no es fácil, pero si es fácil introducir errores en el desarrollo

El código debe ser fácil de leer. Si el código es fácil de leer para el desarrollador se le aliviana la tarea cuando el este modificando algo, ya que podrá buscar dentro de la pantalla exactamente donde se encuentra algún error o donde debe agregar código para agregar una funcionalidad. La gran mayoría de los errores no son de sintaxis, si no que de lógica. Por lo que intentar encontrar un problema de lógica dentro de varios if, try/catch, for, while, es sumamente difícil. Existirán desarrolladores experimentados que puedan encontrarlo, pero no escribimos código para él, escribimos código para otros humanos.

Agregar funcionalidades debe ser fácil reutilizando la mayor cantidad de código que sea posible. Podemos optar por patrones que nos permitan tomar una tabla que ya hemos creado, transformarla en un componente y sencillamente entregarle la nueva data que esta deba renderizar. Podemos hacer lo mismo con listas, formularios, validaciones, etc.

Si nuestro código tiene una buena estructura, es entendible, sigue patrones establecidos sin intentar reinventar la rueda, si se utilizan los términos académicos correctos para asegurar una buena comunicación entre los desarrolladores estamos un paso adelante para hacer nuestra solución más robusta.

Los patrones o paradigmas que utilices para hacer tu código reutilizable no es muy relevante en primera instancia, lo que si es importante es que empieces a hacer tu código reutilizable.

Otro beneficio de reutilizar la mayor cantidad de código es que este ya se encontrará probado, por lo que tendrás mayor confianza al desplegar y también al desarrollar. Si todas tus funciones o componentes que utilizas para construir lógica de negocio o interfaces de usuario ya se encuentra probado, lo más probable es que solo necesites de un test de integración. Este test de integración será para validar de que la lógica es la correcta y no deberás intentar recorrer todos los caminos posibles.

Es imposible entregar calidad externa sin calidad interna, pero sí es posible entregar calidad externa con calidad interna.

Al hacer tu aplicación para que esta sea reutilizable primero, cada vez que quieras construir una nueva pantalla de tu aplicación será muy rápido, algo que te tomaba días en construir ahora te tomará un par de minutos, pero esto solo se puede con la arquitectura indicada, y para eso, los desarrolladores también deben trabajar sin presión. Al tener presión por sacar los proyectos rápido los desarrolladores abaratarán costos en las cosas que pueden:

  • Pruebas
  • Refactor
  • Diseñar o pensar una arquitectura adecuada

Esto que te menciono las empresas de calidad mundial ya lo saben, por lo que se preocupan de entregarte un ambiente propicio para que puedas desarrollar y pensar tranquila y cómodamente.

Cuando estemos desarrollando tratemos de hacer que cada pull request que creemos intente mejorar la arquitectura existente dentro de un commit, y luego agregamos la funcionalidad con lo que hemos refactorizado

Este post fue más largo, pero espero haber podido meter lo idea de que nuestro código debe ser refactorizado más de lo que posiblemente ya lo hacemos.

Espero que este post te haya gustado, puedes suscribirte en la cajita más abajo, recuerda seguirme en youtube y en twitter, los links más abajo en el párrafo donde sale mi foto.


Suscríbete

Suscríbete a la lista para más cursos, posts y videos tutoriales. Prometo no enviarte más de un correo semanal 🙏

Creado por Nicolás Schürmann ingeniero e instructor de software. Cuando no está programando, esta frente a una cámara dictando cursos, creyéndose youtuber o apoyando a sus alumnos. Puedes seguirlo en twitter o también suscribirte a su canal de youtube. Considera comprar sus cursos por este medio y así apoyas al instructor.