Git y desarrollo de equipo (para tontos)

Coautor del artículo: RicardoMilos

Introduccion

Hola Si viniste aquí, entonces te interesa la cuestión de cómo trabajan los programadores en un equipo. Si antes de eso trabajó solo en solitario, entonces probablemente le parezca que trabajar en equipo es más fácil, porque hay más manos y, por lo tanto, puede hacer el trabajo mucho más rápido. Pero no tan simple. Ahora nos familiarizaremos con las herramientas que se están desarrollando y lo que está sucediendo dentro del equipo.

Git

Seguramente estás familiarizado con esta situación:



Este es un problema de versiones. Típicamente, tal problema ocurre en personas creativas que constantemente rehacen todo y logran el ideal. Desafortunadamente, también en la programación, lejos de siempre, todo sale bien la primera vez. Imagine una situación: descubrió cómo rehacer un fragmento de código para que funcione un poco más rápido. Reescribe, compila, ejecuta y comprende que ahora el programa no funciona en absoluto. Todo esta roto.

Y aquí te das cuenta de que no guardaste la opción de trabajo, y el botón Z de tu teclado se rompió, por lo que ni siquiera puedes enviar spam ctrl + z. En un ataque de ira, atraviesas el monitor con la mano derecha bombeada. Por la noche, lloras envuelto en una manta y piensas en la difícil situación de los programadores.

Una situación deplorable ... Y para evitar que esto suceda, debe guardar versiones de su código.

Bueno, los programadores son personas inteligentes, y entendieron perfectamente que almacenar todas las versiones en forma de un montón de archivos no es lo más conveniente posible y que es necesario inventar algo urgente que facilite el almacenamiento de versiones y, por lo tanto, resuelva el problema de versiones.

Y aquí podemos hacer una analogía con los juegos. Casi todos los proyectos AAA tienen un sistema de guardado. Como buen ejemplo, el juego Papers Please.



Casi igual, todos los sistemas de control de versiones funcionan.

El Sistema de control de versiones (VCS) es un sistema que registra los cambios en un archivo o conjunto de archivos durante un largo período de tiempo, para que luego pueda volver a una versión específica.

Clasificación de LES:

1. Local
2. Centralizado
3. Distribuido

Ya descubrimos la moneda local (estos son los mismos montones de los mismos archivos)

Moneda fuerte centralizada

• servidor central
  todos los archivos bajo control de versiones
• un número de clientes
  recibir copias de archivos

Ejemplos:

• CVS
• Subversión
• Perforce

Moneda fuerte distribuida

1. Los clientes copian completamente todo el repositorio
2. El servidor central es responsable de proporcionar la copia maestra
3. La sincronización puede ser
   
   • Con servidor
   • Con cualquier cliente
   
   

Ejemplos:

• Git
• Mercurial
• Bazar

¿Por qué necesito LES?

1. Almacenar todos los cambios del proyecto
2. La capacidad de cambiar "a cualquier etapa del proyecto"
3. La capacidad de realizar el desarrollo simultáneo del equipo.
4. Capacidad para resolver problemas como los siguientes

Git

Git - Sistema distribuido de control de versiones
Publicado por Linus Torvalds
2005 - primera versión

Instalación:
Linux: sudo apt install git
Windows / macOS: enlace

Los desarrolladores usan:

• GNU / Linux
• Android
• Vino
• Google
• Cromo
• jQuery
• Php
• MediaWiki
• Qt

Conceptos basicos

Repositorio (repositorio, repositorio): un lugar donde la moneda fuerte almacena sus metadatos y una base de datos de objetos de proyecto
Directorio de trabajo : una copia de una versión específica de un proyecto extraída del repositorio
El área preparada ( área preparada ): un archivo de servicio que contiene información sobre lo que debe incluirse en la próxima revisión del proyecto
Revisión (revisión): un objeto que almacena el cambio en el estado del proyecto (versión del proyecto)
Comprometerse : crear una nueva revisión

Configurar GIT

Configuración de nombre de usuario

git config --global user.name "Your Name" git config --global user.email you@abc.net 

La configuración se guarda en un archivo .gitconfig oculto (en el directorio de inicio del usuario)

 [user] name = John Doe email = jdoe@example.com 

Crear repositorio

 mkdir first_git_repo cd first_git_repo git init 

Estados del archivo de proyecto

1. Fijo
   el archivo ya está en el repositorio
2. Modificado
   el archivo es diferente en contenido de su estado comprometido
3. Preparado
   un archivo modificado que se confirmará después de crear una nueva revisión (este archivo se incluirá en esta revisión)

Trabajar con código

• Inicialización de repositorio
  
  

   git init 

• O cambiar a una revisión específica
  

   git checkout _ 

1. Cambio en el código del proyecto: creación / eliminación / edición de archivos
   En cualquier IDE
2. Ver estado
   git status
3. Agregar archivos modificados al índice
   (transición al estado de Escenario)
   git add ___
4. Creando una revisión (de Staged a Repo)
   git commit -m ""

Resumir

Trabajar con divisas

¿Qué almacenar?

[+] Todos los archivos de código fuente
[+] Todos los recursos necesarios para la compilación
[+] configuración de compilación del proyecto
[-] configuración del proyecto en el IDE
[-] archivos compilados desde la fuente
[-] archivos ejecutables

Eliminar del índice

git rm _

Una confirmación puede contener cambios en varios archivos

¿Cuándo comprometerse?

• Cuando completé una pequeña tarea
• Si el problema es grande, divídalo en subpartes lógicas
• ¡El código debe estar operativo!

Ver historial

 git log git log --graph 

Número de revisión = SHA-1 Cambiar hash

Cambiar a auditoría

 git checkout sha1_hash git checkout _8__sha1 

Ramas

Una rama es una secuencia de confirmaciones en la que se desarrolla un funcional en paralelo

Rama principal - maestro

Sucursales en GIT

Mostrar todas las ramas existentes en el repositorio

git branch

Crear sucursal

git branch

Cambiar a rama

git checkout
No debería haber cambios sin guardar en este momento.

Crea una rama y cambia a ella

git checkout -b

Fusionar ramas

Fusionar ramas: el proceso de integrar cambios (confirmaciones) de una rama a otra:

b1 - rama a la que agregamos cambios
b2 - rama desde la cual agregamos cambios

 git checkout b1 git merge b2 

Ver historial

Utilidades de ventana:

• gitg
• gitk
• gitx
• gitKraken

Eliminar ramas

Eliminar sucursal

git branch –d _

BORRAR una rama

git branch –D _

O más bien, elimine la rama sin esperar a que los commits se muevan a master

Búfer de cambio sin guardar

O "¿qué hacer si necesita cambiar a otra sucursal y comprometerse temprano?"

Escribir cambios en el búfer temporal

git stash

Extraiga estos cambios del búfer

git stash pop

Enlaces utiles:

git-scm.com/book/en/v2
githowto.com/ru
en.wikipedia.org/wiki/version_system

Desarrollo del equipo

Entonces, si llegas a esta línea, significa que tienes al menos un pequeño trato con git (realmente espero que sí). ¿Pero qué pasa con el desarrollo del equipo? Veamos este problema con más detalle.

Un pequeño rompecabezas humorístico:

Dado:

• N desarrolladores
• Lugares de trabajo
• Términos de referencia (TOR)
• El internet

Pregunta:

• ¿Cómo llevar a cabo un proyecto sin llamar la atención de los asistentes?

La respuesta es:

• Equipo bien coordinado y trabajo duro.

¿Qué es un equipo? Como es ella

Un equipo es un pequeño número de personas:

• con habilidades complementarias (alguien está programando, alguien está diseñando, etc.)
• aspirando a objetivos comunes (todos deben cumplir con la tarea del cliente para obtener una completa autosatisfacción)
• compartir la responsabilidad de lograr el objetivo del proyecto (si de repente uno de los miembros del equipo tiene dificultades con su TK personal, sus compañeros siempre acudirán en su ayuda (esto no debe ser abusado, de lo contrario, simplemente será innecesario para el equipo)).

Una nota muy importante: en el equipo debe sentirse absolutamente cómodo e intentar llevarse bien con todo el equipo, de lo contrario, todo podría salir mal.

Entonces, ahora entiendes lo que es un equipo. Pero la siguiente pregunta que surge en su cabeza (sí, sí, los autores de este artículo pueden leer las mentes): “¿Y quién es responsable de qué en el equipo? ¿Todos tienen su propio lugar? ¿O todos están haciendo lo que quieren?

Naturalmente, cada participante en el equipo tiene su propio rol y sus propias tareas. De lo contrario, en lugar de desarrollar un producto, habría caos. Veamos los roles en la programación de comandos:

1. Jefe de equipo:
   
   Team Leader es un cruce entre un gerente de proyecto y un desarrollador calificado.
   
   Hay dos roles principales en los proyectos: gerencial - PM y técnico - Arquitecto de sistemas. Timlid cumple en parte ambos roles, pero el foco de sus responsabilidades está en la gestión (el énfasis en la parte técnica es el líder tecnológico).
   
   "Líder de equipo # 1: Cuidar a su equipo. El equipo debe sentirse cómodo en el entorno laboral y estar bien motivado. Además, el líder del equipo también proporciona crecimiento profesional y profesional para sus hijos, regularmente mantiene discusiones sobre el tema en el que las personas están interesadas en desarrollarse y les ayuda en esto ”.
   
   El rol directivo del líder del equipo incluye responsabilidades tales como la administración, asignación y delegación de tareas, todo tipo de evaluaciones y programación, monitoreo del estado del proyecto, así como reuniones, comunicación con el cliente, administración y todos los miembros del equipo (desarrolladores, evaluadores, gerentes).
   
   Bajo el rol técnico: participación en la redacción de documentación técnica, selección de tecnologías para el proyecto, desarrollo de arquitectura, I + D, revisión de códigos, tutoría de juniors, realización de entrevistas técnicas, participación competente de nuevos miembros del equipo en el proceso de trabajo, responsabilidad de la parte técnica del proyecto.
   
   Un día laboral típico de Timlid incluye:
   
   
   • consideración de nuevas tareas y su distribución
   • ponerse de pie con un equipo
   • manifestaciones
   • programacion
   • cuestiones arquitectónicas
   • revisión de código
2. Gerente de proyecto:
   
   Project Manager es un especialista cuya tarea principal es administrar el proyecto en su conjunto: diseñar y priorizar, programar tareas, monitorear, comunicar y resolver problemas rápidamente.
   
   La responsabilidad principal de PM es hacer realidad la idea del cliente a tiempo utilizando los recursos existentes. En el marco de esta tarea, PM necesita construir un plan de desarrollo, organizar un equipo, establecer un flujo de trabajo del proyecto, proporcionar comentarios entre los equipos y el cliente, eliminar la interferencia para los equipos y controlar la calidad y la entrega del producto a tiempo.
   
   Las tareas de MP se pueden clasificar como tácticas y estratégicas. Táctico: esta es la solución a los problemas cotidianos del proyecto, la eliminación de obstáculos del equipo. Los estratégicos son coordinar el objetivo general del proyecto, el camino hacia él y la velocidad de movimiento.
   
   "La declaración de objetivo principal para PM es:" Necesitamos que esto funcione ", lo que implica que el equipo proporcionará el resultado en un período de tiempo razonable con un nivel razonable de calidad".
3. Probador:
   
   Un probador es un especialista que se dedica a probar un producto de software para identificar errores en su trabajo y su posterior corrección.
   
   Los principales deberes del probador:
   
   
   • Control de calidad de productos desarrollados.
   • Identificación y análisis de errores y problemas encontrados por los usuarios al trabajar con productos de software.
   • Desarrollo de autotest y su ejecución regular.
   • Prueba de desarrollo de guiones.
   • Documentando defectos encontrados.
4. Desarrolladores:
   
   
   • Junior:
     Junior es un desarrollador de nivel de entrada.
     
     Después de completar una pasantía, una persona se convierte en un junio completo. El requisito principal para ello es la capacidad de realizar tareas técnicas de forma independiente. Si un proyecto está construido en arquitectura, debe implementar inmediatamente otra pieza de la lógica de aplicación típica. Aunque Junior puede cometer errores de vez en cuando, no entienda los matices, discuta los planes de implementación con el líder del equipo o verifique el código terminado con él.
     
     Debe comprender que para las tareas que el Signor resolverá en diez minutos, junio puede necesitar tres enfoques cada hora, y en el proceso, el código deberá reescribirse por completo, gastando mucha energía adicional. Es importante no tener miedo de esto y sentir el equilibrio: cuándo empujar, tratar de resolver el problema usted mismo y, por el contrario, dejar de golpearse la frente contra la pared, quemar el tiempo del proyecto y pedir ayuda. Justificar su falta de rendimiento con la frase "Todavía estoy en junio" es una mala idea.
   • Medio:
     
     Medio: un desarrollador de nivel medio.
     
     El requisito principal para un desarrollador intermedio es la capacidad de realizar de forma independiente las tareas que se le asignan. Muy similar a lo que se escribió en el párrafo anterior, ¿verdad? Sin embargo, hay una advertencia importante: aquí falta la palabra "técnico". Es decir, en un nuevo nivel, debe comprender los requisitos del negocio y poder traducirlos en soluciones técnicas.
     
     De esta manera:
     
     
     1. El desarrollador intermedio comprende lo que está haciendo la aplicación. Esto le permite comprender mejor la tarea y, por lo tanto, evaluarla con mayor precisión e implementarla mejor. Si los requisitos no cubren completamente un escenario, un buen desarrollador prestará atención a esto en la etapa de planificación. Y no cuando la aplicación comienza a fallar en cualquier acción del usuario no estándar.
     2. El desarrollador intermedio está familiarizado con las plantillas y soluciones estándar cuando crea una aplicación en su campo, comprende por qué son necesarias y sabe cómo aplicarlas. La estandarización de las decisiones es de gran importancia en el desarrollo colectivo del código, ya que permite que una nueva persona descubra rápidamente qué es qué y minimiza la cantidad de errores. Comprender la estructura de una aplicación típica hace que la tarea de construirla desde cero sea bastante trivial, le permite hablar sobre los principios de la implementación adecuada y distinguir el código bueno del malo.
     3. El desarrollador intermedio entiende que ninguno funciona. Sabe cómo interactuar con otros miembros del equipo: puede discutir un momento difícil con un diseñador, aclarar requisitos incompletos con un analista de negocios o coordinar alguna solución técnica importante con el arquitecto del proyecto (si lo hay) y, por supuesto, posee las herramientas apropiadas para el desarrollo del equipo.
   • Senior:
     
     Senior es un desarrollador de alto nivel que ha visto mucho código, obtuvo un montón de conos y logró sacar las conclusiones correctas de esto. La tarea principal de Signor es tomar las decisiones tecnológicas correctas en el proyecto. Los "correctos" son aquellos que maximizan los beneficios comerciales y minimizan los costos. Un buen firmante no solo comprende lo que el equipo está desarrollando, sino que piensa qué tareas debe resolver la aplicación finalizada. Al desarrollar un sitio para la subasta, el firmante siempre se pregunta sobre la carga máxima e intenta prever intentos de escribir competitivamente en las tablas de la base de datos. Piensa de antemano en los cuellos de botella del sistema, en la posibilidad de escalarlo, recuerda las vulnerabilidades y los problemas causados ​​por el uso inadecuado de las herramientas.
     
     Tal especialista hace algo asombroso: resuelve problemas incluso antes de que aparezcan. Desde el exterior, se asemeja al don de la previsión. Pero si su proyecto vive de fuego en fuego, y constantemente tiene que tirar y reescribir piezas de código, estos son síntomas de que el proyecto no recibe suficiente atención del firmante.
5. Diseñador:
   
   Un diseñador es una persona que diseña. Lógicamente, ¿no es así?
   
   El trabajo del diseñador comienza mucho antes de que aparezca el primer píxel y termina mucho más tarde que el último.
   
   La mayoría de las personas están acostumbradas a creer que el diseño es en realidad un conjunto de imágenes, colores y fuentes que se transmiten a los diseñadores y programadores de diseño para hacer un producto. A veces, este enfoque funciona, pero con mayor frecuencia resulta ser un proyecto, lo que resulta vergonzoso agregar a la cartera.
   
   El hecho es que para resolver el problema no es suficiente hacer un dibujo. En el proceso, un buen diseñador pasa por 4 pasos. Aquí están:
   
   • Entendiendo el problema:
     
     El trabajo comienza con una comprensión del problema, como un teatro con una percha: hasta que renuncies a tu ropa exterior, no irás más allá. Si no profundiza en el problema, obtendrá un producto no viable.
   • Busca una solución:
     
     Cuando el problema está claro, es hora de buscar una solución. En términos establecidos, estos son todo tipo de bocetos y prototipos que ayudan a construir una visión preliminar del producto final.
   • Diseño:
     
     Esto es solo dibujar imágenes y seleccionar fuentes. Muchos diseñadores comienzan desde aquí e inmediatamente terminan el trabajo, y los resultados del trabajo de dichos diseñadores se pueden ver en grandes cantidades en Dribble o Behans.
   • Aprobación:
     
     Incluso si tiene una solución esbelta y elegante en la cabeza y en el papel, esto no significa que para el cliente se verá igual. Si omite esta etapa y simplemente le da al cliente las mejores prácticas, en el mejor de los casos, se rehacerán según su propio entendimiento. Lo que eventualmente quedará después de las ediciones del cliente será un poco como su trabajo.
   
   

Bueno, ahora, finalmente, estás familiarizado con todas las publicaciones en desarrollo de equipos. Aquí he enumerado solo las publicaciones relacionadas con la programación. Si consideramos el desarrollo de un producto de software como un proyecto comercial, entonces, por supuesto, se agregarán más roles, por ejemplo, contadores, comercializadores, etc.

Conclusión

Bueno, si lees hasta este punto, ¡felicidades, eres increíblemente genial! No, bueno, realmente, ¿tu cerebro aún no se ha hervido con tanta información? Espero que no

Por lo tanto, espero que nuestro artículo te haya ayudado a comprender todas las complejidades del desarrollo del equipo. Y no te quedan preguntas sobre este tema. Y cuando vengas a una compañía super-duper-irreal-cool-and-famosa y te contraten (si solo intentan no aceptar), no te confundirás y le mostrarás a tu jefe quién es el programador principal. O tal vez crearás tu propia empresa, quién sabe ;-)

Gracias por su atencion!

PS

El artículo fue preparado por estudiantes de la MSHP (Escuela de Programadores de Moscú) , basado en conferencias del curso de Programación Industrial.