De um tradutor: publicamos para você
um artigo do desenvolvedor Jack Finlay. Jack fala sobre seu próprio caso - uma tentativa de organizar o trabalho como uma equipe de juniores, onde todos são iguais e não há gerente técnico. Este artigo será útil para programadores iniciantes.
Alguns projetos podem parar e terminar em nada por várias razões. Orientação técnica é algo que geralmente falta. Esse problema pode levar a um fiasco. Uma vez aconteceu com um projeto em que participei.
A Skillbox recomenda: Curso prático de dois anos "Eu sou um desenvolvedor Web PRO" .
Lembramos que: para todos os leitores de "Habr" - um desconto de 10.000 rublos ao se inscrever em qualquer curso Skillbox usando o código promocional "Habr".
O tempo pode te ensinar muito. Infelizmente, adquirimos experiência como resultado de trabalhar não apenas em projetos bem-sucedidos, mas também em projetos malsucedidos.
Experiência pessoal e liderança
Mais precisamente, a falta dela. Não havia desenvolvedor líder ou desenvolvedor sênior em nosso projeto. Em princípio, já estava claro o que aconteceria com o nosso trabalho, mas naquela época não entendíamos isso.
A equipe não tinha experiência. Quase todos nós éramos estudantes e não havia ninguém que pudesse nos liderar. Então não nos pareceu necessário.
No decorrer de um verão, o número de membros da equipe aumentou cinco vezes. Um problema? Todos eram do mesmo nível profissional. Todo mundo carecia de experiência. Nós nos dividimos em vários grupos, cada um dos quais foi responsável por alguma coisa.
Além disso, quase todos os participantes do projeto eram boas pessoas no comando. Mas este foi o nosso primeiro projeto comercial. Minha equipe era muito boa, trabalhamos perfeitamente, mas o resultado foi um fracasso.
ToolkitUm componente-chave do trabalho de qualquer profissional são as ferramentas. Sem as ferramentas certas, um fluxo de processo normal é impossível. Uma boa equipe geralmente tem um líder que sabe quem precisa de quais ferramentas e onde obtê-las.
Bases de dadosNeste projeto, tivemos acesso a um banco de dados compartilhado hospedado em uma máquina virtual, uma das mais lentas que foram obtidas. Naturalmente, experimentamos todos os "prazeres" desse trabalho: perda de dados, queda de tabelas, ações simultâneas nos mesmos elementos. Tudo isso atrasou nosso trabalho.
Não foi possível reproduzir o banco de dados localmente ou na nuvem sem executar a operação de backup e restauração. Não havia como obter um banco de dados “limpo” no mesmo estado em que gostaríamos de implantá-lo em ambientes diferentes. O banco de dados só pode ser criado como um clone do banco de dados do nosso servidor.
Mas o projeto funcionou apenas com o banco de dados, localizado no servidor de produção. Isso significava que não podíamos testar o banco de dados e o projeto dependendo localmente. Várias vezes surgiu uma situação quando tivemos que reverter a base para um certo ponto, porque à noite alguém a destruía com ações descuidadas. Isso impediu muito o processo de desenvolvimento.
A migração e atualização do banco de dados foram feitas manualmente. Isso significava ... sim, estávamos perdendo tempo novamente.
Agora parece óbvio que os desenvolvedores devem ter bancos de dados locais em suas máquinas. Além disso, você deve usar ferramentas de migração automatizadas. Isso dá aos desenvolvedores a liberdade e espaço para manobrar em determinadas situações.
DesempenhoOs desenvolvedores precisam de alto desempenho em máquinas locais e no servidor em que o projeto está sendo testado. Mas, como tínhamos ferramentas lentas, não conseguimos nem sonhar com isso.
Muitos tinham dispositivos extremamente lentos que eram usados por muitos anos. Teclados, trackpads - tudo isso trazia a marca do tempo.
Os servidores também estavam lentos, como mencionei acima. Como resultado, todo o processo de desenvolvimento ficou lento. Os testes também progrediram lentamente.
A conclusão é simples, no estilo da identidade corporativa, é fornecer ao desenvolvedor o equipamento e os recursos necessários para o processo normal de desenvolvimento.
Controle de origem
Geralmente era um caos. Usamos um sistema de controle de origem corporativo, mas o problema não estava no software. Simplesmente não havia estratégia. Equipes de desenvolvimento separadas trabalharam cada uma "em seu próprio pântano", e não concordamos em quando fundiríamos brunches individuais. O resultado foi o que aconteceu: conflitos, conflitos durante a fusão em todos os lugares. Tive que gastar muito tempo resolvendo problemas e sincronização adequada.
Integração e implantaçãoGeralmente, não possuímos soluções de CI / CD. A implantação foi simples: copiamos os recursos da pasta interna e colamos no servidor usando a Área de Trabalho Remota. Se você fez algo semelhante, pode entender minha dor.
Para aqueles que não encontraram um problema: se você tiver algo diferente dos arquivos necessários no buffer, isso matará o upload de arquivos para o servidor. Se alguém da equipe ingressar no servidor para fazer upload de arquivos, você terá problemas. Além disso, alguns arquivos podem ser transferidos corrompidos.
Meu conselho é escolher uma solução de CI / CD para você.
Controle de qualidade
Outro elemento importante do processo de desenvolvimento é o controle de qualidade.
Revisão por paresEste trabalho foi realizado conosco e os membros da equipe se reuniram e analisaram o trabalho realizado. E às vezes nem olhamos para o código, então um grande número de momentos se passaram. Outro problema foi que não tínhamos experiência, o que significa entender o que é um bom código. Não foi possível isolar imediatamente os erros no código que um desenvolvedor experiente vê imediatamente.
Se a equipe tivesse um desenvolvedor sênior, ele poderia nos informar imediatamente onde estão os problemas e como lidar com eles. Mas ele não estava lá, trabalhamos de forma independente.
TestadoresTambém não tínhamos. Realizamos os testes por conta própria. Novamente sem experiência. Como resultado, gastamos um tempo precioso que gastamos na captura de bugs e na eliminação deles.
Se você deseja um bom código, precisa de testadores e profissionais. Os desenvolvedores nem sempre lidam com o problema dos testes de software.
Qualidade do código
Muitos de nós, no início da jornada, somos representantes da cultura “copiar-passado”. Isso significa que o desenvolvedor procura as soluções necessárias para o projeto no Stackoverflow e insere a peça encontrada sem uma pontada de consciência. O resultado não é um código muito bom, que é praticamente ilegível e que os desenvolvedores acham difícil de explicar completamente. Mesmo a pessoa que copiou um site específico geralmente não consegue descobrir seu trabalho.
Só posso aconselhar uma coisa: se você copiar o código, deverá entendê-lo completamente. Sem isso, um projeto normal não pode ser realizado.
Código de espagueteUma má compreensão da arquitetura do projeto levou ao caos completo. O código do espaguete é uma descrição simples do que aconteceu no final.
Algumas seções passaram por mãos diferentes, de diferentes desenvolvedores, cada uma das quais adicionou algo diferente. O código final do projeto era um conjunto de idéias e "muletas".
Não tínhamos um sistema de injeção de dependência e não usamos nenhum padrão de design comum. Isso levou a muitos códigos ruins que começaram a "apodrecer".
O que posso dizer? A legibilidade do código é tão importante quanto a operação adequada, e essas duas coisas andam de mãos dadas. Um estilo claro e consistente e um código consistente fornecem o resultado mais eficaz.
Conclusão
Muitos problemas surgiram devido à nossa falta de experiência. Nós simplesmente não sabíamos como trabalhar no projeto. Não foi possível implementar adequadamente o ambiente. Não tínhamos as ferramentas e tecnologias necessárias.
Um bom líder de equipe resolveria todos esses problemas. Ele teria previsto muito com antecedência.
A propósito, o projeto em si não foi o pior do que poderia acontecer. Conheci muitos futuros colegas com quem me comunico até agora. Tem a experiência necessária para trabalhar como profissional. E percebi que, sem uma liderança adequada, mesmo a equipe mais capaz não realiza todo o seu potencial. Nunca.
A Skillbox recomenda: