¿La propiedad del código es un olor a código?

Esto es algo en lo que he estado pensando desde que leí esta respuesta en el controvertido hilo de opiniones de programación :

Tu trabajo es dejarte sin trabajo.

Cuando escribe software para su empleador, cualquier software que cree debe escribirse de tal manera que cualquier desarrollador pueda recogerlo y comprenderlo con un mínimo esfuerzo. Está bien diseñado, escrito de manera clara y consistente, formateado de manera limpia, documentado donde debe estar, se construye diariamente como se espera, se registra en el repositorio y se versiona adecuadamente.

Si lo atropella un autobús , lo despiden, lo despiden o se va del trabajo, su empleador debería ser capaz de reemplazarlo en cualquier momento, y el próximo individuo podría asumir su papel, recoger su código y levantarse. corriendo dentro de una semana como máximo. Si él o ella no pueden hacer eso, entonces has fallado miserablemente.

Curiosamente, he descubierto que tener ese objetivo me ha hecho más valioso para mis empleadores. Cuanto más me esfuerzo por ser desechable, más valioso me vuelvo para ellos.

Y se ha discutido un poco en otras preguntas, como esta , pero quería mencionarlo nuevamente para discutirlo desde un punto de vista en blanco "¡ es un olor a código! ", Que realmente no se ha cubierto en profundidad todavía.

He sido desarrollador profesional durante diez años. Tuve un trabajo en el que el código estaba bien escrito lo suficiente como para que un nuevo desarrollador decente lo recogiera relativamente rápido, pero en la mayoría de los casos en la industria, parece que un nivel muy alto de propiedad (tanto de propiedad individual como de equipo) es norma. La mayoría de las bases de código parecen carecer de la documentación, el proceso y la "apertura" que permitirían a un nuevo desarrollador recogerlas y trabajar rápidamente con ellas. Siempre parece haber muchos trucos y trucos no escritos que solo alguien que conoce muy bien la base del código ("la posee") conocería.

Por supuesto, el problema obvio con esto es: ¿qué pasa si la persona se detiene o "es atropellada por un autobús"? O a nivel de equipo: ¿qué pasa si todo el equipo sufre una intoxicación alimentaria cuando salen a almorzar y todos mueren? ¿Sería capaz de reemplazar el equipo con un nuevo conjunto de nuevos desarrolladores aleatorios relativamente sin dolor? - En varios de mis trabajos anteriores, no puedo imaginar que eso suceda en absoluto. Los sistemas estaban tan llenos de trucos y trucos que " solo tienes que saber " que cualquier equipo nuevo que contrates tardaría mucho más que el ciclo económico rentable (por ejemplo, nuevos lanzamientos estables) para que las cosas vuelvan a funcionar. En resumen, no me sorprendería si el producto tuviera que ser abandonado.

Obviamente, perder un equipo completo a la vez sería muy raro. Pero creo que hay algo más sutil y siniestro en todo esto, que es el punto que me hizo pensar en comenzar este hilo, ya que no lo he visto discutido en estos términos antes. Básicamente: creo que una gran necesidad de propiedad del código es a menudo un indicador de deuda técnica . Si hay una falta de proceso, comunicación, buen diseño, muchos pequeños trucos y trucos en el sistema que "solo tienes que saber", etc., generalmente significa que el sistema se está endeudando cada vez más y más.

Pero la cuestión es que la propiedad del código a menudo se presenta como una especie de "lealtad" a un proyecto y una empresa, como una forma positiva de "asumir la responsabilidad" de su trabajo, por lo que es impopular condenarlo directamente. Pero al mismo tiempo, el lado de la deuda técnica de la ecuación a menudo significa que la base del código se está volviendo cada vez menos abierta y más difícil de trabajar. Y especialmente a medida que la gente avanza y los nuevos desarrolladores tienen que tomar su lugar, el costo de la deuda técnica (es decir, el mantenimiento) comienza a dispararse.

Entonces, en cierto sentido, realmente creo que sería bueno para nuestra profesión si un alto nivel de necesidad de propiedad del código fuera visto abiertamente como un olor a trabajo (en la imaginación popular del programador). En lugar de ser visto como "tomar responsabilidad y orgullo" en el trabajo, debería verse más como "afianzarse y crear seguridad laboral artificial a través de la deuda técnica".

Y creo que la prueba (experimento mental) debería ser básicamente: ¿y si la persona (o de hecho, todo el equipo) desapareciera de la faz de la Tierra mañana? ¿Sería una lesión gigantesca, posiblemente mortal, para el proyecto, o podríamos traer gente nueva, hacer que lean los documentos y archivos de ayuda y jugar con el código durante unos días, y luego volver a entrar? negocio en unas pocas semanas (y volver a la productividad total en un mes más o menos)

Creo que debemos hacer una diferencia entre la propiedad del código:

• desde el punto de vista de la responsabilidad,
• desde el punto de vista del estilo de código / hacks, etc.

El primero debe ser alentado. Si nadie es responsable del código y los errores de baja calidad, sucederán cosas malas . No significa que el error relacionado con su propio código deba asignársele siempre: si el código está escrito correctamente, cualquiera puede corregir el error en cualquier parte del código. Pero si no tiene ningún comentario sobre los errores que tiene, producirá los mismos errores una y otra vez .

La propiedad del código puede ayudar mucho tanto a los gerentes como a los desarrolladores, especialmente a los desarrolladores. Si sé que el 80% de los errores en el producto estaban en mi código mientras éramos tres desarrolladores trabajando en el proyecto, y que el 75% de esos errores estaban relacionados con la inyección de SQL, sería más cuidadoso al escribir código la próxima vez, y haga un esfuerzo adicional para escribir las consultas de la base de datos correctamente.

El segundo (propiedad del código del estilo de código / hacks, etc.) es principalmente algo malo. ¿Qué aporta al producto? No aumenta la calidad del producto, pero disminuye la uniformidad del código fuente y hace que sea difícil mantenerlo últimamente .

Para muchos proyectos grandes, las personas no se quedan de por vida trabajando en el mismo código. Y aquí, ni siquiera hablo de cosas horribles como que el desarrollador sea golpeado por un autobús: no creo que la propiedad del código sea la primera preocupación en este caso. Pero suceden muchas cosas menores: las personas migran del desarrollo a la gerencia u otros trabajos, o eligen otros proyectos, o trabajan en otras cosas, o comienzan a usar otro idioma (si se usan varios idiomas dentro de un proyecto), etc.

Una parte del código de un proyecto también se puede reutilizar en otro proyecto, y el desarrollador que trabaja en este otro proyecto quisiera modificar algunas partes del código para que se ajusten a las nuevas necesidades, sin pedir consejo al antiguo redactor del código.

¿Es un olor a código? Bueno, depende de qué quieres decir con código de olor. Para mí, se trata de la coherencia general del proyecto y la gestión correcta . En un buen proyecto,

• Se aplican pautas de estilo de código para ayudar a comprender el código más fácilmente más adelante,
• Los desarrolladores más experimentados no violan el principio KISS, lo que ayuda a los colegas menos experimentados a comprender el código fuente más adelante.

Para concluir, la propiedad del código debe rastrearse a través del control de versiones, pero no debe ser capaz de decir que usted o alguien más de un equipo ha escrito un código .

Primero necesitamos definir qué es "propiedad de código".

Cuando una parte (parte) del código se encuentra en el proceso inicial de desarrollo, a menudo es necesario designar a una o dos personas como "propietarios" porque:

• Al principio no hay especificaciones o requisitos claros, y los desarrolladores deberán recopilar información por su cuenta. Hay un intervalo de tiempo entre la recopilación y la documentación de esos hallazgos.
• Evite ediciones en conflicto cuando el fragmento de código se está modificando activamente.
• Los "propietarios" son las personas que pueden informar el progreso del desarrollo de la función.

Normalmente hay un único propietario para cada tarea. Los propietarios dobles son posibles con la programación por pares. No sería práctico hacerlo sin ninguna "propiedad de código" estrictamente designada.

Nota:
Consulte la respuesta de @ MainMa para conocer los otros problemas durante el desarrollo. En esos casos, la "propiedad del código" es un síntoma de problemas mayores, es decir: elección subóptima de la arquitectura, inconsistencia del estilo de codificación y, en general, falta de calidad del código.

Una vez que una pieza se escribe y acepta en la base del código ("hecho"), aparece la pregunta más general de "propiedad del código".

• ¿Quién es el experto que puede responder todas las preguntas sobre este código / esta parte de la funcionalidad?
• ¿Se ha capturado este conocimiento en artefactos tangibles, como documentos de requisitos, pruebas unitarias, pruebas de aceptación, registros de cambios, wiki del proyecto, etc.?

Siempre habrá una parte del conocimiento de dominio (comprensión tácita de los requisitos de los clientes, problemas de compatibilidad con sistemas arcanos, etc.) que es difícil formalizar en especificaciones escritas. Por lo tanto, cuando hay un evento de calamidad, es de esperar una pérdida de conocimiento del dominio.

Junto con la pérdida de conocimiento del dominio, también perderá los respondedores expertos que pueden explicar los detalles del sistema. En este aspecto, la pérdida del experto es algo universalmente malo. El conocimiento debería haber sido capturado antes.

Esto no significa que la existencia de "expertos" sea mala: considere que los expertos son un "caché" del conocimiento escrito. Los expertos a menudo pueden responder preguntas más rápido que tener que buscar y digerir el conocimiento escrito.

Sin embargo, a veces "propiedad del código" se refiere a las barreras establecidas por los desarrolladores activos de un proyecto para evitar que personas externas modifiquen el código.

• ¿Quién puede hacer cambios a este código?
  • Para corregir errores obvios?
  • ¿Hacer que el código satisfaga algunos otros requisitos?
  • ¿Reescribir completamente el código al gusto de uno?

Hay buenas barreras y malas barreras:

• Buenas barreras
  • Conocimiento de dominio: qué tan bien comprende los requisitos y el estilo de arquitectura / codificación
  • Habilidad de programación y diseño: ¿tiene las habilidades para mejorar el diseño del proyecto y la calidad del código?
• Malas barreras
  • No estaba en el equipo de desarrolladores original, por lo que no puede realizar cambios.
  • Solo las correcciones de errores son bienvenidas. Las mejoras de funciones no son bienvenidas.

En este caso, el privilegio de editar el código fuente de otro proyecto no debe basarse en la propiedad del código, sino en el mérito.

Finalmente, la respuesta de @Graham Lee apunta a la fragmentación del conocimiento y la arquitectura causada por la departamentalización.

En este caso, la "propiedad del código" es uno de los síntomas de la departamentalización. Un segundo síntoma es la "falta de interés en los proyectos de otros equipos". Como organización, los gerentes deberán tomar medidas para alentar la transferencia de conocimiento y la colaboración entre equipos y departamentos.

Más insidiosamente, algunas compañías (he trabajado en una) organizan su estructura de administración en torno a equipos funcionales: usted administra los desarrolladores de clientes de Windows, ella administra el equipo instalador, él administra los desarrolladores de back-end, etc. Esto no solo conduce a la fuerte propiedad del código que usted describe, sino que lo consagra como la forma en que funciona el negocio. Convierte la arquitectura del software en una lucha política.

¿Es esto un problema? Es si la arquitectura es o se vuelve subóptima. Es imposible decir (por ejemplo) que el instalador funcionaría mejor o sería más barato de desarrollar si fuera solo un caso de uso del cliente, porque eso le quita el control a un equipo y a su gerente. Las divisiones entre módulos funcionales se han convertido en hechos sobre la forma en que se ejecuta el departamento de ingeniería, y se necesita mucha agitación para alterar esos hechos.

[Por cierto, en caso de que la discusión anterior no lo aclare, mi respuesta a su pregunta es sí. La propiedad del código es un olor a código, porque puede evitar que personas inteligentes con buenas ideas, o incluso personas que estén disponibles cuando las necesite, trabajen en el código. Obviamente, tener controles para detener los cambios caprichosos es algo bueno, pero si tiene un ingeniero que puede ver cómo solucionar un error y tiene tiempo para hacerlo, no debe bloquearlo porque alguien más escribió el código de error. ]

Al abordar su pregunta desde un punto de vista ligeramente diferente, la propiedad del código NO es un olor a código. En cambio, es un olor de gestión y recursos .

Piensa en lo que significa un olor a código. Es una metáfora que le dice cuando mira su código, que algo no está del todo bien con el código y / o el diseño del software, pero el problema puede no ser tan obvio como para ser capaz de señalar qué el problema exacto puede ser, pero probablemente tengas una buena idea independientemente. En su hogar, si algo huele mal, siga su nariz hasta que encuentre la fuente del problema y luego haga algo al respecto. De la misma manera, si el código tiene un problema, investíguelo y cámbielo hasta que se convierta en un problema menor, o como algunos podrían decir, hermoso o bien elaborado .

La propiedad del código, por otro lado, puede ser un problema grave. Sugiere una falta de supervisión y un riesgo de que si el propietario del código se va, ese conocimiento sobre el código y los problemas específicos que resuelve ya no estarán disponibles para la empresa. Esto no tiene nada que ver con el código real en sí. Básicamente se trata de una situación de gestión de riesgos de la misma manera que nos lleva a mantener copias de seguridad de nuestros datos, y se aplica igualmente a la propiedad de la tarea, o la propiedad del documento en otras áreas de la empresa.

Creo que está bien describir otros problemas comerciales como olores , pero ciertamente no implica que solo porque haya un olor , tiene que ver específicamente con el código.

Defino la propiedad del código como asumir la responsabilidad personal del código que usted escribe, con el entendimiento de que otros trabajarán en su código en el futuro . Si piensa en las cosas de esta manera, será menos probable que escriba un truco porque a) los errores en ese módulo podrían rastrearse hasta usted, yb) los miembros del equipo probablemente tengan dificultades para modificar el código en el futuro .

Escribí una publicación de blog sobre esto hace varios meses, donde sostuve que sin la propiedad del código, como lo defino, una base de código a menudo cae presa de la Tragedia de los Comunes .

Según su definición de propiedad del código, estoy de acuerdo en que es malo tener un código en el que solo el autor pueda trabajar.