Steel Threads es un enfoque de diseño de software poderoso pero oscuro. Aprender sobre Steel Threads te hará un mejor ingeniero. Puede usarlos para evitar problemas comunes como el dolor de integración. Y puede usarlos para reducir la complejidad del diseño del sistema. Tan oscuro que fue eliminado de Wikipedia en 2013 ¿Qué tan desconocidos son los hilos de acero? El concepto se en 2013 porque "la idea no es notable dentro de la ingeniería de software y no ha recibido una cobertura significativa de fuentes notables". Agreguemos a la cobertura y también analicemos por qué es un enfoque tan útil. eliminó de Wikipedia ¿Qué son los hilos de acero? Un hilo de acero es una porción muy delgada de funcionalidad que se enhebra a través de un sistema de software. Se denominan "hilo" porque entrelazan las diversas partes del sistema de software e implementan un caso de uso importante. Se llaman “acero” porque el hilo se convierte en una base sólida para mejoras posteriores. Con un enfoque de Steel Thread, crea la versión más delgada posible que cruza los límites del sistema y cubre un caso de uso importante. Ejemplo de un enfoque problemático convencional Supongamos que está creando un nuevo servicio para reemplazar una parte de su código base monolítico. La forma más común de hacer esto sería Mire el código anterior y descubra las necesidades del nuevo sistema. Diseñe y desarrolle las API que proporcionan las capacidades que necesita. Ingrese al código anterior y actualice las referencias para usar las nuevas API. Hazlo detrás de una bandera característica. Corte usando la bandera característica. Solucione cualquier problema que surja hasta que funcione, desactivando el indicador de función si es necesario para volver a la ruta del código anterior. Cuando sea estable, elimine las rutas de código antiguas. Suena razonable, ¿verdad? Bueno, esta es la forma más común en que operan los ingenieros de software, pero este enfoque tiene muchas minas terrestres. ¿Qué problemas esperaría en este proyecto? Puede ser atractivo construir el nuevo servicio de una manera desconectada del antiguo sistema. Después de todo, el diseño puede parecer más puro. Pero también está introduciendo un cambio estructural significativamente mayor, y está haciendo estos cambios sin ninguna integración con el sistema anterior. Esto aumenta significativamente el dolor de integración. Mi expectativa sería que todas las estimaciones para el proyecto no sean realistas. Y espero que el proyecto se considere un fracaso después de que se complete, incluso si el servicio resultante tiene un buen diseño en general. Espero que el cambio al nuevo sistema sea problemático. Habrá una serie de problemas descubiertos a medida que cambie que requerirán volver a las rutas de código anteriores o trabajar intensamente para solucionar problemas en las etapas finales del proyecto. Ambas cosas son evitables, al no tener una transición enorme. Tenga en cuenta que incluso reducir más del uno por ciento del tráfico al nuevo servicio con un indicador de función es un enfoque de transición. ¿Por qué? Está recortando todo ese uno por ciento del tráfico a todos los cambios al mismo tiempo. Todavía no esperaría que fuera bien. Estás dando pasos que son demasiado grandes. Ejemplo usando un hilo de acero Compare ese enfoque con la forma de hacerlo de Steel Thread. Piense en el nuevo sistema que está construyendo. Cree algunos casos de uso limitados que representen los subprocesos de acero del sistema: cubren una funcionalidad útil en el sistema, pero no manejan todos los casos de uso o están restringidos de alguna manera. Elija un caso de uso inicial que sea lo más estrecho posible que proporcione algún valor. Por ejemplo, puede elegir una API que crea que formaría parte del nuevo servicio. Cree la nueva API en un nuevo servicio. Haga que funcione solo para ese caso de uso limitado. Para cualquier otro caso de uso, use la ruta del código anterior. Póngalo en producción y en pleno uso. (Consejo: ¡incluso podría hacer tanto la ruta del código nueva como la anterior, y comparar!) Luego, agrega gradualmente los casos de uso adicionales, hasta que haya movido toda la funcionalidad que necesita, al nuevo servicio. Cada caso de uso está en producción. Una vez que haya terminado, extraiga el código anterior y las banderas de funciones. Esto no es arriesgado en absoluto, ya que ya se está ejecutando en el nuevo sistema. ¿No es este también el patrón “estrangulador”? Sí, pero esto también se puede usar para nuevos proyectos. Siga leyendo para ver un ejemplo de greenfield. Los hilos de acero evitan el dolor de integración y le brindan una mayor confianza El dolor de integración es una de las mayores causas de problemas de última hora en los proyectos. Cuando cambia a un nuevo sistema, encuentra problemas que no espera. Debe sospechar de cualquier cosa que implique un corte. Haz las cosas en pequeños incrementos. siempre Steel Threads se integra desde el principio, por lo que nunca tendrá que lidiar con muchos problemas de integración. En cambio, tienes un pequeño dolor de integración a lo largo del camino. Además, su servicio nunca necesita ser probado antes de que entre en funcionamiento, porque lo ha probado de forma incremental a lo largo del camino. Sabe que puede manejar cargas de producción. Ya ha agregado latencia de red, por lo que conoce las implicaciones de eso. Todas las sorpresas avanzan y se manejan de forma incremental, como parte de la forma en que implementa gradualmente el servicio. Lo importante es que tenga un sistema integrado que funcione y, a medida que trabaje en él, lo mantendrá funcionando. Y lo desarrollas con el tiempo. Los hilos de acero pueden ayudar a reducir la complejidad Cuando estás diseñando un sistema, tienes MUCHA complejidad. Crear un conjunto de requisitos para el nuevo sistema puede ser una tarea desafiante. Al utilizar un enfoque de Steel Thread, elige algunos de los requisitos básicos y los formula de una manera que atraviesa las capas del sistema y ejercita su diseño. Proporciona una especie de estructura esquelética para todo el sistema. La implementación de ese hilo de acero se convierte en la base sobre la que se pueden construir requisitos adicionales. Por lo tanto, Steel Threads es un de un sistema. subconjunto de los requisitos Los hilos de acero también se pueden usar en trabajos nuevos Supongamos que está implementando un clon de Slack. Su hilo de acero inicial podría ser algo como: “Cualquier persona no autenticada puede publicar un mensaje en una sala #general codificada en una cuenta codificada. Los mensajes persisten a través de las actualizaciones de la página”. Tenga en cuenta lo limitado que es este hilo de acero inicial. No maneja autenticación, usuarios o cuentas. Maneja escribir mensajes y persistirlos. Su segundo hilo de acero puede hacer que el sistema sea más útil. Podría, por ejemplo, tener un hilo de acero que permita que el cartel del mensaje elija el nombre con el que publicará. Este segundo Steel Thread en realidad no ha hecho mucho. Todavía no tiene autenticación, cuentas o incluso un concepto de usuario. Pero ha creado una sala de chat que funciona lo suficiente como para que pueda comenzar a usarla. Además, tenga en cuenta que no ha pasado el hilo de acero por todas las partes del sistema. Pero ha borrado los conceptos de usuarios y cuentas. Los hilos de acero brindan retroalimentación temprana Tenga en cuenta que en este ejemplo de clonación de Slack, puede obtener comentarios tempranos sobre el sistema que está construyendo, aunque todavía no haya construido tanto. Esta es otra poderosa razón para usar Steel Threads. Después de esos dos hilos de acero, su equipo podría comenzar a usar la sala de chat a tiempo completo. Piense en cuánto aprenderá su equipo al usar su sistema. Es un sistema de trabajo. Compare eso con lo que habría aprendido construyendo los sistemas de usuario y cuenta, conectando todo y finalmente construyendo una sala de chat. Comience con hilos de acero Los hilos de acero suelen ser un buen lugar para comenzar a diseñar sus proyectos. Crean un esqueleto para el resto del trabajo por venir. Fijan las partes centrales del sistema para que haya lugares naturales para desarrollar. Le animo a probar un enfoque de acero roscado. Creo que encontrará que puede transformar sus proyectos. ¡Cuéntame tus experiencias con él! Los hilos de acero están estrechamente relacionados con los cortes verticales Es posible que haya oído hablar del término "corte vertical". Describo el concepto en mi publicación sobre . Hitos Steel Threads es una técnica de diseño de software que da como resultado la entrega de su software en cortes verticales. El término tiende a usarse para describir las rebanadas verticales iniciales de un sistema. Son conceptos estrechamente relacionados, pero no completamente iguales. También he oído hablar de Steel Threads como "balas trazadoras". Imagen de en Steen Jepsen Pixabay Esta historia apareció originalmente en: https://www.rubick.com/steel-threads/
