De um tradutor: hoje estamos
publicando um artigo para você pelo experiente testador de gamedev Richard Taylor. O artigo será útil para desenvolvedores iniciantes e experientes - há definitivamente algo a discutir aqui.
Eu criei muitos jogos. Normalmente, o estágio final de desenvolvimento é muito doloroso. Afinal, é no final que encontramos bugs, e só depois podemos trazer brilho ao produto. A situação piora quando o desenvolvedor tem um tempo mínimo para concluir o projeto. Você precisa trabalhar rapidamente e, nesse caso, os erros são convidados frequentes. Como posso lidar com eles? É muito simples: cometer menos erros, isso é tudo (essa é a ironia do autor - nota do tradutor).
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".
Reduza o número de bugs
Como todos os bugs estão no código, é provavelmente suficiente pedir à equipe de desenvolvimento que cometa menos erros?
Se você é engraçado neste lugar, não vou me surpreender. E realmente, porque ninguém (bem, ou quase ninguém) os faz por vontade própria. Então, o que você pode oferecer à equipe para cometer menos erros no código, para que não haja bugs?
Começamos um novo projeto. Etapa 1 - Não repita erros anteriores
Nossa equipe trabalhou em vários projetos AAA. Antes de iniciar um deles, decidimos debater sobre o tópico "Como cometer o número mínimo de erros". Nenhum de nós queria passar os últimos dois meses trabalhando em um projeto procurando bugs e limpando o código. Uma das principais tarefas é a distribuição de responsabilidades e responsabilidades. Cada tipo de trabalho foi designado como sênior.
O primeiro passo é decidir por que tudo isso é necessário. O "porquê" do nível superior é explicado simplesmente: queremos reduzir a quantidade de tempo necessária para eliminar bugs, otimizar custos e melhorar a qualidade geral do projeto.
Trata-se de liberar tempo para a execução de tarefas interessantes, aquelas que permitem que você acorde alegremente pela manhã e assuma imediatamente a implementação da tarefa. Foi isso que fez de todos nós desenvolvedores - a oportunidade de usar nosso tempo para coisas realmente legais!
A propósito, mesmo que haja uma tarefa clara para criar menos bugs, é tão geral que pode ser simplesmente sem sentido. Esta é uma declaração de intenções que precisa ser esclarecida e dividida em uma série de atribuições claras, endereçadas a membros da equipe.
Ao responder à pergunta de como fazer isso, é necessário seguir o básico do método científico: observação, hipótese, teste, repetição.
Observação
CategorizaçãoAbra o banco de dados de erros do seu projeto mais recente e visualize-o. Existem muitas variedades de bugs, então é só dizer: menos erros é simplesmente inútil.
Para entender melhor o problema, você precisa determinar os detalhes. Antes de tudo, é necessário reduzir o número desses problemas, cuja detecção e solução exigem um avanço de tempo.
AnáliseApós compilar uma lista dos bugs que consomem mais tempo, o próximo passo é uma tentativa de encontrar um terreno comum nesses erros, além de entender o motivo de sua aparência. Analise e interprete!
Causa do problemaNo final, criamos vários modelos para procurar bugs específicos, o que possibilitou entender por que a pesquisa e a eliminação deles levam tanto tempo. Depois disso, estávamos prontos para acessar o código-fonte para encontrar a causa raiz do problema.
Trabalhando com especialistas técnicos, descobrimos mais alterações de correção. Em seguida, compilamos novas listas de sistemas, arquivos e linhas de código associadas aos principais erros. No final, fizemos uma lista das alterações de código necessárias que poderiam ser discutidas com a equipe de desenvolvimento.
Nós dissemos a você!Depois tivemos uma reunião com os programadores para discutir nossas descobertas. Como se viu, os caras sabiam sobre a maioria das áreas problemáticas no código. Mas se sim, qual era o sentido de ter uma reunião?
Resposta: conseguimos traçar um paralelo entre locais específicos no código e as perdas de tempo associadas a esses problemas. E isso, por sua vez, possibilitou avaliar objetivamente qualquer proposta de manutenção de código.
Assim, revisamos seções do código que poderiam ser consideradas aceitáveis incorretas. Quando os avaliamos com nossas melhores práticas, descobrimos que precisávamos de refatoração. Ao mesmo tempo, a equipe de engenharia o abandonou anteriormente porque "há muito trabalho" ou "é simplesmente impossível".
De fato, muitos problemas eram sistêmicos. Muitos aspectos "invisíveis" levaram a uma cadeia de eventos que causou o aparecimento de um erro. A propósito, as causas dos problemas eram tão sistêmicas que o projeto teve que começar do zero.
Como resultado, acumulamos resultados suficientes de observações e análises empíricas para formar hipóteses. Toda a equipe participou desse processo.
Hipóteses
Hipótese 1. É provável que padrões de codificação específicos levem ao aparecimento de erros em um grande projeto de software.
Hipótese 2. O tempo necessário para corrigir erros em um projeto pode ser reduzido, evitando os padrões de comportamento definidos na primeira hipótese.
Vamos decidir o que é um grande projeto. São cerca de 25 programadores, 12 meses de desenvolvimento. As seguintes afirmações são verdadeiras para ele:
R. Qualquer código permanecerá tempo suficiente, portanto, o custo de manutenção excederá o custo do próprio desenvolvimento.
B. A complexidade de conectar sistemas de projetos individuais é maior que a complexidade de um sistema específico.
Por que isso é tão importante? Em pequenos projetos, você pode lidar com quase tudo, aqui a estrutura do programa não é tão importante. O código está tudo à sua disposição.
Se o projeto for grande, tudo muda. Você pode trabalhar com um código cuja finalidade você não entende; talvez nem saiba a que parte do projeto um site específico pertence.
Após nossa discussão, obtivemos esta declaração de resultados: “Os dados mostram que esses padrões de programação específicos eram um fator comum associado a vários bugs / problemas. Acreditamos que, evitando esses padrões, podemos reduzir o tempo necessário para corrigir erros e, ao mesmo tempo, melhorar a qualidade. ”
Agora começamos a implementação prática.
Teste
Ao criar um novo projeto, você deve evitar padrões de erros identificados. Nós tínhamos:
- Sobrecarga do operador e nomeação incorreta.
- Auto, características polimórficas e negligência do tipo de segurança.
- Aumentar a complexidade do código, por exemplo, injetando dependências e retornos de chamada.
- Utilizando mutexes, semáforos e similares no código de alto nível.
O que vem a seguir?
E então tivemos a oportunidade de iniciar um novo projeto, o desenvolvimento de um novo jogo. Conseguimos criar um mecanismo de jogo do zero e concluir tudo dentro do prazo, com uma equipe relativamente pequena de programadores. Havia poucos bugs, mas o código acabou sendo bom. Ao mesmo tempo, demorou um pouco para atendê-lo.
Tudo isso se tornou possível porque não usamos padrões problemáticos, como se eles não existissem mais. Chegamos até ao mantra "Complicar a aparência de um erro".
Toda a equipe ficou satisfeita com esses resultados, ficou mais interessante trabalhar, porque, novamente, foi possível dedicar tempo ao que você gosta.
A Skillbox recomenda: