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

Estoy en medio de una discusión con algunos compañeros de trabajo sobre si la propiedad del equipo de toda la base de código es mejor que la propiedad individual de los componentes de la misma.

Soy un gran defensor de asignar a cada miembro del equipo una parte aproximadamente igual de la base de código. Permite que las personas se enorgullezcan de su creación, les da a los detectores de errores un primer lugar obvio para asignar boletos entrantes y ayuda a aliviar el "síndrome de la ventana rota".

También concentra el conocimiento de la funcionalidad específica con uno (o dos) miembros del equipo, lo que facilita mucho la corrección de errores.

Sobre todo, pone la última palabra en las decisiones importantes con una persona que tiene mucho aporte en lugar de un comité.

No estoy abogando por requerir permiso si alguien más quiere cambiar su código; tal vez la revisión del código sea siempre para el propietario, claro. Tampoco sugiero construir silos de conocimiento: no debería haber nada exclusivo sobre esta propiedad.

Pero al sugerir esto a mis compañeros de trabajo, recibí una tonelada de retroceso, ciertamente mucho más de lo que esperaba.

Entonces le pregunto a la comunidad: ¿cuáles son sus opiniones sobre trabajar con un equipo en una gran base de código? ¿Hay algo que me falta sobre el mantenimiento vigilante de la propiedad colectiva?

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

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

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

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

El hecho de que no tenga la propiedad individual de las secciones de código, ya que lo escribió, no significa que todavía no tendrá los aspectos de "orgullo en su creación", etc. No creo que tener la propiedad del equipo sea muy importante disminuir cualquier sentimiento personal de propiedad del código escrito.

Finalmente, 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 de su parte del código y la responsabilidad secundaria de la base del código en su conjunto.

Si surge un problema con una parte de la base del código, trato de volver a la persona que originalmente escribió el código para una solución. Por supuesto, no hay nada que impida a otros miembros del equipo aplicar 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 tratamos de obtener una solución del autor original primero. Después de todo, escribieron el código; ellos son los que más lo conocen.

He trabajado en entornos de equipo que, debido a que las personas no tenían un sentido de propiedad de lo que escribieron, no se vieron obligadas a escribir un código excelente, sino simplemente un 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.

Tendería a estar de acuerdo con usted en que la propiedad de un módulo o compartimento específico dentro de la base de código más grande generalmente producirá mejores resultados. ¿Alguien que se va sin previo aviso obstaculizaría el éxito? Ciertamente. Pero fingir que todos los miembros del equipo deben tener la misma cantidad de conocimiento con respecto a la base del código es ingenuo y no hace nada para mejorar el código; Intenta proteger el código. Proteger el código es el papel de la empresa por razones obvias. Los esfuerzos que hará un negocio para proteger el código a menudo pueden ser perjudiciales de todos modos.

No te aseguras de que todos los jugadores de tu equipo puedan jugar quarterback, ¿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 tratar de hacer que cada jugador dentro de su equipo juegue al quarterback a un nivel satisfactorio ... no cuadra. ¿Tienes copias de seguridad? Claro que sí ... pero los miembros del equipo deben tener una identidad dentro del equipo. Creer que todos son iguales es pedir un dolor diferente ...

No sé si la propiedad de código individual 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 una gestión de código individual : el código debe ser propiedad del equipo, pero hay una persona en particular a la que el equipo delega responsabilidad y autoridad sobre el mismo.

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

Yo desposaría la propiedad del equipo sobre el individuo por las siguientes razones:

• Consistencia del código en todo el proyecto.
• Promueve la discusión del código, que siempre conduce a soluciones mejores y más verificadas.
• 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 realizar 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 bastante tiempo de comunicación, pero la propiedad no lo es.

Lo que quiero decir es que la actitud debería 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 es parte del equipo, también es su responsabilidad corregir errores en toda la base de código, 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. Naturalmente, esto requiere que el código se escriba de una manera que permita e invite a los miembros del equipo a trabajar con él. Tener un código retorcido lo prohibirá, por lo tanto, busque un código claro y simple, ya que eso permite a la mayoría de los desarrolladores trabajar con él. Es posible que desee ir con una revisión por pares para mantenerlo así.

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

La desventaja obvia de la propiedad individual es que si algo le sucede a un empleado (ser despedido, jubilarse, enfermarse, etc.), a menos que él / ella haya escrito un código realmente limpio, tomará un tiempo para que otra persona adopte el nombre de esa persona. código, especialmente si también tienen 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 toda la base de código. Además, ¿cómo se asigna una parte particular de una base de código a una sola persona? ¿Simplemente dice 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 eso, y eso solo causa más problemas.

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

Si para cualquier pieza de código solo hay una persona que puede trabajar en él, eso es realmente 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 del código individual (con suerte) permite un tiempo de entrega más rápido, porque el desarrollador generalmente prefiere ese enfoque (incentivo), porque el desarrollador conoce muy bien el código, etc. También hay un problema de tiempo: debería ser posible reasignar a los desarrolladores en proyectos específicos dependiendo de las necesidades del negocio, pero si lo haces a diario, es horrible (aunque solo sea porque los desarrolladores lo odian, pero también porque el costo del cambio es demasiado alto y pasas la mayor parte del tiempo haciendo nada).

En mi opinión, una función de un gerente es encontrar un buen equilibrio entre ambos. La revisión del código, los estándares de codificación y la estandarización de 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 mantenible es abordar este problema.

Creo que la propiedad del código colectivo es incomparablemente mejor que la propiedad del 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 se haga cargo, pero el evento es lo suficientemente raro como para que el costo amortizado sea bajo.

Más bien, creo que la propiedad colectiva del código conduce directamente a un código de alta calidad. Esto es por dos razones muy simples. En primer lugar, porque la dolorosa verdad es que algunos de sus programadores no son tan buenos como los demás, y si poseen código, ese código será pobre; darle acceso a sus mejores programadores lo mejorará. En segundo lugar, la revisión del código: si todos poseen el código, todos pueden revisarlo y mejorarlo; incluso los buenos programadores escriben código por debajo del par 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 algunas partes del sistema que se han especializado: yo y otro tipo somos propietarios de facto del sistema de compilación, por ejemplo, hay un tipo que está haciendo la mayor parte del trabajo en los datos entrantes. , otro tipo que trabaja en la importación de imágenes, etc. En varias de esas áreas (particularmente, ¡tengo que confesar, en mi área!), La calidad del código ha sufrido seriamente: hay errores, conceptos erróneos, errores y hacks que simplemente no podrían sobrevivir a la atención de otras personas en el equipo.

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

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

Por ejemplo, tenemos un par de personas en nuestro equipo que crean páginas web administrativas para nuestros productos de servidor. Creamos un motor de scripts personalizado del lado del servidor para que pudiéramos llamar a las funciones C en el servidor directamente desde nuestros scripts 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 la página web de los demás.

Creo que usted toma la propiedad individual del código en el momento en que lo escribe y luego lo entrega 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 eso me topé con tu pregunta.

La forma en que lo veo es: "cuando todos lo poseen, nadie lo posee".

Para mí, no hay un factor más importante para codificar la calidad que la propiedad y la responsabilidad.

El ejemplo de la vida real ilustra esto bien. ¿cuál cuidaría mejor: su jardín privado o el parque de la comunidad? Bastante obvio.

Eso, por cierto, no necesariamente tiene que ser cambiado por "flexibilidad de equipo". Simplemente significa que cuando una persona posee algo, lo posee - 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 donde los niveles de competencia varían enormemente entre los miembros, podría ser bueno buscar una noción más sólida de propiedad del código con una mentalidad más modular de caja negra.

Al carecer de esto, por ejemplo, su interfaz cuidadosamente diseñada conforme a los principios SÓLIDOS puede ser arruinada rápidamente por alguien que ni siquiera sabe "SÓLIDO" significa y quiere agregar nuevas funciones eclécticas todo el tiempo a la interfaz por "conveniencia", por ejemplo Esto es, de lejos, lo 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 raíz (por ejemplo, tratar de responder a un informe de bloqueo simplemente poniendo soluciones alternativas en el código solo para ocultar el error y transferir el mortal efectos secundarios a otra persona). En ese caso, no es tan malo como el sabotaje de diseño de interfaz y puede proteger sus intenciones con pruebas unitarias cuidadosamente construidas.

La solución ideal es fortalecer su equipo hasta el punto en que esta noción de autoría y propiedad ya no sea tan importante. La revisión por pares no se trata solo de mejorar la calidad del código, sino también de mejorar el trabajo en equipo. Los estándares no son solo sobre 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 no tiene remedio y traerá muchos críticos inexpertos a la mezcla. Yo diría que mucho de si la propiedad del código o la propiedad del equipo tiene una mayor prioridad se basará en la capacidad de su equipo para realizar una revisión por pares efectiva y realmente dejar que todos salgan como si se hubieran beneficiado (tanto en términos de la revisión en sí misma) , y cada vez más cerca en mentalidad y estándares como resultado). En equipos grandes, sueltos y / o dispares, esto puede parecer inútil. Si su equipo puede funcionar como un "escuadrón" donde apenas puede decir quién escribió qué, entonces la propiedad exclusiva comenzará a parecer una idea tonta.

En este tipo de escenarios lejos de ser ideales, esta noción de propiedad del código en realidad puede ayudar. Está tratando de superar el peor de los casos, pero puede ayudar si el trabajo en equipo generalmente no tiene remedio para poner un cerco 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 pisar los pies.