Fácil de mantener la cultura corporativa en palabras. Sin embargo, solo unas pocas empresas están explorando activamente las pocas características de la cultura corporativa que tienen un impacto significativo en la productividad, porque es la más difícil.
Para los equipos de software, la propiedad del código es un predictor clave del bienestar de la ingeniería. En esta guía práctica, analizaremos exactamente cómo integra este principio en el trabajo diario de su equipo de desarrollo, para que el bienestar de su base de código se mantenga por sí mismo.
Tuve la suerte de reunirme con algunos de los mejores desarrolladores del mundo: en Stepsize trabajo con ellos todos los días. Y durante las discusiones sobre cómo se crea la deuda técnica, con los principales desarrolladores de empresas como Skyscanner, Spotify, Palantir y otras, siempre se plantea una pregunta: la propiedad.
Al interactuar estrechamente y desarrollar equipos rápidamente (bueno, es decir, en equipos modernos), donde los desarrolladores pueden comprometerse con cualquier parte de la base del código, el código se desordena fácilmente y se convierte en un monstruo similar a Frankenstein. Y cuando las cosas se ponen lo suficientemente mal, alguien debería intervenir, como el Capitán Marvel, y arreglarlo todo con una gran refactorización.
Para evitar esta situación, los equipos de desarrollo intentan adherirse a uno de los muchos buenos consejos de Robert S. Martin ("Tío Bob"), a saber, las " Reglas de Boy Scout ": mantenga el código en mejores condiciones que antes . Aquí hay una extensión gratuita para VSCode para ayudarlo a hacer esto mucho más fácil .
Sin embargo, a pesar del nivel de habilidad y los mejores incentivos de los desarrolladores, parece que la ley inmutable del desarrollo de software es que la deuda técnica se acumula, hasta que se vuelve demasiado, y luego tenemos que hacer tiempo para muchas refactorizaciones. . Hemos sido reacios a aceptar esto como parte del ciclo de vida de desarrollo de software.
¿Quizás todo se reduce a una falta de disciplina?
Eso pensé antes. Y luego conocí a Gareth Vizaji , el arquitecto jefe de Snyk.io , y me golpeó con la siguiente frase:
La propiedad es el principal indicador del bienestar de la ingeniería.
¿A qué se refería? ¿Y cómo podría hacer tal declaración?
Existe una gran cantidad de investigaciones que demuestran que cuando los miembros del equipo son dueños de los frutos de su trabajo, son responsables ante los gerentes y se responsabilizan por el éxito y el fracaso, comienzan a suceder todo tipo de cosas buenas.
Desafortunadamente, lograr esto en la práctica no es fácil. En parte porque, al parecer, la productividad de la ingeniería no puede medirse , y las prácticas modernas de desarrollo pueden verse como alentadoras de la falta de propiedad del código en cualquier circunstancia. La verdad es que hasta ahora era increíblemente difícil medir correctamente la propiedad de los equipos de desarrollo ... por lo que ni siquiera sabíamos cuán "bueno" parecía este indicador.
Afortunadamente, la investigación científica reciente ha demostrado que la propiedad del código, la mejor medida indirecta de la vaga noción de "propiedad" en los equipos de desarrollo, puede medirse mediante la actividad de compromiso de Git. Y este es un maravilloso indicador principal del bienestar de su base de código.
Esas partes de la base de código en las que muchos desarrolladores realizan cambios están abarrotadas con el tiempo, y aquellas con las que trabajan menos personas generalmente están en mejores condiciones. No confíe en mi palabra: las buenas personas de Microsoft lo han estudiado con su propio ejemplo.
Fuente: estudio de Microsoft
Casi puedo escuchar a algunos de ustedes gritar que no quieren una situación en la que solo un desarrollador sea la única persona a la que se le permita tocar algún fragmento de código; este enfoque tiene terribles efectos secundarios. Te entiendo, y esto no es lo que ofrecemos.
Escúchame hasta el final.
Existen varias formas de propiedad del código adecuadas para diferentes circunstancias.
Propiedad colectiva y falta de propiedad
La propiedad colectiva es la [...] propiedad en la que el código es de propiedad conjunta, pero las responsabilidades y los horarios están claramente definidos. Cada miembro del equipo puede trabajar en cualquier subsistema o servicio, si es necesario.
No propiedad : [...] una situación en la que varios desarrolladores realizan cambios en el mismo subsistema, pero la coordinación de acciones, la responsabilidad por la calidad o la comunicación del equipo es mínima. En tales sistemas, uno no debe esperar un trabajo de alta calidad.
Fuente: estudio de Microsoft
Puede continuar esta partición aún más agregando al montón también el código sin propietario y la propiedad exclusiva, pero no quiero perder lo principal, así que aquí hay un gráfico que muestra el espectro de formas de propiedad del código:
La propiedad colectiva debe ser su opción predeterminada y la forma de propiedad por la que debe luchar. Tenga en cuenta que esto no significa que solo un desarrollador de su equipo tenga permiso para cambiar el código, o que cualquier modificación del código requiere su aprobación. Esto solo significa que está completamente claro para todos en el equipo con quienes debe discutir cualquier pregunta que tenga, y que el propietario del código probablemente se encargará de la revisión del código (revisión del código). Esto permitirá que todos en el equipo mejoren los estándares de escritura de códigos y se den cuenta de cómo se ha modificado su propio código.
El propietario es responsable del estado de su código, y los gerentes deben pedirle esto. Esto no significa que deba ser golpeado en la cabeza por cada error que se haya filtrado en su código; esto significa que los propietarios están autorizados a tomar decisiones sobre la calidad del código y la deuda técnica; serán responsables de estas decisiones con métricas de apoyo adicionales, como la cohesión y la actividad repetitiva (abandono) (para más detalles, vea nuestro artículo sobre métricas técnicas de deuda ).
La falta de propiedad, o la propiedad débil, es lo opuesto a la propiedad colectiva, y en la mayoría de los casos esta forma de propiedad debe evitarse. Como ya se mencionó (y esto puede sonar obvio) para archivos como package.json, no tener un propietario claramente definido es una situación normal. Ir al extremo no es necesario.
Código huérfano
El tipo de falta de propiedad más desagradable, uno de los bordes del espectro de formas de propiedad del código. Definitivamente no necesita esta forma de propiedad. Evítalo a toda costa ... a menos que sea, por supuesto, un código que nunca volverás a tocar. Pero ese código es muy raro.
El código se considera sin propietario si su desarrollador principal ha dejado de realizar cambios en la base del código. Tal vez dejó la organización, o tal vez pasó de desarrolladores a gerentes. En cualquier caso, tiene serios problemas, y también su base de código.
Sin embargo, hay una solución. Debe traducir el código fuente a cualquier otra forma de propiedad que sea más adecuada para él. Para evitar la aparición de cualquier código sin propietario en su base de código, asegúrese de que sus planes para el caso de desestimación o derivación de casos incluyan la introducción de nuevos propietarios del código en el curso de los asuntos de su antiguo propietario. Puede facilitarles la tarea al asignarles automáticamente para ver solicitudes de extracción de cambios de código. En ausencia de tal, simplemente puede designar a los propietarios del código como mejor le parezca.
Independientemente del método que elija, no deje el código sin propietario colgado en su base de código. Nunca se sabe lo que le sucederá si lo dejas a merced del destino.
Propiedad única (propiedad absoluta)
Este es el otro extremo del espectro de propiedad del código. Con él, todo puede ser maravilloso y muy difícil.
Se considera que el código es de propiedad exclusiva cuando el propietario es el único desarrollador que puede realizar o aprobar cambios en el código, o cuando el propietario es, en esencia, la única persona que ha realizado cambios en el código en el pasado.
Las nuevas empresas a menudo encuentran prácticas similares en su trabajo. Cada desarrollador, como regla, es responsable del historial completo de un solo archivo, y se espera que se conserve la propiedad de este archivo. Este no es el fin del mundo; las startups, después de todo, tienen recursos limitados, y debes hacer ciertos sacrificios. Pero si un día el desarrollador mueve el autobús, esta parte del código no tendrá propietario. Para tales situaciones, debe tener un plan de respaldo.
En organizaciones de ingeniería más grandes, un bajo " factor de bus " puede ser un problema real, especialmente cuando se trata de partes críticas de la base del código, la rotación del personal es alta y la deuda técnica contratada por la compañía es demasiado grande. Por ejemplo, si deja un desarrollador que ha estropeado todo su sistema de pago configurado manualmente, tendrá un gran dolor de cabeza, en caso de que quiera cambiar su modelo de precios, o si encuentra un error en su base de código que lo hace durante muchos meses recibieron menos dinero de sus mayores clientes. Entonces, o alguien tendrá que reunirse e intentar comprender el código para realizar cambios, o tendrá que declararse en quiebra técnica en su sistema de pago y volver a escribirlo desde cero (pero antes de hacerlo, lea esto ).
No dejes que esto te suceda.
Sin embargo, hay momentos en que la propiedad exclusiva del código es aceptable o incluso recomendable. Es posible que desee establecer esta forma de propiedad para aquellas partes de la base del código para las cuales la declaración "si esta parte se rompe, podemos retirarnos, porque entonces la empresa no podrá pagarnos salarios o iremos a la cárcel".
En tales casos, incluso si desea difundir el conocimiento sobre la parte crítica del código entre varios desarrolladores para mantener un factor de bus lo suficientemente alto, probablemente también desee establecer reglas que prohíban la inyección de solicitudes de extracción sin la aprobación del único propietario del código correspondiente.
Resumen
Esfuércese por la propiedad colectiva de la gran mayoría de los archivos en su base de código (50% –90% de la propiedad del código para cualquier archivo dado), y sea más disciplinado para aumentar la propiedad del código y reducir la deuda técnica cuando sea necesario.
Los beneficios son los siguientes:
- Normas de escritura de códigos más altas y mantenidas adecuadamente. En un grupo pequeño y bien informado, es más fácil cumplir con altos estándares. Esto se aplica no solo a los desarrolladores que modifican su propio código, sino también a las revisiones de código escritas por sus pares y que afectan las partes que poseen.
- Facilitar la comunicación. La propiedad explícita y clara significa que cada desarrollador del equipo sabe quién responderá mejor a su pregunta.
- Refactorización más focalizada y efectiva. Si decide pagar parte de la deuda técnica, los desarrolladores fuertes que poseen el código apropiado son los más adecuados para este trabajo. Utilice las métricas de propiedad, conectividad y actividad repetitiva para delinear áreas de preocupación en su base de código. Sus desarrolladores utilizarán su presupuesto para la deuda técnica con prudencia y nunca más perderán tiempo en pagar deudas técnicas que no valen la pena.
- El factor del autobús nunca se saldrá de control. Puede usar la propiedad del código para organizar el intercambio de conocimientos en su organización. Si el grado de propiedad es demasiado alto, asigne a otros desarrolladores que revisen el código y las tareas asociadas con su modificación. Mejorará gradualmente sus indicadores de propiedad, lo que conducirá a un aumento en la calidad del código y una disminución de la deuda técnica.
Como todo lo que realmente vale la pena, crear una cultura de ingeniería de propiedad del código (¡y seguirlo!) Toma tiempo y esfuerzo, pero valdrá la pena con intereses. Este factor afecta directamente a casi cualquier bienestar de ingeniería de KPI que pueda imaginar. Incruste en la cultura de su empresa y, a la larga, se convertirá en su gran ventaja competitiva.