Cómo refactorizar para Startups 2022: razones y compensaciones

(Publicado en forma cruzada desde el sitio web de Klotho )

Esta publicación de blog es una descripción general de alto nivel sobre las razones para refactorizar el código y los sistemas en una configuración de inicio. Cubrimos riesgos, enfoques y compensaciones a considerar en 2022.

Cómo juzgar cuándo el costo vale la pena las ganancias

Se honesto contigo mismo

La tentación siempre será refactorizar: el código del mundo real es desordenado y a los ingenieros no les gusta el código desordenado. Asegúrese de que haya un caso comercial para la refactorización al medir cuánto tiempo dedica el equipo a las funciones directamente visibles para el cliente.

Nuestra investigación muestra que las empresas medianas y las nuevas empresas de rápido crecimiento gastan el 39 % de la capacidad de ingeniería en trabajo no diferenciado, como la infraestructura. Divida las historias en subtareas como infraestructura y refactorización para que pueda medir a dónde va su tiempo.

Bien estructurado está bien mantenido

Los límites claros entre los módulos los hacen más fáciles de probar, implementar y monitorear. Esté atento a los errores informados por los clientes, la latencia del servicio y la frecuencia con la que tiene que revertir el código. En el otro extremo del ciclo de vida del software, existen múltiples indicadores de que se está tendiendo hacia un cuello de botella: cuánto tiempo se tarda en pasar del diseño a la entrega, el grado de satisfacción de la ingeniería y el aumento de los costos de infraestructura; todos estos pueden ser indicadores principales. que ha acumulado una deuda.

Puntos de inflexión en los negocios

Las bases de código tienden a organizarse en tres dimensiones: tamaño del equipo, ritmo de nuevas funciones y número de clientes. Cuando estos números cambien significativamente, puede ser el momento de analizar la división de componentes.

Si está haciendo crecer el equipo o aumentando la tasa de desarrollo de características, el factor limitante será la legibilidad del código. Comience con una refactorización oportunista y dirigida. Si su base de clientes está creciendo, es posible que necesite tecnologías o flujos de trabajo más escalables.

Controla lo que puedas, planifica el resto

Elegir bien no impedirá la reorganización

La refactorización y la nueva arquitectura no significan que haya tomado una mala decisión antes. Más a menudo, las fuerzas impulsoras detrás de la re-arquitectura están ligadas a cambios en los requisitos o factores externos. Hay al menos 4 dimensiones importantes que obligarán a rediseñar la arquitectura durante la vida útil de un producto: tasa de desarrollo de nuevas funciones, tamaño del equipo de ingeniería, cantidad de tiempo dedicado a trabajo no diferenciado y crecimiento de clientes. Cada uno de estos es progresivamente más difícil de controlar directamente.

Comience con los diales fáciles...

De las cuatro dimensiones, las dos que son más fáciles de controlar son la tasa de nuevas funciones y el tamaño del equipo de ingeniería. Puede controlar la tasa de nuevas funciones siendo más estricto con la planificación y la priorización. Escalar el equipo es un proceso más lento, pero generalmente es uno que al menos puede planificar.

Si tanto el equipo como la tasa de nuevas características son pequeños, es poco probable que la refactorización tenga un impacto significativo en el negocio. En el otro extremo del espectro, un gran equipo que trabaja en muchas funciones puede beneficiarse de la reorganización en equipos más pequeños, y debe considerar refactorizar o rediseñar el código para que coincida. Una arquitectura que permita límites organizativos y de código más limpios permitirá que el producto y la empresa crezcan.

…y luego pasar a los más difíciles

La cantidad de tiempo que su equipo dedica al trabajo no diferenciado puede ser difícil de controlar, y el crecimiento de los clientes es la medida más difícil de afectar. Si esto fuera fácil, ¡todos minimizarían el trabajo no diferenciado y maximizarían el crecimiento de clientes! Aún así, puedes

adelántese a los problemas con un enfoque cuidadoso y proactivo para la refactorización.

El primer paso es saber cuándo no refactorizar. Si el crecimiento de sus clientes y la cantidad de tiempo dedicado a trabajos no diferenciados es bajo, no dedique tiempo a la refactorización: concéntrese en cambio en características impactantes y visibles para el cliente. Del mismo modo, si tiene un buen crecimiento de clientes y poca cantidad de trabajo no diferenciado, su equipo lo está haciendo bien. Considere la refactorización táctica para evitar que aumente la cantidad de trabajo no diferenciado, pero no le dedique demasiado tiempo.

Si su equipo dedica demasiado tiempo a un trabajo no diferenciado, es hora de revisar la arquitectura a una que se adapte mejor a la situación actual de su empresa.

Si la adopción de su cliente es menor, su prioridad debe ser una arquitectura más económica que le brinde más pista.
Si tanto la adopción de sus clientes como la cantidad de tiempo que su equipo dedica al trabajo no diferenciado son altas, puede ser el momento de centrarse en una solución centralizada y optimizada. Esto generalmente toma la forma de un equipo de operaciones dedicado que puede ejecutar de manera eficiente las tareas de infraestructura. Este es un gran problema, ¡así que tómese un momento para felicitarse a sí mismo y a su equipo por haber llegado hasta aquí!

Tenga un objetivo, luego encuentre atajos para llegar allí

Ten un plan, incluso si no es perfecto

Una vez que se haya comprometido con una nueva arquitectura, no tenga miedo de pensar en grande. Apóyese en sus ingenieros para encontrar un estado final que les encante y luego redúzcalo según sea necesario. Lo más probable es que la oportunidad de una reorganización importante solo se presente una o dos veces en el ciclo de vida de un producto, así que prepárese para vivir con cualquier compromiso que haga. Pero del mismo modo, sepa que incluso los mejores planes saldrán mal cuando comience a implementarlos.

Haz grandes planes, da pequeños pasos

Una vez que sepa dónde quiere que esté el código, sea táctico acerca de cómo llevarlo allí. Trabaje con un componente a la vez, o elija componentes que estén lo más alejados posible entre sí. Si aún no ha invertido en pruebas sólidas, tanto a nivel de unidad como de sistema, ahora es el momento. Las pruebas le darán la confianza de que sus cambios no interrumpirán las experiencias de los clientes existentes, pero también pueden ayudar a su equipo a definir su definición de hecho. Cuando pasen las pruebas, ¡el componente estará listo!

La mejor tecnología es la que puedes adaptar

La clave para reducir el impacto de la refactorización y la remodelación de la arquitectura en las nuevas empresas en particular es utilizar tecnología que sea adaptable.

Históricamente, las empresas eligen tecnologías específicas como máquinas virtuales, sin servidor o contenedores para alojar sus aplicaciones. El problema es que cambiar de una tecnología a otra es prohibitivamente costoso y lo que necesita hoy puede no ser lo que necesite mañana.

Una arquitectura adaptativa es aquella que le permite alojar su aplicación en cualquier tecnología con la misma facilidad. Esto le permite ajustar el entorno de alojamiento sobre la marcha, para que coincida con sus necesidades actuales. Las opciones tecnológicas específicas como AWS Lambda, Fargate, Kubernetes, gRPC, Linkerd, Azure/GCP se vuelven intercambiables.

Al reutilizar construcciones de lenguajes de programación existentes como funciones y controladores de eventos, así como interfaces que son idiomáticas para cada idioma, las arquitecturas adaptables hacen que los servicios en la nube sean más fáciles de usar.

Busque abstracciones y herramientas que sean livianas, pero lo suficientemente flexibles como para permitirle cambiar de tecnología. Creemos que las anotaciones de Klotho cumplen los requisitos, ya que le permiten separar el significado semántico de su arquitectura de la configuración de implementación, pero con una inversión suficiente en bibliotecas de tiempo de ejecución y automatización de la infraestructura, puede crear una solución similar usted mismo.