¿Es importante la propiedad del código individual? [cerrado]

Creo que la propiedad del equipo es mucho más beneficiosa a largo plazo.

Solo necesita mirar los siguientes 2 escenarios para comprender por qué concentrar el conocimiento en un número mínimo de personas es menos que ideal:

• El miembro del equipo se encuentra con el desafortunado accidente
• El miembro del equipo se encuentra con una mejor oportunidad de empleo

Naturalmente, la persona o personas que escriben secciones particulares tendrán un mayor conocimiento de ello, pero no ceden a la tentación de convertirlos en el único silo de conocimiento. Silos te dará victorias a corto plazo por dolores a largo plazo.

El hecho de que no tengas propiedad individual de las secciones de código, ya que lo escribiste, no significa que no tengas los aspectos del "orgullo en tu creación", etc. No creo que tengas un equipo la propiedad disminuirá enormemente cualquier sentimiento personal de propiedad del código escrito.

En última instancia, el equipo posee el código. Pero por todas las razones que mencionó, hemos designado autores individuales para partes específicas del código. Cada autor tiene la responsabilidad principal por su parte del código, y la responsabilidad secundaria por el código base en su conjunto.

Si surge un problema con una parte de la base del código, intento volver a la persona que originalmente escribió el código para una solución. Por supuesto, no hay nada que impida que otros miembros del equipo apliquen una solución; se espera que todos los miembros del equipo estén familiarizados con el código de todos los demás. Pero siempre intentamos obtener una solución del autor original primero. Después de todo, escribieron el código; Ellos son los que más conocen.

He trabajado en entornos de equipo que, debido a que las personas no tenían una sensación de propiedad en lo que escribían, no estaban obligadas a escribir código excelente, sino simplemente código promedio.

Si bien estoy de acuerdo con una postura comercial sobre las razones para difundir el conocimiento sobre el producto; la realidad es que un individuo que enfoca sus esfuerzos en un área determinada de cualquier cosa, con el tiempo, se volverá mucho más versado en el área dada.

Ignorar esto es ignorar la ciencia. Desafortunadamente, el cerebro no puede retener todo lo que encuentra. Recuerda lo que es válido y valioso en un momento dado, pero incluso ese almacenamiento disminuye con el tiempo.

Yo tiendo a estar de acuerdo con usted en que la propiedad de un módulo o compartimiento específico dentro de la base de código más grande generalmente producirá mejores resultados. ¿Alguien que se vaya sin previo aviso obstaculizará el éxito? Ciertamente. Pero fingir que todos los miembros del equipo deben tener la misma cantidad de conocimiento con respecto al código base es ingenuo y no hace nada para mejorar el código; Intenta proteger el código. Proteger el código es el rol del negocio por razones obvias. La duración del esfuerzo que hará una empresa para proteger el código a menudo puede ser perjudicial de la misma manera.

Usted no se asegura de que todos los jugadores de su equipo puedan jugar como mariscal de campo, ¿verdad? Yo diría que asegurarse de que cada miembro del equipo tenga una participación en la base del código es lo mismo que intentar que todos los jugadores de su equipo jueguen como mariscales de campo a un nivel satisfactorio ... no se acumula. ¿Tienes copias de seguridad? Claro que sí ... pero los miembros del equipo deben tener una identidad dentro del equipo. Creer que todos somos iguales es pedir dolor de un tipo diferente ...

No sé si el código individual propiedad es una buena idea. Al menos no en el sentido de que la gente pueda decir "Este es mi código, y haré lo que quiera con él". Tal vez sea mejor decir que debe tener un código individual managership : el código debe ser propiedad del equipo, pero hay una persona en particular a quien el equipo delega responsabilidad y autoridad sobre él.

La razón de esto es que si es responsabilidad de todos, entonces no es responsabilidad de nadie.

Propongo la propiedad del equipo sobre la persona por las siguientes razones:

• Coherencia de código en todo el proyecto
• Promueve la discusión del código, lo que siempre conduce a soluciones mejores y más probadas
• Si un miembro del equipo está enfermo (o peor), una sección completa del código no está sujeta a demoras
• Los miembros del equipo pueden trabajar en todas las partes del proyecto, lo que sirve para hacer una revisión del código integrada en el proceso de desarrollo

La especialización está bien: para una base de código grande, a la larga esto puede ahorrar un poco de tiempo de comunicación, pero la propiedad no.

Lo que quiero decir es que la actitud debe ser que el equipo tiene un error, y nadie debería decir que "oh, solo X puede tocar ese código, así que no es mi problema". Si forma parte del equipo, también es su responsabilidad corregir los errores en todo el código base, si puede, y hacerlo correctamente. La Persona X puede ser la mejor opción para hacerlo, pero se debe esperar que cualquiera lo haga si tuviera que hacerlo. Esto, naturalmente, requiere que el código se escriba de manera que permita y invite a los miembros del equipo a trabajar con él. Tener un código genético lo prohibirá, por lo tanto, procure un código claro y simple, ya que eso permite que la mayoría de los desarrolladores trabajen con él. Es posible que desee ir con la revisión por pares para mantener de esa manera.

Tengo que estar en desacuerdo contigo: la propiedad del equipo de un código base es una opción mucho mejor que la propiedad individual.

El inconveniente obvio de la propiedad individual es que si algo le sucede a un empleado (que lo despidan, se jubilen, se enfermen, etc.), a menos que él / ella escribiera realmente el código limpio, tomará un tiempo para que otra persona adopte el código de esa persona, especialmente si también tiene que administrar su propio código.

También son demasiadas herramientas que facilitan la propiedad del equipo. Revisiones de código, control de fuente: estas son cosas que fomentan la participación del equipo en todo el código base. Además, ¿cómo asigna una parte particular de una base de código a una sola persona? ¿Acabas de decir que solo esta persona puede modificar este archivo?

Finalmente, creo que si una parte de una base de código se rompe, es demasiado fácil culpar a la persona responsable de ello, y eso solo causa más problemas.

Creo que necesitas ambos, porque hay una tensión entre ambos enfoques.

Si para cualquier parte del código solo hay una persona que puede trabajar en él, eso es muy malo a largo plazo para la empresa, especialmente a medida que crece, porque cada desarrollador se convierte en un punto de falla. Por otro lado, la propiedad individual del código (con suerte) permite un tiempo de entrega más rápido, porque el desarrollador generalmente prefiere ese enfoque (incentivo), porque el desarrollador conoce el código muy bien, etc ... También hay un problema de tiempo: debería ser posible para reasignar a los desarrolladores en proyectos específicos según las necesidades del negocio, pero si lo hace a diario, eso es horrible (aunque solo sea porque los desarrolladores lo odian, pero también porque el costo del cambio es demasiado elevado y usted pasa la mayor parte de su tiempo haciendo esto). nada).

OMI, un rol de un gerente es encontrar un buen equilibrio entre ambos. La revisión del código, los estándares de codificación, la estandarización en un conjunto de herramientas también deberían ayudar a disminuir el problema de falla. Después de todo, el punto principal del código que se puede mantener es abordar este problema.

Creo que la propiedad de código colectivo es incomparablemente mejor que la propiedad de código individual.

No me molesta tanto el argumento del camión: en un modelo de propiedad individual, la pérdida de un propietario es costosa en términos del tiempo necesario para que otra persona asuma el control, pero el evento es tan raro que el costo amortizado es bajo.

Más bien, creo que la propiedad colectiva de códigos conduce directamente a códigos de alta calidad. Esto es por dos razones muy simples. En primer lugar, porque la verdad dolorosa es que algunos de sus programadores no son tan buenos como los otros, y si poseen código, ese código será pobre; Darle acceso a tus mejores programadores lo mejorará. En segundo lugar, revisión del código: si todos son dueños del código, todos pueden revisarlo y mejorarlo; incluso los buenos programadores escriben código de subparado si lo dejan en sus propios dispositivos.

Digo esto basado en la experiencia en mi proyecto actual. Nuestro objetivo es practicar la propiedad colectiva, pero hay algunos fragmentos del sistema que se han especializado: otro individuo y yo somos propietarios de facto del sistema de compilación, por ejemplo, hay un tipo que está haciendo la mayor parte del trabajo en los feeds de datos entrantes. , otro chico trabajando en la importación de imágenes, y así sucesivamente. En varias de esas áreas (en particular, tengo que confesar, en mi área), la calidad del código ha sufrido seriamente: hay errores, conceptos erróneos, errores y trucos que simplemente no sobrevivirían a la atención de otras personas en el equipo.

Observo que puede obtener algunos de los beneficios de la propiedad de código colectivo si tiene la propiedad de código individual donde la propiedad de un bit de código en particular se mueve entre diferentes programadores regularmente (por ejemplo, cada tres meses o cada versión, tal vez incluso cada ¿iteración?). Una programación equivalente a la rotación de cultivos. Eso podría ser divertido. Sin embargo, no voy a intentarlo yo mismo.

No creo que la propiedad del código de equipo sea tan importante como tener múltiples contribuyentes que entiendan la arquitectura básica de los subsistemas prevalecientes.

Por ejemplo, tenemos un par de personas en nuestro equipo que hacen páginas web administrativas para nuestros productos de servidor. Construimos un motor de script del lado del servidor personalizado para poder llamar a funciones C en el servidor directamente desde nuestros scripts de java o html. Creo que es más importante que nuestros chicos "web" entiendan cómo usar este motor en lugar de ser copropietarios de las aplicaciones de páginas web de los demás.

Creo que tomas la propiedad individual del código en el momento en que lo escribes y luego lo entregas al equipo. De esta manera todos se responsabilizan y contribuyen. Todos deberían querer arreglar una falla de codificación que crearon. Junto con una revisión del código, esto crea estándares más altos. Nadie quiere el trabajo de limpiar después de otros.

Piensa más responsabilidad y menos propiedad. Después de todo, quienquiera que esté escribiendo los cheques es el verdadero dueño de todos modos.

Jim, estoy contigo en ese 100%. Estoy en medio de exactamente la misma batalla en mi lugar de trabajo, por lo que me topé con tu pregunta.

La forma en que lo veo es: "cuando todo el mundo lo posee, nadie lo posee".

Para mí, no existe un factor más importante para la calidad del código que la propiedad y la responsabilidad.

Ejemplo de la vida real ilustra esto bien. ¿Qué cuidaría mejor: su jardín privado o el parque de la comunidad? Bastante obvio.

Por cierto, eso no necesariamente tiene que cambiarse por "flexibilidad de equipo". Simplemente significa que cuando una persona posee algo, LO DEBE, y solo por el día.

Para mí, depende de la dinámica de tu equipo.

Por ejemplo, si tiene un equipo que no está unificado por estándares, revisión por pares, pruebas metódicas, o si tiene un equipo en el que los niveles de competencia varían enormemente entre los miembros, puede ser bueno buscar una idea más sólida. de propiedad de código con una mentalidad modular más de caja negra.

A falta de esto, por ejemplo, una interfaz cuidadosamente diseñada que se ajuste a los principios de SOLID puede ser arruinada rápidamente por alguien que ni siquiera sabe "SOLID" significa y desea agregar nuevas funciones eclécticas todo el tiempo a la interfaz para "conveniencia ", p.ej Esto es, de lejos, el peor.

También puede tratar con compañeros de trabajo descuidados cuya idea de corregir un error es corregir el síntoma sin comprender el problema de la raíz (por ejemplo, intentar responder a un informe de error simplemente colocando soluciones en el código solo para ocultar el error y transferir los efectos secundarios mortales a otra persona). En ese caso, no es tan malo como el sabotaje del diseño de la interfaz y puede proteger sus intenciones con pruebas de unidades cuidadosamente construidas.

La solución ideal es reforzar tu equipo, hasta un punto en el que esta noción de autoría y propiedad ya no sea tan importante. La revisión por pares no es solo mejorar la calidad del código, sino también mejorar el trabajo en equipo. Las normas no solo tienen que ver con la consistencia, sino que mejoran el trabajo en equipo.

Sin embargo, hay escenarios en los que la revisión por pares y el hecho de que todos se ajusten a un estándar es inútil y traerá un montón de críticos inexpertos en la mezcla. Diría que gran parte de si la propiedad del código o la propiedad del equipo tienen una mayor prioridad, se basará en la capacidad de su equipo para realizar realmente una revisión por pares y dejar a todos saliendo como ellos se beneficiaron (tanto en términos de la revisión en sí misma) , y acercarse más en mentalidad y estándares como resultado). En equipos grandes, sueltos y / o dispares, esto puede parecer desesperado. Si tu equipo puede funcionar como un "escuadrón" en el que apenas puedes decir quién escribió qué, entonces la propiedad exclusiva comenzará a parecer una idea estúpida.

En este tipo de escenarios lejos de lo ideal, esta noción de propiedad del código puede ayudar. Está tratando de resolver el peor de los casos, pero puede ayudar si el trabajo en equipo generalmente no tiene sentido para poner una cerca al código de un autor. En ese caso, está disminuyendo el trabajo en equipo, pero eso puede ser mejor si el "trabajo en equipo" solo conduce a un paso hacia abajo.