De un traductor: publicamos para usted
un artículo del desarrollador Jack Finlay. Jack habla sobre su propio caso: un intento de organizar el trabajo como un equipo de juniors, donde todos son iguales y no hay un gerente técnico. Este artículo será útil para programadores novatos.
Algunos proyectos pueden paralizarse y terminar en nada por varias razones. La orientación técnica es algo que a menudo falta. Este problema puede conducir a un fiasco. Una vez sucedió con un proyecto en el desarrollo del cual participé.
Skillbox recomienda: Curso práctico de dos años "Soy un desarrollador web PRO" .
Le recordamos: para todos los lectores de "Habr": un descuento de 10.000 rublos al registrarse en cualquier curso de Skillbox con el código de promoción "Habr".
El tiempo puede enseñarte mucho. Desafortunadamente, ganamos experiencia como resultado de trabajar no solo con proyectos exitosos, sino también con proyectos que no tuvieron éxito.
Experiencia personal y liderazgo
Más precisamente, la falta de la misma. No había ningún desarrollador principal o principal en nuestro proyecto. En principio, ya estaba claro qué pasaría con nuestro trabajo, pero en ese momento no entendíamos esto.
El equipo no tenía experiencia. Casi todos éramos estudiantes, y no había nadie que pudiera guiarnos. Entonces no nos pareció necesario.
En el transcurso de un verano, el número de miembros del equipo aumentó cinco veces. Un problema? Todos tenían el mismo nivel profesional. Todos carecían de experiencia. Nos dividimos en varios grupos, cada uno de los cuales era responsable de algo.
Además, casi todos los participantes del proyecto eran buenos responsables. Pero este fue nuestro primer proyecto comercial. Mi equipo fue muy bueno, trabajamos perfectamente, pero el resultado fue un fracaso.
Kit de herramientasUn componente clave del trabajo de cualquier profesional son las herramientas. Sin las herramientas adecuadas, un flujo de proceso normal es imposible. Un buen equipo generalmente tiene un líder que sabe quién necesita qué herramientas y dónde obtenerlas.
Bases de datosEn este proyecto, tuvimos acceso a una base de datos compartida alojada en una máquina virtual, una de las más lentas que se pudo obtener. Naturalmente, experimentamos todos los "placeres" de dicho trabajo: pérdida de datos, tablas descendentes, acciones simultáneas sobre los mismos elementos. Todo esto genial ralentizó nuestro trabajo.
No podríamos reproducir la base de datos localmente o en la nube sin realizar la operación de copia de seguridad y restauración. No había forma de obtener una base de datos "limpia" en el mismo estado en el que nos gustaría implementarla en diferentes entornos. La base de datos solo se puede crear como un clon de la base de datos de nuestro servidor.
Pero el proyecto solo funcionó con la base de datos, que se encontraba en el servidor de producción. Esto significaba que no podíamos probar la base de datos y el proyecto dependiendo de ella localmente. Varias veces surgió una situación en la que tuvimos que retroceder la base hasta cierto punto, porque por la noche alguien la destruyó con acciones descuidadas. Esto impidió en gran medida el proceso de desarrollo.
La migración y actualización de la base de datos se realizó manualmente. Eso significaba ... sí, estábamos perdiendo el tiempo otra vez.
Ahora parece obvio que los desarrolladores deberían tener bases de datos locales en sus máquinas. Además, debe usar herramientas de migración automatizadas. Esto les da a los desarrolladores la libertad y el espacio para maniobrar en ciertas situaciones.
RendimientoLos desarrolladores necesitan un alto rendimiento tanto en máquinas locales como en el servidor donde se está probando el proyecto. Pero como teníamos herramientas lentas, ni siquiera podíamos soñar con eso.
Muchos tenían dispositivos extremadamente lentos que se habían utilizado durante muchos años. Teclados, trackpads: todo esto llevaba el sello del tiempo.
Los servidores también eran lentos, como mencioné anteriormente. Como resultado, todo el proceso de desarrollo se ralentizó. Las pruebas también progresaron lentamente.
La conclusión es simple, al estilo de la identidad corporativa, es proporcionar al desarrollador el equipo y los recursos que necesita para el proceso normal de desarrollo.
Control de fuente
En general fue un caos. Utilizamos un sistema de control de fuente corporativo, pero el problema no estaba en el software. Simplemente no había estrategia. Equipos de desarrollo separados trabajaron cada uno "en su propio pantano", y no estuvimos de acuerdo sobre cuándo fusionaríamos los brunches individuales. El resultado es lo que sucedió: conflictos, conflictos durante la fusión en todas partes. Tuve que pasar mucho tiempo resolviendo problemas y una sincronización adecuada.
Integración y despliegueGeneralmente no teníamos soluciones de CI / CD. La implementación fue simple: copiamos los recursos de la carpeta integrada y los pegamos en el servidor usando Escritorio remoto. Si hiciste algo similar, puedes entender mi dolor.
Para aquellos que no han encontrado un problema: si tiene algo más que los archivos necesarios en el búfer, esto matará la carga de archivos al servidor. Si alguien más del equipo se une al servidor para cargar archivos, tendrá problemas. Además, algunos archivos pueden transferirse corruptos.
Mi consejo es elegir una solución de CI / CD para usted.
Control de calidad
Otro elemento importante del proceso de desarrollo es el control de calidad.
Revisión por paresEste trabajo fue con nosotros que los miembros del equipo se reunieron y analizaron el trabajo realizado. Y a veces ni siquiera miramos el código, por lo que pasaron una gran cantidad de momentos. Otro problema era que no teníamos experiencia, lo que significa comprender qué es un buen código. No pudimos aislar de inmediato los errores en el código que un desarrollador experimentado ve de inmediato.
Si el equipo tuviera un desarrollador senior, inmediatamente podría informarnos dónde están los problemas y cómo tratarlos. Pero él no estaba allí, trabajamos de forma independiente.
ProbadoresNosotros tampoco los teníamos. Realizamos las pruebas por nuestra cuenta. De nuevo sin experiencia. Como resultado, pasamos un tiempo precioso que dedicamos a detectar errores y eliminarlos.
Si quieres un buen código, necesitas probadores y profesionales. Los desarrolladores no siempre se enfrentan al problema de las pruebas de software.
Calidad del código
Muchos de nosotros al comienzo del viaje somos representantes de la cultura de "copiar el pasado". Esto significa que el desarrollador busca las soluciones necesarias para el proyecto en Stackoverflow e inserta la pieza encontrada sin una punzada de conciencia. El resultado no es un código muy bueno, que es prácticamente ilegible y que los desarrolladores encuentran difícil de explicar por completo. Incluso la persona que copió un sitio en particular a menudo no puede entender su trabajo.
Solo puedo aconsejar una cosa: si copia el código, debe entenderlo completamente. Sin esto, un proyecto normal no puede realizarse.
Código de espaguetiUna mala comprensión de la arquitectura del proyecto condujo al caos completo. El código de espagueti es una descripción suave de lo que sucedió al final.
Algunas secciones pasaron por diferentes manos, de diferentes desarrolladores, cada una de las cuales agregó algo diferente. El código final del proyecto fue un conjunto de ideas y "muletas".
No teníamos un sistema de inyección de dependencia, y no usamos ningún patrón de diseño común. Esto condujo a una gran cantidad de código incorrecto que simplemente comenzó a "pudrirse".
Que puedo decir La legibilidad del código es tan importante como la operación adecuada, y estas dos cosas van de la mano. Un estilo claro y consistente y un código consistente proporcionan el resultado más efectivo.
Conclusión
Muchos problemas surgieron debido a nuestra falta de experiencia. Simplemente no sabíamos cómo trabajar en el proyecto. No pudimos implementar adecuadamente el medio ambiente. No teníamos las herramientas y tecnologías necesarias.
Un buen líder de equipo resolvería todos estos problemas. Habría previsto con mucha anticipación.
Por cierto, el proyecto en sí no fue lo peor de lo que podría suceder. Conocí a muchos futuros colegas con quienes me comunico hasta ahora. Obtuve la experiencia necesaria para trabajar como profesional. Y me di cuenta de que sin un liderazgo adecuado, incluso el equipo más capaz no se da cuenta de todo su potencial. Nunca
Skillbox recomienda: