* Propietario del código * sistema: ¿es una forma eficiente? [cerrado]

Hay un nuevo desarrollador en nuestro equipo. Una metodología ágil está en uso en nuestra empresa. Pero el desarrollador tiene otra experiencia: considera que partes particulares del código deben asignarse a desarrolladores particulares. Por lo tanto, si un desarrollador hubiera creado un procedimiento o módulo de programa, se consideraría normal que todos los cambios del procedimiento / módulo fueran realizados solo por él.

En el lado positivo, supuestamente con el enfoque propuesto, ahorramos tiempo de desarrollo común, porque cada desarrollador conoce bien su parte del código y hace las correcciones rápidamente. La desventaja es que los desarrolladores no conocen el sistema por completo.

¿Crees que el enfoque funcionará bien para un sistema de tamaño mediano (desarrollo de un sitio de red social)?

Como muchas de estas preguntas, creo que la respuesta es:

Depende

Hay razones para creer que tomar la posición de que cada programador debe saber cada línea de código está equivocado.

Si suponemos por un momento que alguien con un profundo conocimiento de un fragmento de código hará cambios 5 veces más rápido que alguien que no lo sabe en absoluto (no es un gran salto de fe en mi experiencia) y lleva aproximadamente un mes de la experiencia de codificación para obtener una comprensión realmente buena de un módulo de tamaño significativo (tampoco irrazonable), entonces podemos ejecutar algunos números (completamente falsos y ficticios):

• Programador A: tiene un profundo conocimiento
• Programador B: ninguno

Digamos que el programador A realiza 1 unidad de trabajo por día. En 4 semanas de 5 días hábiles, puede realizar 20 unidades de trabajo.

Entonces el programador B, comenzando con 0.2 unidades de trabajo por día, y terminando con 0.96 unidades de trabajo en su vigésimo día (el día 21 son tan buenos como el programador A), logrará 11.6 unidades de trabajo en el mismo Período de 20 días. Durante ese mes, el programador B logró un 58% de eficiencia en comparación con el programador A. Sin embargo, ahora tiene otro programador que conoce ese módulo tan bien como el primero.

Por supuesto, en un proyecto de tamaño decente, podría tener ... ¿50 módulos? Por lo tanto, familiarizarse con todos ellos lleva unos 4 años, y eso significa que el programador de aprendizaje está trabajando, en promedio, con un 58% de eficiencia en comparación con el programador A ...

Considere este escenario: los mismos programadores, el mismo proyecto (A lo sabe todo y B no sabe nada de eso). Digamos que hay 250 días hábiles en el año. Supongamos que la carga de trabajo se distribuye aleatoriamente en los 50 módulos. Si dividimos a ambos programadores en partes iguales, A y B obtienen 5 días hábiles en cada módulo. A puede hacer 5 unidades de trabajo en cada módulo, pero B solo obtiene, según mi pequeña simulación de Excel, 1,4 unidades de trabajo realizadas en cada módulo. El total (A + B) es de 6.4 unidades de trabajo por módulo. Eso es porque B pasa la mayor parte de su tiempo sin ninguna habilidad con el módulo en el que están trabajando.

En esta situación, es más óptimo que B se centre en un subconjunto más pequeño de módulos. Si B se enfoca en solo 25 módulos, obtienen 10 días en cada uno, totalizando 3.8 unidades de trabajo en cada uno. El programador A podría pasar 7 días cada uno en los 25 módulos en los que B no está trabajando, y 3 días trabajando en los mismos módulos que B. La productividad total varía de 6.8 a 7 unidades por módulo, con un promedio de 6.9, y eso es significativamente mayor que las 6.4 unidades por módulo que hicimos cuando A y B distribuyeron el trabajo de manera uniforme.

A medida que reducimos el alcance de los módulos en los que B trabaja, obtenemos aún más eficiencia (hasta cierto punto).

Formación

También argumentaría que alguien que no sabe tanto sobre un módulo interrumpirá a la persona que hace mucho más que alguien con más experiencia. Por lo tanto, estos números anteriores no tienen en cuenta que cuanto más tiempo pasa B en código que no entienden, más tiempo de A dedican a hacer preguntas y, a veces, A tiene que ayudar a solucionar o solucionar lo que B hizo. Entrenar a alguien es una actividad que requiere mucho tiempo.

Solucion optima

Por eso creo que la solución óptima debe basarse en preguntas como:

• ¿Qué tan grande es tu equipo? ¿Tiene sentido que todos tengan entrenamiento cruzado en cada parte, o si tenemos un equipo de 10 personas, podemos asegurarnos de que cada módulo sea conocido por al menos 3 personas? (Con 10 programadores y 50 módulos, cada programador debe conocer 15 módulos para obtener una cobertura 3x).
• ¿Cómo es la rotación de sus empleados? Si está entregando empleados en un promedio de cada 3 años, y se tarda más que eso en conocer realmente cada rincón del sistema, entonces no estarán disponibles el tiempo suficiente para que la capacitación se amortice.
• ¿Realmente necesitas un experto para diagnosticar un problema? Mucha gente usa la excusa, "¿y si esa persona se va de vacaciones?", Pero me han llamado varias veces para diagnosticar un problema en un sistema con el que no tengo experiencia. Puede ser cierto que la persona experimentada pueda encontrarlo mucho más rápido, pero eso no significa que no pueda vivir sin ellos durante una semana o dos. Pocos sistemas de software son tan importantes para la misión que el problema tiene que ser diagnosticado en 1 hora en lugar de 5 horas o el mundo terminará. Tienes que sopesar estos riesgos.

Por eso creo que "depende". No desea dividir 20 módulos entre dos programadores en el medio (10 cada uno), porque entonces no tiene flexibilidad, pero tampoco desea entrenar a 10 programadores en los 50 módulos porque pierde mucho eficiencia y no necesita tanta redundancia.

Es una idea horrible . Puede ser más rápido a corto plazo, pero fomenta el código mal documentado y difícil de entender, ya que solo el codificador que lo escribió es responsable de mantenerlo. Cuando alguien deja la empresa o se va de vacaciones, todo el plan se arruina. También hace que sea muy difícil asignar cargas de trabajo; ¿Qué sucede cuando dos errores urgentes aparecen con el código que "posee" el codificador?

Debes codificar como un equipo . Naturalmente, a las personas se les asignarán tareas y se centrarán en ciertas áreas, pero se debe alentar, no desalentar, compartir la carga de trabajo y trabajar juntos.

Depende de cuál sea el dominio del problema.

Si se trata de cosas generales (es decir, acciones CRUD simples, etc.), entonces estoy de acuerdo con Tom Squires (cualquiera debería poder trabajar en ello y editarlo).

Sin embargo ...

Si la solución en cuestión requiere experiencia en el dominio (se ha invertido mucho tiempo en el pasado o se debe hacer una gran cantidad de investigación antes de la implementación, ya que esto es algo que enumeraría en un requisito de trabajo como conocimiento especializado que no todos en el proyecto lo tienen), entonces un propietario definitivamente debe ser asignado a esa parte del código. Dicho esto, cualquiera debería poder modificarlo según sea necesario, pero siempre debe ser revisado por la persona propietaria de esa área del proyecto.

No desea que todo su equipo (o varias personas del equipo) investiguen y aprendan el mismo tema (ciclos desperdiciados). Asigne un propietario, pero pídales que documenten sus aprendizajes y diseños, y quizás haga que realicen sesiones de capacitación informales (o formales, en realidad no importa) sobre la tecnología.

Esta es una idea horrible . He trabajado en una empresa que ha utilizado este enfoque y es más o menos una receta para un montón de deudas técnicas . La conclusión es que dos cabezas son casi siempre mejores que una. ¿Por qué? Porque a menos que seas un idiota, sabes que no eres un programador perfecto y no vas a atrapar cada error que cometas. Es por eso que necesita un equipo: más ojos mirando el mismo código desde diferentes perspectivas.

Se reduce a una cosa: disciplina . ¿Cuántos programadores solitarios conoces que son verdaderamente disciplinados en su estilo de codificación? Cuando no codifica con disciplina, toma atajos (porque lo "arreglará más tarde") y la capacidad de mantenimiento del código se ve afectada. Todos sabemos que "después" nunca llega. Realidad : es más difícil tomar atajos cuando eres inmediatamente responsable ante tus compañeros en un equipo. ¿Por qué? Porque sus decisiones serán cuestionadas y siempre es más difícil justificar los atajos. ¿Resultado final? Produce un código mejor y más fácil de mantener que también es más robusto.

La ventaja es que no todos necesitan investigar y comprender todo. La desventaja es que eso hace que cada persona sea necesaria para su propia área de código, y nadie más sabe cómo mantenerla.

Un compromiso sería tener al menos 2 propietarios para cada área de código. Entonces alguien puede irse de vacaciones, tomar un nuevo trabajo o retirarse, y todavía hay alguien que conoce el código (y puede capacitar a la nueva segunda persona). No todos necesitan aprender todo, lo cual es un poco más eficiente.

No haga que las mismas 2 (o 3) personas trabajen juntas todo el tiempo. Cambie los pares para diferentes áreas, de modo que el conocimiento también se comparta inadvertidamente cuando trabaje con una persona diferente en un área de programa relacionada.

Sí, es un poco más eficiente, a corto plazo. Y ahí termina los beneficios. Eso ni siquiera se acerca a superar el costo.

¿Qué sucede cuando está de vacaciones, o inesperadamente enfermo, o se va, o es atropellado por el autobús proverbial? ¿Qué sucede cuando desea flexibilizar recursos para lograr que un trabajo sea más rápido que otro? ¿Qué tan efectivas pueden ser las revisiones de código? ¿Cómo puede un gerente, particularmente uno que no está en la base de código, saber si el desarrollador está trabajando duro o tirando la lana sobre sus ojos? ¿Quién se dará cuenta si la deuda técnica comienza a aumentar?

En mi experiencia, las personas que les gusta trabajar de esta manera son cazadores de gloria en el mejor de los casos, flojos en el peor. Les gusta ser la única persona a la que puede acudir con un problema determinado y les gusta que su código permanezca privado. Y a menudo les gusta codificar rápido, sin tener en cuenta la legibilidad.

Eso no quiere decir que, en un equipo de 50 desarrolladores, todos deberían conocer todo el código, pero un equipo de 5-7 debería tener un módulo lo suficientemente grande como para mantener a esas personas trabajando. Ningún individuo debe poseer nada.

Hay al menos tres cuestiones que señalan las otras respuestas; pero me gustaría intentar tratarlos a los dos juntos. Los dos problemas son:

• experiencia : alguien en el equipo tiene conocimiento detallado sobre un campo en particular; este conocimiento es independiente de la implementación específica de ese dominio en el proyecto
• liderazgo : aunque el trabajo de construcción del proyecto puede compartirse entre muchos desarrolladores; la hoja de ruta, así como las decisiones inmediatas sobre detalles importantes de implementación están en manos de un miembro del equipo en particular o solo de unos pocos miembros del equipo.
• código sin ego : la forma particular en que se implementa el proyecto no depende de los estilos de codificación, las prácticas o el conocimiento de ningún desarrollador en particular del equipo; y mediante el estricto cumplimiento de un estilo de codificación bien conocido o una especificación bien mantenida, cualquier nuevo miembro del equipo tiene la misma oportunidad de comprender los cómo y los porqués del proyecto que los desarrolladores experimentados.

Cuando el tema es puramente de experiencia, el éxito del proyecto puede depender de un alto nivel de conocimiento sobre el dominio; pero no depende del conocimiento de un experto específico de ese dominio. Los expertos, aunque quizás raros y valiosos, siguen siendo esencialmente intercambiables; un contador de impuestos experimentado es tan útil para un proyecto de software de planificación fiscal como otro, desde el punto de vista de su conocimiento de dominio. El problema se convierte en uno de cuán bien la experta puede transferir su conocimiento al proyecto.

Cuando el tema es puramente de liderazgo, el éxito del proyecto depende principalmente de la consistencia y la comprensión de las decisiones tomadas por el líder del proyecto; Aunque tendemos a favorecer a los líderes de proyectos que tienen experiencia en el dominio, o que están probados como líderes de proyectos, esto a veces es secundario al rol. El "líder" podría cambiar día a día si las decisiones tomadas son consistentes de un caso a otro y el equipo ejecuta rápidamente cada decisión. Si esto está funcionando bien; muchas decisiones no tienen que ser "tomadas" por el líder del proyecto porque el equipo ya comprende qué decisiones se tomarán.

No creo que la pregunta fuera realmente sobre el código sin ego, pero es difícil hablar sobre la propiedad del código sin discutir también lo importante que es este problema. Mantener un proyecto es probablemente la mayor parte del ciclo de desarrollo. La forma de entender este problema es preguntarse qué pasaría si algunos de los desarrolladores tuvieran que abandonarlo de inmediato. ¿Qué pasaría si todo el equipo tuviera que ser reemplazado? Si el proyecto está en duda porque depende de algunos jugadores clave, entonces corre un alto riesgo de fracaso. Incluso si nunca pierde a un solo miembro del equipo, el simple hecho de que se necesitan uno o unos pocos desarrolladores para avanzar en el proyecto significa que es posible que no esté trabajando tan eficientemente como lo haría si se informara a más desarrolladores.

La propiedad del código tiende a evitar la refactorización, crear cuellos de botella en el desarrollo y causar problemas de ego cuando el código tiene problemas que deben abordarse.

Recomiendo consultar con los autores del código antes de cambiar, aunque el código de alto estándar debe estar suficientemente documentado, probado en la unidad, probado en la integración y probado en el sistema para hacer esto redundante, aún así no puede hacer daño obtener otra opinión.

Esto es malo por muchas razones, trabajé en una tienda donde intentaron cambiar esto a algo más razonable y fue feo.

Las razones por las que esto es malo:

• Si el propietario del código se toma unas vacaciones y aparece un gran error en sus cosas, será muy difícil y llevará mucho tiempo tratar de aprender el código Y corregir el error
• Si el propietario del código deja la empresa, sus proyectos se verán seriamente retrasados ​​ya que todo el patrimonio y el conocimiento tribal acaba de salir por la puerta
• La documentación es pobre. Si soy la única persona que lo codifica, ¿por qué lo documentaría? Relacionado está el problema de que cualquier documentación que sea forzada a crearse probablemente también sea deficiente porque nadie sabrá lo suficiente sobre el código para decir realmente si la documentación está completa o es precisa.
• Las guerras sagradas de códigos pueden encenderse fácilmente cuando todos tienen su propia caja de arena, ya que otros han mencionado que esto puede volverse realmente estúpido muy rápido. Donde esto es un problema es cuando dos personas tienen que trabajar juntas, ninguna de las dos está acostumbrada a comprometerse en nada.
• Debido al punto anterior, las habilidades de trabajo en equipo nunca se forman, las personas nunca tienen que trabajar con otros.
• Los feudos pueden formarse fácilmente, pequeños reinos hechos de bolsas de basura que no compran nada a la compañía. No sabe que esto sucederá hasta que sea demasiado tarde porque el módulo o la herramienta X es responsabilidad de Bob, y ¡ay de usted, que incluso debería preguntar qué hace Bob en su código!
• Las revisiones de código y las revisiones de pares sufren porque nadie sabe nada sobre el código. Si no conoce el código, no puede detectar los lugares que no son correctos y se limitan a comentar solo sobre formato de texto y convenciones de nomenclatura.
• Y si trabajas para mí ... la compañía posee el código, no tú. Nos enorgullece lo que hacemos y lo que logramos, y lo que escribimos, pero es algo grupal, como cuando su equipo gana un partido difícil. Cualquier empleado que trabaje para la compañía posee el código por igual, y en el curso de su trabajo se le permite editarlo de cualquier manera que desee para hacer su trabajo, que es reenviar los objetivos de la compañía.

Los más importantes son los problemas de personal y la documentación. Esa persona se irá algún día, y va a estar presionando el horario a la izquierda durante algunas semanas.

El mejor enfoque es que todos estén familiarizados con cada parte de la base del código (o media docena de partes, si es realmente grande y diversa) hasta el punto de que puedan

• Repare cualquier defecto en esa área
• Agregue nuevas características o mejoras menores o moderadas

Cada persona tiende a saber un poco más sobre algunas cosas que otras, por lo que para los problemas difíciles dos o tres pueden unirse, o el experto de facto puede asumirlo. He trabajado en grupos donde este fue el caso y funcionó muy bien. No solo no había ninguno de los inconvenientes mencionados anteriormente, la dotación de personal era mucho más predecible ya que no estábamos buscando expertos.

La propiedad del código pro a único es que el "propietario del código" probablemente puede hacer las cosas más rápido que otros, pero esto solo es cierto si todos son "propietarios del código" en proyectos que no se superponen. En otras palabras, si las personas rotan, la ventaja del "propietario del código único" desaparece.

Ver número de camión, también conocido como factor de autobús

El factor de bus (también conocido como factor de camión , o número de bus / camión ) es una medida de la concentración de información en los miembros individuales del equipo. El factor del bus es el número total de desarrolladores clave que tendrían que estar incapacitados (como ser atropellados por un bus / camión) para enviar el proyecto a tal desorden que no podría continuar; el proyecto retendría información (como el código fuente ) con la que ningún miembro restante del equipo está familiarizado. Un factor de bus alto significa que muchos desarrolladores necesitarían ser eliminados antes de que el proyecto fracasara necesariamente.

"Ser atropellado por un autobús" podría tomar muchas formas diferentes. Esta podría ser una persona que toma un nuevo trabajo, tiene un bebé, cambia su estilo de vida o estado de vida, o literalmente es atropellado por un autobús: el efecto sería el mismo ...

Como con muchas cosas, es un gran "depende". Si se trata de un estricto "nadie más puede trabajar en el código", probablemente esté llegando a ser malo. Si es "el propietario debe hacer una revisión del código antes de aceptar un cambio", es medio bueno, dependiendo de qué tan dispuesto esté el propietario a aceptar un cambio externo.

La desventaja es severa; el "número de camión" de su equipo se convierte en 1

Para revisar, el "número de camión" se define simplemente como "cuántos miembros del equipo, en el peor de los casos, podrían ser golpeados por un camión antes de que el equipo pierda los conocimientos necesarios para realizar alguna tarea crítica".

Es natural, y algo alentador, que los desarrolladores se centren en subdisciplinas; Si todos tuvieran que saber todo lo que tiene que ver con el proyecto, no se haría nada porque todos estarían aprendiendo lo que todos los demás hicieron, por qué funciona y cómo se puede cambiar sin romperlo. Además, si los desarrolladores están haciendo cosas diferentes en diferentes áreas, es menos probable que los cambios choquen. Por lo tanto, generalmente es bueno tener dos o tres desarrolladores o pares de desarrolladores que trabajen principalmente en un subsistema particular del proyecto y lo conozcan bien.

Sin embargo, si se supone que solo una persona toca una línea de código en particular, entonces cuando ese tipo renuncia, es despedido, se va de vacaciones o termina en el hospital, y esa línea de código se demuestra como la causa de un error eso debe ser arreglado, alguien más tiene que entrar y entender el código. Si nadie más que el tipo que lo escribió lo ha visto, tomará tiempo para llegar a un nivel de comprensión que permita al desarrollador hacer el cambio que corrige el error sin hacer más. TDD puede ayudar, pero solo diciéndole al desarrollador que hizo el cambio "incorrecto"; Una vez más, el desarrollador debe comprender qué pruebas están ejerciendo qué código para asegurarse de que las pruebas fallidas no intenten hacer afirmaciones incorrectas.

No lo llevo al extremo, pero prefiero la responsabilidad del código . Escribes código roto, deberías arreglarlo. Esto se puede hacer a nivel individual, de pareja o de equipo. Evita pasar el desorden a otra persona para que lo limpie. Esto también se aplica a los cambios.

La carga de trabajo y los problemas de programación sobrescribirán esto. Sería una tontería retrasar la reparación de un error importante porque el culpable está de vacaciones por dos semanas.

El objetivo no es que su equipo juegue "el juego de la culpa" o que lleve los recuentos de errores demasiado lejos (de todos modos, no son todos iguales). Base la información en quién verificó el código en último lugar o haga que un supervisor tome la decisión y se la asigne a alguien en lugar de pasar por cada parte de cada línea de código.

Los mejores programadores probablemente terminen arreglando muchos códigos de otras personas sin importar cómo lo asignen.