* Sistema de propietario de código *: ¿es una forma eficiente? [cerrado]

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

Depende

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

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

• El programador A: tiene un profundo entendimiento
• Programador B: ninguno

Digamos que el programador A obtiene 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, que comienza con 0.2 unidades de trabajo por día y termina con 0.96 unidades de trabajo en su día 20 (en el día 21 son tan buenos como el programador A), logrará 11.6 unidades de trabajo En el mismo periodo 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 además del primero.

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

Considere este escenario: mismos programadores, 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 de manera equitativa, 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 realizado en cada módulo. El total (A + B) es 6.4 unidades de trabajo por módulo. Esto se debe a que 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 enfoque 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, con un total de 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 en los mismos módulos que en 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 más alto que las 6.4 unidades por módulo que hicimos cuando A y B repartieron el trabajo de manera uniforme.

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

Entrenamiento

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

Solución óptima

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

• ¿Qué tan grande es tu equipo? ¿Tiene sentido que todos entrenemos en todas las partes, 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 su empleado? Si está entregando empleados a un promedio de cada 3 años, y le toma más tiempo conocer realmente cada rincón del sistema, entonces no estarán disponibles el tiempo suficiente para que la capacitación se rinda a sí misma.
• ¿Realmente necesita un experto para diagnosticar un problema? Mucha gente usa la excusa "qué pasa si esa persona se va de vacaciones", pero me han llamado muchas veces para diagnosticar un problema en un sistema con el que no tengo experiencia. Puede ser cierto que la persona experimentada podría encontrarlo mucho más rápido, pero eso no significa que no pueda vivir sin ellos durante una o dos semanas. Pocos sistemas de software son tan críticos para la misión que el problema debe diagnosticarse 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 justo en el medio (10 cada uno), porque entonces no tiene flexibilidad, pero tampoco desea entrenar a los 10 programadores en los 50 módulos porque pierde mucho eficiencia y no necesitas tanta redundancia.

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

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 el intercambio de trabajo y el trabajo en conjunto, no se debe desalentar.     

Depende de cuál sea el dominio del problema.

Si son cosas generales (es decir, acciones de CRUD simples, etc.), entonces estoy de acuerdo con Tom Squires (cualquiera debería poder trabajar 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 mucha investigación antes de la implementación, ya que esto es algo que se incluiría en un requisito de trabajo como conocimiento especializado que no todas las personas en el proyecto tienen, entonces un propietario debe definitivamente ser asignado a esa parte del código. Dicho esto, cualquier persona debería ser capaz de realizar modificaciones según sea necesario, pero siempre debe ser revisada por la persona que posee esa área del proyecto.

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

Esta es una idea horrible . He trabajado en una empresa que ha utilizado este enfoque y es prácticamente una receta para un montón de deuda técnica . 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 todos los errores que cometas. Es por eso que necesita un equipo: más ojos que miran 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 resiente. Todos sabemos que "más tarde" nunca llega. Hecho : es más difícil tomar atajos cuando eres responsable de inmediato ante tus compañeros en un equipo. ¿Por qué? Debido a que 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 mantenible 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 jubilarse, y todavía hay alguien que conoce el código (y puede capacitar a la segunda persona). No todos necesitan aprender todo, lo cual es un poco más eficiente.

No tienen las mismas 2 (o 3) personas trabajando juntas todo el tiempo. Cambie los pares para diferentes áreas, por lo que el conocimiento también se comparte inadvertidamente cuando se trabaja con una persona diferente en un área del programa relacionada.

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

¿Qué sucede cuando está de vacaciones, o se enferma inesperadamente, o se va, o es golpeado por el autobús proverbial? ¿Qué sucede cuando desea modificar los recursos para obtener un trabajo 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 el código base, saber si el desarrollador está trabajando duro o sacando la lana sobre sus ojos? ¿Quién notará si la deuda técnica comienza a acumularse?

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

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

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

• expertise : 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 los detalles importantes de la implementación, están en manos de un miembro del equipo en particular o solo de unos pocos miembros del equipo.
• egoless code : 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 al adherirse estrictamente a un estilo de codificación bien conocido o una especificación bien mantenida, cualquier nuevo miembro del equipo tiene la misma oportunidad de entender los recursos y por qué del proyecto como los desarrolladores con experiencia.

Cuando el tema es puramente uno 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 sobre ese dominio. Los expertos, aunque quizás sean raros y valiosos, son esencialmente intercambiables; un contador fiscal experimentado es tan útil para un proyecto de software de planificación fiscal como otro, desde el punto de vista de su conocimiento del dominio. El problema se convierte en uno de los aspectos en que la experta puede transferir sus conocimientos al proyecto.

Cuando el tema es puramente de liderazgo, el éxito del proyecto depende principalmente de la consistencia y la percepció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 comprobados como líderes de proyectos, esto a veces es secundario a la función. El "líder" podría cambiar de un día a otro si las decisiones tomadas son coherentes de un caso a otro y cada decisión es ejecutada rápidamente por el equipo. Si esto está funcionando bien; el líder del proyecto no tiene que "tomar" muchas decisiones porque el equipo ya entiende qué decisiones se tomarán.

No creo que la pregunta fuera realmente acerca del 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 dejarlo de inmediato. ¿Qué pasaría si el equipo entero tuviera que ser reemplazado? Si el proyecto se pone en duda porque depende de algunos jugadores clave, 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 podría no estar trabajando tan eficientemente como lo haría si hubiera más desarrolladores interesados.

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

Recomiendo consultar con los autores de los códigos antes de cambiarlos, aunque el código de alto estándar debe estar lo suficientemente documentado, probado en la unidad, probado en la integración y probado en el sistema para hacer que esto sea 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 por 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 error grande en sus cosas, será muy difícil y lento tratar de aprender el código Y solucionar el error
• Si el propietario del código abandona la empresa, sus proyectos se verán seriamente retrasados ya que toda la herencia y el conocimiento tribal acaban de salir
• La documentación es deficiente. Si soy la única persona que lo codifique, ¿por qué lo documentaría? El problema está relacionado con el hecho de que cualquier documentación que se obligue a ser creada también será deficiente porque nadie sabrá lo suficiente sobre el código para decir realmente si la documentación está completa o incluso es precisa.
• Las guerras santas de código pueden encenderse fácilmente cuando todos tienen su propia pequeña 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 los demás.
• Los feudos pueden formarse fácilmente, pequeños reinos hechos de bolsas de desechos que no le compran nada a la compañía. No sabes que esto suceda hasta que sea demasiado tarde porque el módulo o la herramienta X es responsabilidad de Bob, y, ¡ay de ti, quién debería siquiera preguntar qué está haciendo Bob con su código his !
• Las revisiones de código y las 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 está limitado a comentar sobre el formato de texto y las convenciones de nomenclatura solo.
• 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 una cuestión de grupo, como cuando tu equipo gana una partida 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 la manera que más le convenga para hacer su trabajo, que es enviar 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 empujando el horario a la izquierda durante unas semanas.

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

• Solucione cualquier defecto en esa área
• Agregar nuevas funciones 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 en los que este fue el caso y funcionó muy bien. No solo no había ninguno de los contras enumerados anteriormente, el personal era mucho más predecible ya que no estábamos buscando expertos.

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

Consulte Número de camión también conocido como Factor de bus

  

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 cada equipo. miembros. El factor de bus es el número total de desarrolladores clave que necesitarían estar incapacitados (como si un bus o camión lo chocara) para enviar el proyecto a tal desorden que no podría continuar; el proyecto retendría información (como código fuente ) con la que ningún miembro del equipo restante está familiarizado. Un factor de bus alto significa que muchos desarrolladores deberían eliminarse antes de que el proyecto fracasara necesariamente.

     

"Ser golpeado por un autobús" podría tomar muchas formas diferentes. Esto podría ser una persona que toma un nuevo trabajo, tiene un bebé, cambia su estilo de vida o su estado de vida, o literalmente es golpeada 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", es probable que esté casi en mal estado. Si es "el propietario debe hacer una revisión del código antes de aceptar un cambio", está a medio camino, dependiendo de lo dispuesto que esté el propietario a aceptar un cambio externo.

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

Para revisar, el "número de camión" se define simplemente como "la cantidad de miembros del equipo, en el peor de los casos, que podría ser golpeado por un camión antes de que el equipo pierda el conocimiento necesario para realizar alguna tarea crítica". p>

Es natural, y de alguna manera se recomienda, que los desarrolladores se centren en las subdisciplinas; Si todos tuvieran que saber todo lo que tenía que ver con el proyecto, no se haría nada porque todos aprenderían lo que todos los demás habían hecho, por qué funciona y cómo se puede cambiar sin romperlo. Además, si los desarrolladores no están haciendo cosas diferentes en áreas diferentes, es menos probable que los cambios se colenen. Por lo general, 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 solo se supone que una persona toque una línea de código en particular, cuando esa persona renuncia, se despide, se va de vacaciones o termina en el hospital, y esa línea de código se demuestra como la causa de un error que debe solucionarse, alguien más tiene que entrar y entender el código. Si nadie más que el que lo escribió lo ha visto, tomará tiempo para llegar a un nivel de comprensión que le permita al desarrollador hacer el cambio que corrige el error sin hacer más. TDD puede ayudar, pero solo al decirle al desarrollador que hizo el cambio "incorrecto"; de nuevo, el desarrollador debe comprender qué pruebas están ejerciendo qué código para asegurarse de que las pruebas que fallan no estén intentando hacer las 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 su desorden a otra persona para limpiar. Esto también se aplica a los cambios.

Los problemas de carga de trabajo y de programación sobrescribirán esto. Sería una tontería evitar reparar un error importante porque el culpable está en unas vacaciones de dos semanas.

El objetivo no es que tu equipo juegue "el juego de la culpa" o que lleve la cantidad de errores demasiado lejos (no todos son iguales de todos modos). Haga una base sobre quién verificó el código por última vez o haga que un supervisor tome la decisión y asignarlo a alguien en lugar de revisar cada parte de cada línea de código.

Los mejores programadores probablemente terminen corrigiendo el código de muchas otras personas sin importar cómo lo asignes.