¿Cuándo es útil la propiedad del código compartido?

Question

Últimamente he trabajado en varios proyectos que han promovido la idea de la propiedad de código compartido. A veces, esto pareció acelerar la mejora y la mejora del código. Otras veces, parecía convertirse en un terreno de disputas egocéntricas con cambios que se realizaban para apoyar a los individuos codificando estilos, tecnologías favorecidas o simplemente una demostración de poder/intelecto.

¿Cómo se puede implementar la propiedad del código compartido para evitar las trampas y aún así obtener los beneficios? ¿Pueden demasiados cocineros echar a perder el caldo?

Answer 1

Sin duda, los estándares de codificación pueden ser útiles, especialmente si están respaldados por una integración continua y/o políticas de control de origen.

Primero, defina los estándares y haga que el equipo los acepte (la administración rompe lazos).

En segundo lugar, use herramientas automatizadas (preferiblemente con ganchos IDE) para manejar el formato del código.

En tercer lugar, use herramientas automáticas de análisis estático para verificar el cumplimiento. Estos pueden ir más allá de validar el formato y verificar las métricas de complejidad del código, las convenciones de nombres, las mejores prácticas, etc. Las mejores pueden personalizarse para que coincidan con las reglas de su equipo. Si es posible, busque los que permitan suprimir las advertencias inadecuadas a través de metadatos (como los atributos). La mayoría de las reglas tienen excepciones, y desea ocultar el "ruido" de los falsos positivos.

En cuarto lugar, integre el análisis estático con su sistema de control de fuente/revisión para que se ejecute durante el check-in. Algunos sistemas permiten rechazar registros que no pasan las políticas. Otra opción (que no se excluye mutuamente) es configurar un servidor de integración continua que se autocompone en el check-in; puede ejecutar análisis estáticos y notificar a todos los desarrolladores sobre cualquier falla.

Answer 2

Me pareció que la propiedad del código compartido funciona bien cuando se combina con el seguimiento de problemas y las pautas de codificación. Es decir, las personas trabajan en cuestiones (asignadas durante las reuniones de desarrollo) que pueden incluir el código de cualquier persona y muchas preguntas de "estilo" abordadas en las directrices. Esto parece ser bastante efectivo y no parece tener el problema que mencionaste de personas que cambian el código sin una buena razón.

Answer 3

• La comunicación a través del apareamiento, las pruebas y el código limpio: Cuando no tiene un montón de tiempo para escribir documentos técnicos o cuando el sistema está cambiando tanto que no pueden mantenerse al día con la necesidad de escribir documentos técnicos.

• Los equipos ágiles no tienen una "figura de arquitecto" que dicte exactamente cómo encaja todo. Los miembros del equipo Agile tienen una visión mucho más democrática de las cosas y el diseño es colaborativo. Esto significa más comunicación, y un tipo y volumen de comunicación que sería difícil de mantener solo a través de documentos escritos. (No quiere decir que no es necesario documentos - pero es necesario que el apareamiento cara a cara y la influencia sobre la dirección compartida.)

• La propiedad compartida es útil para equipos distribuidos que necesitan compartir una base de código básico común . En un equipo distribuido en el que trabajé, enviamos colaboradores remotos a nuestra sede para vincularnos con el código común, de modo que pudieran obtener suficiente conocimiento y confianza para trabajar en él en sitios remotos mientras los autores originales del código están durmiendo en él. una zona horaria diferente. Resultado: menos necesidad de esperar a los expertos remotos.

• Está construyendo algo que requiere varios tipos diferentes de experiencia, y ningún miembro del equipo es un experto en todos esos campos.

• El proyecto integra dos o más subsistemas complejos y los expertos en cada subsistema se distribuyen de forma desigual entre los miembros del equipo.

• La implementación es realizada por un subcontratista, pero algún otro grupo adoptará el sistema y lo mantendrá. Ambas partes deben emparejarse e influir en la dirección para que esto sea sostenible.

Answer 4

La propiedad compartida tiene muchos beneficios. A continuación se presentan los puntos idealizadas, pero se puede obtener un largo camino hacia ellos, especialmente como tejidos de punto del equipo, junto con el tiempo:

• Muchos cerebros piensan mejor que una. Los codificadores a menudo detectan errores o cuestionan rarezas en los códigos de los demás, lo que mejora la robustez general del código. Piense en ello como una revisión continua del código de pares.
• Disminuye el riesgo de perder conocimiento crítico/valioso si un desarrollador es golpeado por un autobús o dimite.
• Si un desarrollador está de vacaciones por una semana, no tiene que esperar una semana para que se solucione un error. O no tienes que explicarle a un codificador enojado por qué te metiste con "su" código mientras le daban la espalda.
• Divulga el conocimiento del producto en todo el equipo. Un tipo que llame a una biblioteca cometerá menos errores si realmente trabajó en el código de la biblioteca y lo entiende bien. Un tipo que llame a una caja negra de la que no sepa tomará más tiempo y cometerá más errores.
• Divide el conocimiento de la codificación en todo el equipo. Todos aprenden trucos y patrones de otros (incluso los mejores programadores a veces pueden aprender algo que no sabían de un junior)
• Acuerda el estilo de codificación: las personas tienen egos y tienden a gustar iniciar guerras de religión, pero si trabajan en el misma base de código y el administrador aplica los estándares de codificación e interviene para mantener las "peleas" sobre el estilo bajo control, después de un tiempo el equipo comienza a trabajar como un grupo coherente, la calidad del código aumenta y las peleas dejan de suceder.
• Ayuda a todos a sentirse parte de un equipo, sin cañones sueltos. No hay primadones y todos sienten que son iguales y su aportación es valorada y vale la pena, esto se traduce en una mejor autoestima. Además, cuando el equipo logra un objetivo, todos se sienten bien al respecto, y cuando el equipo falla, nadie siente todo el peso de la responsabilidad individual.
• Los programadores se comunican más, lo que le proporciona un mejor espíritu de equipo y una mayor disposición a ayudar a los demás.
• Mejora la calidad del código porque los programadores saben que otros leerán su código, por lo que tienden a dejarlo todo en un estado mucho más ordenado para evitar situaciones embarazosas. También saben que tienen que hacer que su código sea fácil de entender para otros, así que comienzan a escribir código para que otros lo mantengan, en lugar de escribir código para ellos mismos.

desventajas posibles pueden incluir:

• peleas y guerras religiosas más pequeñas diferencias de opinión sobre el estilo o la aplicación de codificación enfoques
• "Demasiados cocineros estropean el caldo" - a veces la mejor manera de mantener un diseño limpio y enfocado es tener solo una persona como cerebro. Sin embargo, esto no significa necesariamente que hagan todo el trabajo, siempre y cuando todos los miembros del equipo comprendan la visión y sigan el diseño del arquitecto. Las revisiones de código pueden ser muy poderosas aquí.
• No todos los programadores son creados iguales. En ocasiones, puede ser frustrante cuando su equipo puede ofrecer un buen código de limpieza, pero tal vez una persona no puede alcanzar la calidad que brinda el resto del equipo. Esto puede engendrar descontento y dividir a un equipo, ya que pueden sentir que su maravillosa creación está siendo corrompida.
• Los programadores que simplemente no quieren ser jugadores de equipo o sienten que son mejores que los demás pueden ser muy perjudiciales.

Yo diría que en todos estos casos, las cosas generalmente mejoran cuando haces que estas personas compartan la propiedad. A veces no lo suficientemente rápido, pero si dejas que un solitario permanezca solitario, nunca aprenderá a ser un jugador de equipo. Si dejas a los chicos débiles fuera del equipo, ¿cómo van a aprender y fortalecer sus habilidades? Si alguien tiene habilidades de comunicación deficientes, ¿cómo lo ayudará a aislarlo? En última instancia, necesita un equipo cohesivo que tenga una amplia comprensión de la base de código, y mantener a los miembros separados y enfocados en áreas especializadas pequeñas nunca lo logrará.

Answer 5

creo que las revisiones son:

• estándares de codificación, elimina estética peleas y tiene muchos otros beneficios.
• compromisos comunes, si alguien está haciendo cambios que no mejora el diseño o implementar alguna funcionalidad requerida entonces el equipo debería estar llamando a ellos en él. Después de todo, si está soplando el tiempo postura en lugar de proceder hacia el objetivo que está afectando el rendimiento de los equipos . La presión social puede y luego seguir su curso.

También debe evaluar usted mismo. Existe una tendencia natural a creer que las acciones con las que uno no está de acuerdo son irracionales. Muy a menudo, uno carece de las experiencias que motivan al otro y, a veces, uno tiene que superar las inversiones de su propio ego.

Answer 6

Tuve buenas y malas experiencias con la propiedad de código compartido.

Se siente bien cuando:

• Código es utilizado por varias personas, como utilidades e interfaces.
• Los programadores tienen una cualificación y un nivel de conocimiento comparables.
• Todos los propietarios necesitan algo del código compartido.

Se siente mal cuando:

• Código no es estable (cuando la creación de prototipos o refactorización). El propietario debe estabilizarlo primero.
• Aplicado como política. El equipo lo simulará y odiará al ejecutor.
• El código está mal escrito. Necesita ser arreglado, no compartido.

En general, la propiedad compartida de todo no es una buena idea. Es mejor compartir cuando se siente natural, y mantener el código para usted cuando no sea así.

Answer 7

En el lado negativo: -

• Código de titularidad compartida es sólo tan buena como la más débil miembro del equipo/revisor
• Un miembro del equipo débil puede introducir una estructura pública mal, que se convierte en irrevertable, porque algún sistema externo inmutable se vuelve dependiente de él, antes de ser detectado. En el mundo real, he visto esto suceder demasiadas veces.
• Dejando de lado los incidentes de autobús, un oráculo con aspecto de dios casi siempre resolverá los asuntos de misión-dependientes del tiempo que dependen del tiempo, en una fracción del tiempo de muchas tomas de todos los oficios.

propiedad compartida código sólo funciona si todo el mundo en el equipo es altamente calificado, y no hace malas llamadas, a través de las brechas de conocimiento. En otras palabras, todos los integrantes del equipo deben ser expertos en todo el código y comprender plenamente el impacto que tendrán sus cambios en los sistemas que pueden no ser visibles desde una visión limitada de la tarea en cuestión.

Answer 8

Deberías leer esto. La propiedad del código no es tan buena como crees.

https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.ldlpppzh2