👳🏿 👝 👨🏿‍⚖️ Desenvolvimento de Git e equipe (para manequins) 👧🏻 👉🏿 🙈

Co-autor do artigo: RicardoMilos

1. Introdução

Oi Se você veio aqui, está interessado na questão de como os programadores trabalham em equipe. Se antes você trabalhou apenas em solo, provavelmente parece que trabalhar em equipe é mais fácil, porque há mais mãos e isso significa que você pode fazer o trabalho muito mais rapidamente. Mas não é tão simples. Agora vamos nos familiarizar com quais ferramentas estão sendo desenvolvidas e o que está acontecendo dentro da equipe.

Git

Certamente você está familiarizado com esta situação:

Este é um problema de versão. Normalmente, esse problema ocorre em pessoas criativas que constantemente refazem tudo e alcançam o ideal. Infelizmente, também na programação, longe de sempre tudo acontece da primeira vez. Imagine uma situação: você descobriu como refazer um pedaço de código para que ele funcione um pouco mais rápido. Você reescreve, compila, executa e entende que agora o programa não funciona. Tudo está quebrado.

E aqui você percebe que não salvou a opção de trabalho, e o botão Z do teclado foi quebrado, para que você não possa nem enviar spam ctrl + z. Em um acesso de raiva, você atravessa o monitor com a mão direita bombeada. À noite, você chora, embrulhado em um cobertor e pensa na situação dos programadores.

Uma situação deplorável ... E para impedir que isso aconteça, você precisa salvar as versões do seu código.

Bem, os programadores são pessoas inteligentes e entenderam perfeitamente que armazenar todas as versões na forma de um monte de arquivos não é conveniente o máximo possível e que algo precisa ser inventado com urgência para facilitar o armazenamento de versões e resolver o problema de versão.

E aqui podemos traçar uma analogia com os jogos. Quase todos os projetos AAA têm um sistema de salvamento. Como um bom exemplo, o jogo Papers Please.

Da mesma forma, todos os sistemas de controle de versão funcionam.

O VCS (Version Control System) é um sistema que registra alterações em um arquivo ou conjunto de arquivos por um longo período, para que você possa retornar posteriormente para uma versão específica.

Classificação do LES:

Local
Centralizado
Distribuído

Já descobrimos a moeda forte local (esses são os mesmos montes dos mesmos arquivos)

Moeda forte centralizada

servidor central
todos os arquivos sob controle de versão
um número de clientes
receber cópias de arquivos

Exemplos:

CVS
Subversão
Perforce

Moeda forte distribuída

Clientes copiam completamente o repositório inteiro
O servidor central é responsável por fornecer a cópia principal
A sincronização pode ser
- Com servidor
- Com qualquer cliente

Exemplos:

Git
Mercurial
Bazar

Por que eu preciso do SLE

Armazenando todas as alterações do projeto
A capacidade de mudar "para qualquer estágio do projeto"
A capacidade de conduzir o desenvolvimento simultâneo da equipe
Capacidade de resolver problemas como o seguinte

Git

Git - Sistema de Controle de Versão Distribuído
Postado por Linus Torvalds
2005 - primeira versão

Instalação:
Linux: sudo apt install git
Windows / macOS: link

Os desenvolvedores usam:

GNU / Linux
Android
Vinho
Google
Crómio
jQuery
Php
MediaWiki
Qt

Conceitos básicos

Repositório (repositório, repositório) - um local onde a moeda forte armazena seus metadados e um banco de dados de objetos do projeto
Diretório de trabalho - uma cópia de uma versão específica de um projeto extraída do repositório
A área preparada ( área preparada ) - um arquivo de serviço contendo informações sobre o que deve ser incluído na próxima revisão do projeto
Revisão (revisão) - um objeto que armazena a alteração no estado do projeto (versão do projeto)
Confirmar - criando uma nova revisão

Configurar o GIT

Configuração de nome de usuário

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

As configurações são salvas em um arquivo .gitconfig oculto (no diretório inicial do usuário)

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

Criar Repositório

 mkdir first_git_repo cd first_git_repo git init

Status do arquivo do projeto

Fixed
o arquivo já está no repositório
Modificado
o arquivo tem conteúdo diferente do estado confirmado
Preparado
um arquivo modificado que será confirmado após a criação de uma nova revisão (esse arquivo se enquadra nessa revisão)

Trabalhar com código

Inicialização do Repositório
```
 git init 
```
Ou alternando para uma revisão específica
```
 git checkout _ 
```

Mudança no código do projeto: criando / excluindo / editando arquivos
Em qualquer IDE
Exibir status
git status
Adicionando arquivos modificados ao índice
(transição para o estado de estadiado)
git add ___
Criando uma revisão (do Staged para o Repo)
git commit -m ""

Resumir

Trabalhar com moeda forte

O que armazenar?

[+] Todos os arquivos de código fonte
[+] Todos os recursos necessários para a compilação
[+] configurações de compilação do projeto
[-] configurações do projeto no IDE
[-] arquivos compilados a partir da fonte
[-] arquivos executáveis

Excluir do índice

git rm _

Uma confirmação pode conter alterações em vários arquivos

Quando cometer?

Quando completei uma pequena tarefa
Se o problema for grande - divida em subpartes lógicas
O código deve estar operacional!

Ver Histórico

 git log git log --graph

Número da revisão = SHA-1 Change Hash

Mudar para auditoria

 git checkout sha1_hash git checkout _8__sha1

Ramos

Uma ramificação é uma sequência de confirmações na qual uma funcional é desenvolvida em paralelo

Ramo principal - mestre

Agências no GIT

Mostrar todas as ramificações existentes no repositório

git branch

Criar ramo

git branch

Mudar para ramificação

git checkout
Não deve haver alterações não salvas no momento.

Crie uma ramificação e mude para ela

git checkout -b

Mesclar ramificações

Mesclar ramificações - o processo de integração de alterações (confirmações) de uma ramificação para outra:

b1 - ramo ao qual adicionamos alterações
b2 - ramo do qual adicionamos alterações

 git checkout b1 git merge b2

Ver Histórico

Utilitários de janela:

gitg
gitk
gitx
gitKraken

Excluir ramificações

Excluir filial

git branch –d _

EXCLUIR uma ramificação

git branch –D _

Ou melhor, exclua a ramificação sem esperar que as confirmações sejam movidas para o mestre

Buffer de alteração não salvo

Ou "o que fazer se você precisar mudar para outro ramo e confirmar com antecedência?"

Gravar alterações no buffer temporário

git stash

Extraia essas alterações do buffer

git stash pop

Links úteis:

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

Desenvolvimento da equipe

Então, se você chegar a essa linha, significa que você tem pelo menos um pequeno acordo com o git (eu realmente espero que sim). Mas e o desenvolvimento da equipe? Vejamos esse problema com mais detalhes.

Um pequeno quebra-cabeça humorístico:

Dado:

N desenvolvedores
Locais de trabalho
Termos de Referência (TOR)
A internet

Pergunta:

Como realizar um projeto sem atrair a atenção dos enfermeiros?

A resposta é:

Equipe bem coordenada e trabalho duro

Hmm, o que é uma equipe? Como ela é?

Uma equipe é um pequeno número de pessoas:

com habilidades complementares (alguém está programando, alguém está projetando etc.)
aspirando a objetivos comuns (todos precisam cumprir a tarefa do cliente para obter completa satisfação pessoal)
compartilhando a responsabilidade de atingir o objetivo do projeto (se de repente um dos membros da equipe tiver dificuldades com seu TK pessoal, seus colegas de equipe sempre o ajudarão (isso não deve ser abusado, caso contrário você será simplesmente desnecessário para a equipe)).

Uma observação muito importante: na equipe, você deve se sentir absolutamente à vontade e tentar se dar bem com toda a equipe, caso contrário, tudo pode dar errado.

Então, agora você entende o que é uma equipe. Mas a próxima pergunta que surge em sua cabeça (sim, sim, os autores deste artigo podem ler mentes): “E quem é responsável por quê na equipe? Todo mundo tem seu próprio lugar? Ou todo mundo está fazendo o que quer?

Naturalmente, cada participante da equipe tem seu próprio papel e suas próprias tarefas. Caso contrário, em vez de desenvolver um produto, haveria caos. Vejamos as funções na programação de comandos:

Líder da equipe:

O líder da equipe é um cruzamento entre um gerente de projeto e um desenvolvedor qualificado.

Existem dois papéis principais em projetos: gerencial - PM e técnico - arquiteto de sistema. Timlid cumpre parcialmente as duas funções, mas o foco de suas responsabilidades está no gerenciamento (a ênfase na parte técnica é o líder técnico).

“Líder da equipe nº 1: cuidando da sua equipe. A equipe deve se sentir confortável no ambiente de trabalho e estar bem motivada. Além disso, o líder da equipe também fornece crescimento profissional e de carreira para seus filhos, mantém regularmente discussões sobre o tópico em que as pessoas estão interessadas em se desenvolver e as ajuda nisso. ”

A função gerencial do líder da equipe inclui responsabilidades como gerenciamento, alocação e delegação de tarefas, todos os tipos de avaliações e agendamento, monitoramento do status do projeto, além de reuniões, comunicação com o cliente, gerência e todos os membros da equipe (desenvolvedores, testadores, gerentes).

Sob o papel técnico: participação na redação da documentação técnica, seleção de tecnologias para o projeto, desenvolvimento da arquitetura, P&D, revisão de código, orientação de juniores, realização de entrevistas técnicas, envolvimento competente de novos membros da equipe no processo de trabalho, responsabilidade pela parte técnica do projeto.

Um dia de trabalho típico da Timlid inclui:
- consideração de novas tarefas e sua distribuição
- stand-up com uma equipe
- comícios
- programação
- questões arquitetônicas
- revisão de código
Gerente de projeto:

O gerente de projetos é um especialista cuja principal tarefa é gerenciar o projeto como um todo: projetar e priorizar, agendar tarefas, monitorar, comunicar e resolver problemas rapidamente.

A principal responsabilidade e responsabilidade da PM é levar a ideia do cliente a bom termo, usando os recursos existentes. Como parte dessa tarefa, o PM precisa criar um plano de desenvolvimento, organizar uma equipe, configurar um fluxo de trabalho do projeto, fornecer feedback entre as equipes e o cliente, eliminar a interferência nas equipes, controlar a qualidade e a entrega do produto no prazo.

As tarefas de PM podem ser classificadas como táticas e estratégicas. Tático - esta é a solução para os problemas cotidianos do projeto, a remoção de obstáculos da equipe. Os estratégicos são coordenar o objetivo geral do projeto, o caminho para ele e a velocidade do movimento.

"A principal declaração de objetivo para o PM é:" Precisamos que isso funcione ", o que implica que a equipe fornecerá o resultado em um período razoável de tempo com um nível razoável de qualidade."
Testador:

Um testador é um especialista que está envolvido no teste de um produto de software para identificar erros em seu trabalho e sua correção subseqüente.

As principais funções do testador:
- Controle de qualidade de produtos desenvolvidos.
- Identificação e análise de erros e problemas encontrados pelos usuários ao trabalhar com produtos de software.
- Desenvolvimento de autotestes e sua execução regular.
- Testando o desenvolvimento de scripts.
- Defeitos de documentação encontrados.
Desenvolvedores:
- Junior:
  Junior é desenvolvedor iniciante.
  
  Depois de concluir um estágio, uma pessoa se transforma em um junho de pleno direito. O principal requisito para isso é a capacidade de executar tarefas técnicas de forma independente. Se um projeto é construído em arquitetura, ele deve implementar imediatamente outra parte da lógica típica do aplicativo. Embora Junior possa cometer erros de tempos em tempos, não entenda as nuances, discuta os planos de implementação com o líder da equipe ou verifique o código final com ele.
  
  Você precisa entender que, para as tarefas que o signor resolverá em dez minutos, o mês de junho pode precisar de três abordagens a cada hora e, no processo, o código precisará ser completamente reescrito, gastando muita energia adicional. É importante não ter medo disso e sentir o equilíbrio: quando empurrar, tentar resolver o problema sozinho e quando, pelo contrário, parar de bater a testa na parede, queimar o tempo do projeto e pedir ajuda. Justificar sua falta de desempenho com a frase "Eu ainda sou junho" é uma má ideia.
- Médio:
  
  Middle - um desenvolvedor de nível intermediário.
  
  O principal requisito para um desenvolvedor intermediário é a capacidade de executar independentemente as tarefas atribuídas a ele. Muito parecido com o que foi escrito no parágrafo anterior, certo? No entanto, há uma ressalva importante - a palavra "técnico" está faltando aqui. Ou seja, em um novo nível, você precisa entender os requisitos da empresa e poder traduzi-los em soluções técnicas.
  
  Desta forma:
  1. O desenvolvedor intermediário entende o que o aplicativo está fazendo. Isso permite que você entenda melhor a tarefa e, portanto, avalie-a com mais precisão e implementá-la melhor. Se os requisitos não cobrirem completamente um cenário, um bom desenvolvedor prestará atenção a isso no estágio de planejamento. E não quando o aplicativo começa a falhar com qualquer ação não padrão do usuário.
  2. O desenvolvedor intermediário está familiarizado com modelos e soluções padrão ao criar um aplicativo em seu campo, entende por que eles são necessários e sabe como aplicá-los. A padronização das decisões é de grande importância no desenvolvimento coletivo do código, pois permite que uma nova pessoa descubra rapidamente o que é o que e minimiza o número de erros. O entendimento da estrutura de um aplicativo típico torna a tarefa de construí-lo do zero bastante trivial, permite que você fale sobre os princípios de implementação adequada e distinga código bom de ruim.
  3. O desenvolvedor intermediário entende que nem um funciona. Ele sabe como interagir com outros membros da equipe: ele pode discutir um momento difícil com um designer, esclarecer requisitos incompletos com um analista de negócios ou coordenar alguma solução técnica importante com o arquiteto do projeto (se houver) e, é claro, possui as ferramentas de desenvolvimento coletivo apropriadas.
- Senior:
  
  Senior é um desenvolvedor de alto nível que viu muito código, obteve vários cones e conseguiu tirar as conclusões corretas disso. A principal tarefa do signor é tomar as decisões tecnológicas corretas no projeto. Os “corretos” são aqueles que maximizam os benefícios dos negócios e minimizam os custos. Um bom signor não apenas entende o que a equipe está desenvolvendo, mas também pensa em quais tarefas o aplicativo finalizado deve resolver. Ao desenvolver um site para o leilão, o signor sempre se pergunta sobre o pico de carga e tenta prever tentativas de gravação competitiva nas tabelas do banco de dados. Ele pensa antecipadamente nos gargalos do sistema, na possibilidade de dimensioná-lo, lembra as vulnerabilidades e os problemas causados pelo uso inadequado de ferramentas.
  
  Esse especialista faz uma coisa incrível - resolve os problemas antes mesmo que eles apareçam. Do lado de fora, assemelha-se ao dom da previsão. Mas se o seu projeto vive de fogo em fogo, e você constantemente precisa jogar fora e reescrever trechos de código - esses são sintomas de que o projeto recebe atenção signatária insuficiente.
Designer:

Um designer é uma pessoa que projeta. Logicamente, não é?

O trabalho do designer começa muito antes do primeiro pixel aparecer e termina muito depois do último.

A maioria das pessoas está acostumada a acreditar que o design é na verdade um conjunto de imagens, cores e fontes que são repassadas aos designers e programadores de layout para produzir um produto. Às vezes, essa abordagem funciona, mas com mais frequência acaba sendo um projeto, que é embaraçoso para ser adicionado ao portfólio.

O fato é que, para resolver o problema, não basta desenhar uma imagem. No processo, um bom designer passa por 4 etapas. Aqui estão elas:
- Entendendo o problema:
  
  O trabalho começa com uma compreensão do problema, como um teatro com um cabide: até que você desista de sua roupa exterior, você não irá mais longe. Se você não se aprofundar no problema, receberá um produto inviável.
- Procure uma solução:
  
  Quando o problema estiver claro, é hora de procurar uma solução. Em termos estabelecidos, esses são todos os tipos de esboços e protótipos que ajudam a construir uma visão preliminar do produto final.
- Design:
  
  Isso é apenas desenhar imagens e selecionar fontes. Muitos designers começam aqui e terminam imediatamente o trabalho, e os resultados do trabalho desses designers podem ser vistos em grande número no Dribble ou Behans.
- Aprovação:
  
  Mesmo se você tiver uma solução esbelta e elegante em sua cabeça e no papel, isso não significa que, para o cliente, ela terá a mesma aparência. Se você omitir esse estágio e simplesmente fornecer ao cliente as melhores práticas, na melhor das hipóteses, elas serão refeitas de acordo com seu próprio entendimento. O que eventualmente permanecerá após as edições do cliente será um pouco parecido com o seu trabalho.

Bem, agora, finalmente, você está familiarizado com todas as postagens no desenvolvimento de equipes. Aqui, listei apenas os posts relacionados à programação. Se considerarmos o desenvolvimento de um produto de software como um projeto comercial, é claro que serão adicionadas mais funções, por exemplo, contadores, profissionais de marketing etc.

Conclusão

Bem, se você ler até este ponto - parabéns, você é incrivelmente legal! Não, bem, sério, seu cérebro ainda não fervia com tanta informação? Espero que não.

Espero que nosso artigo tenha ajudado você a entender todos os meandros do desenvolvimento de equipes. E você não tem mais dúvidas sobre este tópico. E quando você chegar a uma empresa super-duper-irreal-legal-e-famosa e você for contratado (se eles tentarem não aceitar), não ficará confuso e mostrará ao seu chefe quem é o principal programador. Ou talvez você crie sua própria empresa, quem sabe ;-)

Obrigado pela atenção!

PS

O artigo foi preparado por estudantes da MSHP (Escola de Programadores de Moscou) , com base em palestras do curso de Programação Industrial.

Desenvolvimento de Git e equipe (para manequins)