Hace algún tiempo, observé una distorsión de las técnicas aplicadas en la producción de software. Habiendo profundizado en los detalles (aplicación de DDD), quería insinuar al lector que, siguiendo el liderazgo de la gestión del búho, uno no puede cumplir con su deber como ingeniero.

Un reciente artículo de alto perfil sobre los reyes desnudos de la industria me hizo darme cuenta de que todavía quiero expresar mi comprensión de qué tipo de programador quiero ser y qué quiero ver a mi alrededor: ingenieros que entienden el contexto de su trabajo, su papel y los métodos que deben seguirse. . Debajo del corte, invito al lector a pensar conmigo sobre lo que estamos haciendo en general y lo que esto impone a las limitaciones de los desarrolladores en sus actividades.

Sobre la causa de la contradicción

Comenzaré desde lejos, desde el siglo XVIII. El desarrollo y la socialización de la producción, junto con la competencia, estimulan a los productores una y otra vez para modernizar y automatizar la producción. Los motores de vapor, el telar Jacquard, los transportadores, las líneas de producción y los robots, todas estas mejoras desempeñan su papel económico , brindan una ventaja competitiva, como requisito previo para una mayor socialización de la mano de obra, a saber, la unificación de las cadenas de producción. Como resultado, la producción se está expandiendo, pueden planificar su desarrollo y automatización para recibir ganancias aún mayores.

Por supuesto, cualquier negocio siempre tiene una alternativa a los métodos de ganancias. Por ejemplo, contrate mano de obra más barata, gerentes efectivos que podrán reducir tres pieles de estos trabajadores. Sin embargo, si usted, como creo que la humanidad no debería quedarse quieta, sino avanzar hacia el progreso, entonces estará de acuerdo conmigo en que esta no es una opción que nos convenga. Sí, todas estas tiendas sin vendedores están muy asustadas, porque los drones están entregando cada vez más productos, esa IA está lista para reemplazar a los conductores, y así sucesivamente. Los economistas están asustados por la aparición de industrias con un costo aproximado de cero. Sin embargo, los ingenieros, diseñadores, inventores, arquitectos y solo científicos todavía tienen que hacer su trabajo, para reducir el costo de producción al mejorar su calidad, esta es nuestra tarea socioeconómica.

Para no hablar de asuntos demasiado importantes, propongo ir a nuestras actividades inmediatas. Para los negocios, siempre hay una opción: poner a 10 personas en 10 unidades para hacer un trabajo simple, o 4 personas en 25 unidades automatizarán este trabajo y luego lo atenderán. Y su clara comprensión de las complejidades de las necesidades comerciales y los requisitos de ingeniería pueden ayudarlo a tomar esta decisión hacia un camino de desarrollo intensivo. ¿Y qué significa para el cliente elegir ese camino?

Parte del día trabajamos para nosotros y parte del día para el empleador o el cliente. Me permitiré expresar esto con la siguiente fórmula de valor:

donde

c es capital fijo , es decir herramientas de organización que le permiten llevar a cabo sus actividades (computadoras, software, etc.).
v - salarios de los empleados.
m es el beneficio nocional de quienes poseen la producción.

En el caso del desarrollo de software, hay matices: si el software es una parte del servicio de una empresa que está en constante evolución, entonces debe realizar un trabajo directamente que no esté relacionado con la resolución de un problema empresarial. Sienta la diferencia: lo que se podría gastar en unas pocas personas con menos habilidades se gasta " en el trabajo por el trabajo futuro ". Si transferimos esto a la fórmula, significa que estamos trabajando a favor del capital constante c , debemos gastar dinero de los salarios de alguien v , de las ganancias m o del costo de los bienes W. Debe considerarse con más detalle.

Entonces, por ejemplo, si propone resolver la arquitectura de su monolito y dividirlo en microservicios, pero su cliente no tiene una necesidad directa de esto, ¿cuánto le costará la sofisticación de ingeniería?

• m - el cliente puede renunciar a su beneficio. El nombre de esta inversión, es decir riesgo controlado de mayor beneficio. En este caso, el riesgo debe ser reconocido. Si decide aprender a hacer grandes complejos para el dinero de otras personas, este es un riesgo incontrolado. Otra cosa, como parte de una retrospectiva, por ejemplo, es realizar un pequeño experimento, evaluar los resultados y avanzar más.

  
  

• W : el cliente puede aumentar el precio de sus productos y servicios. Los monopolios pueden darse el lujo de aumentar el costo y lo más probable es que lo hagan. Pero lo más probable es que el cliente siempre se vea sacudido por las condiciones del mercado.

  
  

• v - Puedes renunciar al salario de otra persona, y hay opciones.
  1) Sacrificarás los tuyos. Procesará o realizará un proyecto de código abierto que lo ayudará en el trabajo.
  2) Automatizas el trabajo de otra persona, lo que permitirá que menos personas lo usen.

  
  

  La gente ingenua como yo elige la opción 1, desafortunadamente. Pero si tiene éxito en 2, entonces está cambiando la cadena de producción cualitativamente: necesita menos que solo manos de trabajo y más y más personas con experiencia que puedan crear y modificar correctamente los procesos.

  
  

El problema con el equipo es que no decide qué hacer. Pero puede generar discusiones y el negocio no se verá afectado por nada que no sea material: la belleza del código, el nuevo marco, la técnica de moda, no se trata de dinero. Existe una conexión en inversiones en complejidad tecnológica y necesidades comerciales. Uno debe corresponder al segundo.

Antagonismo de requerimientos

El software es una solución compleja que es el equilibrio de dos contradicciones dialécticas: requisitos comerciales y arquitectura. Al evaluar la complejidad de diseñar un sistema en particular, puede ser extremadamente simple pasar por alto los argumentos de las partes opuestas por su naturaleza. Es importante comprender el contexto, el tipo de tarea que enfrenta, independientemente de su rol en el proyecto: propietario del producto o equipo .

• Al lado comercial (PO, SH) le gustaría trabajar para gastar la menor cantidad de recursos en él. Desafortunadamente, presentar esta posición es muy simple, porque ha penetrado no solo en nuestras vidas, sino también en el folklore de TI: una lechuza es un administrador efectivo, el ejemplo más llamativo.
• Los ejecutores (equipo) deben llevar a cabo un conjunto de trabajos de este tipo para garantizar la solución de los aspectos clave de la arquitectura para resolver un problema empresarial, sin acumular deuda técnica, idealmente, y herramientas para resolver problemas más rápidamente. El equipo de negocios es el suministro de software, y la arquitectura es el capital constante disponible.

Para encontrar un denominador común, sugiero hacerle al cliente las siguientes preguntas antes de cada nuevo proyecto:

• ¿Qué estamos haciendo exactamente por el cliente, cuál es el beneficio esperado?
• La frecuencia de aplicabilidad de esta solución.
• La probabilidad de cambios / requisitos de expansión.
• ¿Existe una conexión con otros sistemas / servicios / contextos?

El número de requisitos por parte de la empresa y la arquitectura debe ser proporcional, de lo contrario, la clase de la tarea planteada y resuelta no es proporcional, y si los requisitos crecen de un lado u otro, la solución puede retrasarse o reestructurarse. En otras palabras, para que el cliente pueda resolver mejor sus problemas, también debemos tener los medios apropiados para resolver los problemas de desarrollo. Es decir soldadura de gas y un mazo, nadie construirá un cohete para los astronautas.

Entonces, si la tarea es pequeña y el cliente necesita resolverla con una cantidad mínima de recursos, si la tarea no se repite, no está conectada con sistemas grandes, la solución TransactionSript, un cliente inteligente y todos los antipatrones son aceptables. Seamos realistas: existen tales problemas y deben resolverse de la misma manera, a veces muy rápidamente (pero no olvidemos marcar esto con una deuda técnica). Pero solo en este caso, no se deje engañar por modelos anémicos en tuberías y otras medias tintas.

Las tareas asociadas con los sistemas existentes se pueden resolver sobre la base del sistema existente, haciendo un análisis mínimo de los procesos internos, si la tarea no se expande o no se esperan cambios en los requisitos, la solución TableModule, la base de datos compartida, etc.

Los requisitos comerciales importantes pueden generar demandas importantes en la arquitectura (por ejemplo, mayor disponibilidad, autorización, tolerancia a fallas, rendimiento). A su vez, la arquitectura puede abrir oportunidades para resolver nuevos problemas (que se asocia principalmente con la transición a una plantilla arquitectónica más compleja y evitar escenarios específicos).

Muy a menudo, en conferencias y reuniones, los desarrolladores preguntan a los oradores: ¿cómo convencer a nuestros empleadores de que necesitan dedicar tiempo a algo (pruebas, arquitectura, documentación, etc.)? Para tareas de alto nivel, probablemente no hay alternativa. La razón de esto es el ciclo de vida de los productos, servicios y organizaciones.

El ciclo tecnológico determina el desarrollo (al mismo tiempo): para ingresar a la siguiente etapa de desarrollo, es necesario ir más allá de los límites del proceso tecnológico actual. Es decir expanda sus prácticas, pruebe algo nuevo, configure experimentos controlados.

Gradualmente, a medida que el número de soluciones complejas de plataforma exceda una cierta cantidad, se convertirá en un crecimiento cualitativo. Costos negativos para la deuda técnica, la arquitectura puede convertirse en una inversión en tareas más complejas, negando el propósito original.

Ágil, CI, DDD, etc. Permitirle empujar los límites del proceso. Estas áreas de conocimiento y metodologías, que ayudan a evaluar la complejidad de las tareas de muchas maneras, establecen el trabajo en equipo. ¡Percibo correctamente estas cosas como holísticas , como una oportunidad para que muchos contribuyan mucho para obtener exactamente el resultado que necesita!

Del balance de requisitos al balance de trabajo

Al hablar sobre el ciclo de vida del software, los entrenadores de moda y los entrenadores ágiles no recordarán el famoso diagrama de I. Adizes.

Todo en él es bonito y hermoso, pero es unilateral. Por lo tanto, la subjetividad del modelo no refleja el proceso de organización interna. Muchos equipos están de acuerdo con la empresa cuánto tiempo pasarán en deuda técnica y varios aspectos de la arquitectura. Le ofrezco mis pensamientos sobre este tema: el eje del ciclo tecnológico (OTC).

El eje de abscisas se toma como la complejidad de las características comerciales. El eje de ordenadas es la complejidad del trabajo arquitectónico. Por complejidad quiero decir puntos cursi de la historia. Al retrasar el rendimiento de las funciones en este gráfico, puede ver qué tan adaptable es al software que libera a los cambios posteriores.

• Cuanto más correcto sea el último punto del gráfico relativo a OTC , antes será útil el producto y más difícil será desarrollarlo para tareas complejas.
• A la izquierda del último punto del gráfico relativo a OTC , más se deja llevar por las plataformas, y corre el riesgo de no proporcionar software de trabajo en la fecha límite.
• En consecuencia, vale la pena adherirse al desarrollo uniforme, es decir movimiento a lo largo del eje.

En la figura anterior, mi idea de cómo se ve el tiempo dedicado a implementar la oportunidad de negocio X y la arquitectura Y , donde el eje Z refleja la utilidad del producto.

Conclusión

Si las tareas comerciales requieren una arquitectura compleja, aparecerá, y viceversa, la arquitectura puede ser un motor para resolver problemas complejos, que sin embargo deben tener requisitos previos: la posibilidad de optimización de procesos. Cuando el cliente tiene una serie de tareas complejas que son difíciles de resolver con las herramientas actuales, es posible que puedan resolverse con la ayuda de un cambio cualitativo. Para llegar a un cambio cualitativo, ciertos cambios deben acumularse secuencialmente. Por ejemplo, para cambiar a microservicios, el monolito a menudo se divide consistentemente en contextos y agregados limitados, y el CI se logra consistentemente. Y viceversa, como casos en los que tiene que agregar funcionalidad al código heredado, y para que esto haga una refactorización secuencial.

Obra arquitectónica compleja: su contribución puede ayudar a una empresa a ser más rentable y competitiva. Al mismo tiempo, es importante evitar compromisos y enfoques comprometedores en el diseño y la implementación a favor de beneficios rápidos y momentáneos. Hoy elevará el KPI de alguien, y mañana no podrá realizar nuevas funciones a tiempo debido a los problemas acumulados del producto.

Recomiendo mirar la conexión entre el ajuste y los negocios en un informe de las guerras de la plataforma Cyril Skrygan (IDE) .