En general, desea asegurarse de que cada área de su base de código tenga más de una persona que esté familiarizada con ella .
Esto se conoce como el principio de “golpeado por un autobús” : si un miembro de su equipo es golpeado por un autobús (o se enferma, se le reasigna o abandona la empresa), desea que el equipo pueda continuar sin incidentes.
Hay beneficios adicionales al tener a varias personas trabajando en la misma área:
- ¿Cuáles son los pasos que sigue para optimizar un sitio web?
- ¿Cuál es la mejor manera de dividir un proyecto de desarrollo web basado en Rails entre dos desarrolladores?
- ¿Qué es una aplicación de una sola página en desarrollo web?
- ¿Por qué los componentes ReactJS están tan hinchados en comparación con componentes similares de jQuery / Bootstrap (por ejemplo, botones, selectores de fecha, carga de imágenes, etc.)?
- ¿Qué roles de base de datos predeterminados se crean cuando crea una base de datos?
- La propiedad de código compartido significa que cualquiera puede mejorar todo el código . Es importante tratar de construir un ambiente positivo donde las personas se sientan empoderadas para cambiar lo que no funciona.
- Genere discusiones : si usted es la segunda persona en ingresar a un área que ha sido construida por otra persona, a menudo le preguntará al respecto y hablará sobre cómo evolucionarlo. Estas discusiones son excelentes para compartir conocimientos.
- Evite la creación de agujeros de deuda técnica : una excelente manera de crear una deuda técnica masiva en su proyecto es asignar un desarrollador junior (o excéntrico) como la única persona que trabaja en una gran característica para la que no está preparado. Tener a otra persona asignada a la misma función asegurará que haya alguien para desafiar las ideas realmente terribles y evitar la locura.
- Conocimiento compartido = Menos errores. Cuanto más entiendas todo lo que toca tu código, menos errores introducirás. Lo mismo para su capacidad de encontrar rápidamente errores creados por otra persona.
- Rendición de cuentas a sus colaboradores: he visto a ingenieros superiores muy talentosos escribir códigos terribles porque eran la única persona que trabajaba en un sistema. Saber que otros también tendrán que tocarlo conduce a una barra de mayor calidad.
Esas fueron algunas de las razones para crear un conocimiento superpuesto de su base de código. ¿Hay alguna razón para no hacerlo?
Si todos lo poseen, a veces nadie lo posee:
- ¿Quién interactúa con otras disciplinas? Los diseñadores, artistas, productores, etc. necesitan saber con quién coordinarse.
- Los sentimientos de baja propiedad pueden conducir a una ejecución mediocre.
- Ventanas rotas: si algo ya era terrible y estás siguiendo el patrón establecido, ¿quién es responsable de que las cosas nuevas también sean terribles?
Estas cosas requieren una discusión activa en su equipo.
A veces es bueno asegurarse de que una sola persona permanezca con una función hasta que alcance un cierto nivel de integridad y establezca esa expectativa desde el principio. Solo asegúrate de que no estén solos durante meses sin aportes.
