Deje su legado
Así que has empezado ese nuevo proyecto de campo verde. Tu directorio de proyectos está vacío; tienes que poner los cimientos. Con tu arquitectura en la pizarra, eliges tu pila de tecnología favorita y luego sales a las carreras de construcción de características. Tus clientes están encantados con el rendimiento de las funciones; todo está pulido y se entrega en el plazo previsto o antes.
Entonces, se produce una degradación. Tal vez has introducido un modelo de herencia que se está volviendo difícil de trabajar. En lugar de revisar el modelo, empiezas a usar trucos de herencia furtivos para seguir entregando características. Tal vez has elegido acoplamientos que han empezado a interponerse en tu camino. En lugar de romper los acoplamientos y encontrar otros más apropiados, duplicas los acoplamientos defectuosos porque no tienes tiempo para rediseñarlos. En cualquier caso, empiezas a sacrificar la calidad de las características en favor del rendimiento.
Tus elecciones empiezan a doler. Las adiciones triviales a tu base de código toman demasiado tiempo. Los índices de error están aumentando. Es difícil mantener un modelo conceptual de tu creación en tu cabeza. Tu base de código comienza a avergonzarte. La gente empieza a referirse a ella como código heredado. El canto de sirena de una reescritura total comienza a sonar bastante bien.
Espero que no reconozca estas anécdotas. Pero si lo haces, está bien. Yo también lo hago. Un código base que se desmorona eventualmente evitará que entregue valor a sus clientes. ¿Cuáles son algunas medidas que puede tomar para mitigar este riesgo?
Pagar la deuda técnica
Los equipos en pagar la deuda técnica en una cadencia regular. Al igual que la deuda financiera, la deuda técnica no pagada tiene una calidad de composición que puede ser muy difícil de revertir si se permite que se encone.
Algunos de los equipos dedican el 25% de su tiempo a pagar la deuda técnica. Otros pasan cada martes mejorando la calidad de sus bases de datos. Algunos incluso borran libremente porciones de código para escribirlo de nuevo usando el conocimiento que obtuvieron al escribirlo la primera vez.
Nuestros equipos se animan a elegir sus propias estrategias para gestionar su deuda técnica.
La presión es algo gracioso. Ser consciente de la presión puede mantenerte productivo. Sucumbir a la presión puede ser destructivo. Los plazos son una enorme fuente de presión en la ingeniería. Si cortas los gastos para cumplir con una fecha límite, estás aplazando la implementación adecuada de algo a una fecha posterior. Con demasiada frecuencia parece que la fecha límite nunca llega, las «esquinas cortadas» se acumulan y tu capacidad de entregar algo se ralentiza.
Se necesitan algunos plazos para coordinar los esfuerzos de múltiples grupos dentro y fuera de su organización. Otros plazos son totalmente artificiales, tienen un valor marginal y no reflejan la realidad. Evitamos lo último en . No tenemos fechas límite, tenemos tristezas. Es decir, si no cumplimos con una fecha límite, alguien tiene una tristeza. De vez en cuando nos encargamos de un plazo difícil si tiene sentido hacerlo. Cuando eso ocurre, nos aseguramos de que se tome el tiempo necesario para pagar cualquier deuda técnica que se haya contraído mientras se cumplía el plazo.
Abrazar la mitosis
Parte de nuestra estrategia arquitectónica es mantener pequeñas bases de código. Hacerlo nos permite seguir cumpliendo con eficacia, incluso frente a un rápido crecimiento. Sin embargo, las bases de código crecen. Las bases de código exitosas tienen una tendencia a crecer rápidamente.
¿Pero qué pasa cuando una base de código crece demasiado? Bueno, puede que sea el momento de dividirla. Al igual que la mitosis en la biología celular, nos gusta dejar que esto ocurra de forma natural. Cuando el tamaño o el modelo conceptual de un componente dado comienza a interferir en la forma en que entrega valor, probablemente sea el momento de dividirlo. En ese momento buscamos las costuras que han surgido en el código base y nos dividimos a lo largo de ellas. No sólo el código base se divide, a veces el equipo también se divide.
Un Greenfield perpetuo
A todo el mundo le encanta un proyecto de campo verde. Es fácil trabajar con ellos y el valor sale de ellos sin mucho esfuerzo. Los nuevos patrones son fáciles de implementar, puedes probar y desechar ideas a un ritmo rápido. Con el tiempo estos proyectos se marchitarán sin el cuidado adecuado y se perderán los beneficios del proyecto de campo verde. En , hacemos todo lo posible para dar ese cuidado con el fin de mantener nuestro código en un estado de campo verde perpetuo.
Categorías: cultureTags: architecture, technical debt