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)