Get best of the week

Vendemos refactorizaci贸n de arquitectura a un cliente o cu谩l es el problema de los desarrolladores

La refactorizaci贸n arquitect贸nica o de dise帽o siempre es un problema doloroso en un proyecto. Los beneficios de la refactorizaci贸n son obvios para nosotros los especialistas t茅cnicos, pero a menudo es dif铆cil para el cliente vender y corroborar esta idea. La raz贸n principal es que nosotros, los especialistas t茅cnicos, no sabemos c贸mo hablar con las empresas.

imagen

El principal problema es la comunicaci贸n entre t茅cnicos y personas que ganan dinero. Hablan idiomas diferentes, aunque intentan resolver los mismos problemas.

Este art铆culo es una traducci贸n del original del ingl茅s: Refactorizaci贸n de arquitectura y Refactorizaci贸n de dise帽o C贸mo venderlo Cliente . Si tiene colegas que no hablan ruso, pueden leer el original en mi bulbo.

Los beneficios de la refactorizaci贸n son obvios para todos los profesionales t茅cnicos, pero a menudo no podemos transmitir esta idea a la empresa. 驴Por qu茅 pas贸 esto? Nos saltamos algunos pasos menores pero muy importantes para el negocio.

Dividimos todo el proceso en 6 pasos simples pero necesarios:

  1. Determinar la causa del problema.
  2. Decida qu茅 cambios deben hacerse.
  3. Justificaci贸n de la decisi贸n.
  4. Haz un plan de refactorizaci贸n
  5. Crear hoja de ruta
  6. Presente su decisi贸n

Encuentra la causa del problema


Este paso nos es bastante familiar como especialistas t茅cnicos. Consid茅relo con ejemplos reales.

La compilaci贸n se bloquea despu茅s de casi cada confirmaci贸n.

Hay varias razones por las cuales esto puede suceder:

  • Los componentes de la aplicaci贸n est谩n estrechamente relacionados y dependen unos de otros.
  • Los componentes de la aplicaci贸n no tienen el aislamiento adecuado
  • Falta de pruebas unitarias
  • Falta de procesos SDLC y CI / CD

Un ejemplo mas. La implementaci贸n de aplicaciones lleva mucho tiempo y tambi茅n se observan problemas de rendimiento.

Las razones principales pueden ser:

  • Una aplicaci贸n monol铆tica crece r谩pidamente y se ha vuelto demasiado grande para una aplicaci贸n
  • La aplicaci贸n es grande y consume mucha RAM y potencia de procesador.
  • La aplicaci贸n es compleja y no est谩 bien escrita.

Decida qu茅 cambios deben hacerse.


El siguiente paso es un poco m谩s complicado, pero sigue siendo familiar y sencillo para los desarrolladores senior +. Todos somos buenos expertos t茅cnicos y siempre sabemos lo que hay que mejorar. Y en este momento cometemos un error y corremos hacia el cliente con las palabras hag谩moslo .

Pero somos arquitectos inteligentes y seguiremos nuestro plan de 6 pasos paso a paso.

Basado en el ejemplo anterior con una aplicaci贸n monol铆tica, las soluciones son obvias. Divida una aplicaci贸n grande y compleja en m贸dulos m谩s peque帽os e independientes. Estos son los primeros pasos para una arquitectura orientada a servicios o microservicios.

imagen

Justificaci贸n de la decisi贸n.


Dividiremos este paso en dos fases: justificaci贸n t茅cnica y comercial .

La l贸gica t茅cnica nos parece l贸gica. Divida el monolito en servicios m谩s peque帽os, como resultado de lo cual obtenemos:

  • Componentes m谩s dispares
  • Los problemas de construcci贸n no ser谩n tan frecuentes
  • Como resultado, los servicios peque帽os consumen menos RAM y potencia de procesador: mejor rendimiento
  • Los servicios separados se pueden implementar m谩s r谩pido e independientemente uno del otro

La justificaci贸n desde el punto de vista comercial es un paso muy importante que los expertos t茅cnicos suelen olvidar. Debe recordar lo que es importante para los negocios. As铆 es , es dinero .

En resumen: si la refactorizaci贸n no beneficia al negocio, no tiene sentido hacerlo.

Seg煤n nuestro ejemplo, puede ofrecer al cliente los siguientes beneficios:

  • Las nuevas caracter铆sticas se desarrollar谩n m谩s r谩pido
  • La calidad de la aplicaci贸n ser谩 mejor, como resultado de menores costos para la correcci贸n de errores y un usuario satisfecho de la aplicaci贸n, lo que tambi茅n afecta positivamente al negocio.
  • Costos reducidos de desarrollo e implementaci贸n
  • Es m谩s f谩cil encontrar profesionales motivados y experimentados que est茅n listos para trabajar con el proyecto.

Plan de refactorizaci贸n


El plan debe ser claro y detallado. Cada iteraci贸n debe describirse claramente y todos los cambios arquitect贸nicos y de dise帽o deben documentarse.

imagen

Crea tu plan debes responder las siguientes preguntas:

  • 驴Cu谩l es el prop贸sito de esta iteraci贸n?
  • 驴Cu谩l es el valor t茅cnico y comercial de esta iteraci贸n?
  • 驴C贸mo acortar el tiempo de iteraci贸n?

Mapa vial


Un paso muy importante . T贸mese el tiempo para hacer esto si realmente quiere vender refactorizaci贸n a un negocio.

Cada gerente y empresario quiere saber las respuestas a dos preguntas:

  • 驴Cu谩nto cuesta?
  • 驴Cu谩nto tiempo tardar谩?

Intenta dividir la refactorizaci贸n en peque帽as iteraciones. Cada iteraci贸n debe aportar valor t茅cnico y comercial. Es bastante dif铆cil vender refactorizaci贸n durante a帽os y cuesta millones de d贸lares sin ning煤n resultado intermedio.

Cada iteraci贸n debe contener informaci贸n sobre la duraci贸n y el n煤mero de especialistas necesarios para esto. Esta informaci贸n ayudar谩 al gerente a responder dos preguntas b谩sicas un poco m谩s altas.

Recopile m茅tricas del proyecto antes y despu茅s de refactorizar en cada iteraci贸n. Esto lo ayudar谩 a mostrar qu茅 valor t茅cnico y comercial aport贸 esta iteraci贸n.

Presento mi decision


Antes de ir con su decisi贸n al negocio, verif铆quelo con su gerente inmediato. Una vista lateral siempre es buena, especialmente si es una vista lateral comercial. Quiz谩s su gerente tenga m谩s contexto y lo ayude a cambiar el plan de acuerdo con las expectativas del negocio.

Necesita saber c贸mo responder a la pregunta cl谩sica.

Por lo general, cuando presenta una refactorizaci贸n arquitect贸nica, una empresa puede preguntar. 驴Por qu茅 necesitamos refactorizar? El a帽o pasado gastamos suficiente dinero en arquitectura, y ahora tenemos problemas nuevamente.

Hay una respuesta cl谩sica a la pregunta cl谩sica. Esta soluci贸n arquitect贸nica era buena hace un a帽o, pero el negocio est谩 creciendo y cambiando, y la arquitectura debe cambiar con ella.

Consejo n煤mero 2. No haga que su cliente entre en p谩nico. Proporcione informaci贸n tan urgente, pero no como un desastre. Digamos que tiene seis meses para refactorizar, pero necesita comenzarlo hoy.

Por fin . Al presentar su decisi贸n, intente educar a las personas, no culpar. Recuerda que cuando culpes a la gente, encontrar谩s resistencia de parte de ellos. Debe buscar formas de resolver problemas, no los culpables.

Finalmente


  • La refactorizaci贸n es costosa y dif铆cil de vender a las empresas
  • La refactorizaci贸n arquitect贸nica no es solo un problema t茅cnico, sino que tambi茅n debe venderse a una empresa
  • Recuerde los beneficios de refactorizar su negocio.
  • Siempre es m谩s f谩cil vender refactorizaciones peque帽as, pero a menudo que grandes, pero una vez

Puede encontrar m谩s art铆culos sobre arquitectura y habilidades de arquitectura en el recurso original.

隆Buena refactorizaci贸n para todos!

More articles:


All Articles