Cómo lograr que los compañeros de trabajo apliquen soluciones comunes

No es obvio a partir de su descripción que el control de versiones de la API sea necesario o prudente en este escenario en particular. Supongo que la necesidad tampoco está clara para los otros ingenieros de los que está hablando. Y frases como "conocimiento común" y "estándar de la industria" son una especie de código para "otras personas lo hacen, así que nosotros también deberíamos", que es un argumento de autoridad que rara vez es persuasivo por sí mismo cuando necesita convencer a otras personas para que hagan algo. quieres que hagan.

Lo que debe hacer si realmente quiere hacer esto es comenzar por identificar un problema específico que tenga en este momento y luego construir el caso para la versión de la API sobre eso. Un ejemplo:

Pasamos ## horas el mes pasado reescribiendo la aplicación A porque los cambios en la API estropearon todo. Debido a que gastamos ## en eso, no pudimos agregar la función Z para el cliente Y y perdimos $X en ingresos. En lugar de romper nuestra API, si tuviéramos el control de versiones, habríamos dedicado 5 minutos al cambio de API, completado Z y ganado $X + W porque pudimos comenzar con la función V.

Tenga en cuenta que esta justificación no es abstracta en absoluto; depende enteramente de las cosas que son medibles. Todas las cosas medibles son cosas que un gerente no técnico puede entender: dinero, tiempo (que es dinero), características facturables (que podrían convertirse en dinero dependiendo de cuál sea su modelo de negocio).

Como "ingeniero sénior", no quiero mantener varias versiones de API nunca, porque es mucho trabajo con el que no quiero lidiar. Como "el tipo que hace lo que me dice mi jefe", me esforzaré al máximo si mi jefe me dice que necesitamos mantener varias versiones para ahorrar una cantidad de dinero no trivial.

Por los detalles que me diste, es difícil para mí saber si tienes razón o no. Pero intentaré responder a tu pregunta:

¿Cuál es la mejor manera de empujar, dentro de mis posibilidades y sin que parezca que estoy tratando de hacer el trabajo del otro equipo?

Muy poco por lo que parece, ya que decidir sobre las versiones (o la falta de ellas) me parece parte del trabajo del equipo. Pero si todavía quieres intentar persuadirlos, aquí hay algunas sugerencias:

• No se refiera a "conocimiento común", si fuera conocimiento común, todos ya estarían de acuerdo con usted

• Prepárate para equivocarte. Hay un equipo de personas mayores que trabajan en el tema a tiempo completo y todos tienen una opinión diferente a la tuya, en realidad es muy probable que estés equivocado.

• Trate de entender por qué se hizo la elección y qué problemas anticipan las personas mayores.

• Describa su caso de problema (la razón por la que necesita el control de versiones) lo mejor posible y su tarea para averiguar si hay otras soluciones para su problema.

• Averiguar que otros equipos se beneficiarían al implementar el control de versiones

Luego reúne toda su investigación en un caso sobre cómo el control de versiones podría beneficiar a la empresa (prepárese para presentar números), cómo se pueden abordar las mayores preocupaciones contra el control de versiones y con qué esfuerzo se puede implementar y mantener.

Si no solo está abierto a que otra persona cambie de opinión, sino que está trabajando activamente para lograrlo y nadie ha cambiado de opinión mientras recopilaba toda la investigación, es muy probable que tenga razón y los demás no podrán estar en desacuerdo :)

Este es uno de esos escenarios de pasar tiempo ahora para ahorrar tiempo más adelante. Las personas que calculan los costos rara vez consideran los ahorros futuros porque esperan que no se materialicen. Por lo general, solo quieren ahorros a corto plazo. Como resultado, se ve obligado a escribir un código incorrecto rápido y corregirlo en cada versión posterior.

Esto conducirá a escenarios bastante divertidos pero frustrantes en los que verá un código como este

var oldDate = api.convertDateTime(input);
//.....some code
var newDate = api.convertDateTime1(input, format);
//.....some code
var finalDate = api.convertDateTime2([oldDate, newDate], format);

Y la razón es simple, nadie quiere mirar hacia atrás y ver dónde se usó api.convertDateTime y corregir cualquier uso, por lo que crean una nueva versión. Pero no hay diferencia en lo que hace, así que obtienes un número. Luego, vuelve a suceder, alguien quiere agregar un formato y es obligatorio, pero no quieren volver atrás y corregir todos los usos anteriores, por lo que crean otra versión nueva. Y finalmente, alguien quiere convertir varias fechas en 1 línea, por lo que crea otra versión nueva y nuevamente no quiere hacer una prueba de regresión de cada uso anterior, así que nuevamente, otra versión nueva.

Y así, nace una mala versión del control de versiones de API.

Entonces, ¿cómo evitar esto? Tienes que convencer a la gente de que dedicar tiempo ahora evitará el lío que acabo de describir. Esto no es algo fácil de hacer y juega mucho en la cultura de la empresa. También es muy importante si su departamento es un centro de costos o un centro de ganancias. A un centro de ganancias a menudo se le permite planificar con anticipación. Suele ser necesario un centro de costos para mantener los costos lo más bajos posible cada año, sin importar cuánta deuda técnica acumule.

Así que tu argumento es simple:

Debe mostrar algunos ejemplos de versiones que salieron mal.

Muestre algunos ejemplos de mejores versiones.

Y, lo que es más importante, grafique el costo de tiempo entre los métodos para que el suyo parezca más económico a largo plazo. Si vienes armado con números, no serás ignorado.

En mi experiencia, generalmente se hace un compromiso, donde se crea una primera versión de la API, y luego se construye un sistema de versiones bajo la idea de que inicialmente habrá demasiadas versiones para realizar un seguimiento, así que espere la API. estabilizarse y madurar antes de preocuparse por las versiones. Luego se dedica tiempo a actualizar todos los usos antiguos de la API para proporcionar una versión una vez que existe, o cualquier uso sin una versión especificada se supone que es la versión 1.

En lugar de preocuparse por una solución particular a su problema (es decir, el control de versiones), concéntrese en los principios de gestión de cambios/tiempo de actividad que necesita que cumpla la API. Es justo decir que los cambios en la API nunca deberían romper ninguna aplicación cliente por sorpresa, que la API debería tener muy poco tiempo de inactividad y que cualquier cambio importante en la API se anuncia con la mayor anticipación posible.

Si puede ponerse de acuerdo sobre estos principios, deje que los desarrolladores de API (o el grupo) decidan cómo alcanzar estos objetivos.