Oi Meu nome é Nikolai Izhikov. Neste post, quero falar sobre um importante elemento de interação que encontramos no processo de desenvolvimento de software, especialmente em código aberto. Esta é uma explicação passo a passo e uma revisão de código.
Darei conselhos
prejudiciais sobre como criar meu recurso e integrá-lo no assistente de projeto de código aberto no contexto de diferenças culturais, temporais, conceituais e outras diferenças entre os membros da comunidade. Geralmente, essa é uma pergunta complicada, especialmente para aqueles que estão começando no código aberto.
Vamos começar com uma pequena introdução. Ao se comunicar com as pessoas, especialmente no bate-papo ou pelo correio, especialmente em inglês, sempre lembre-se de que sua mensagem pode ser percebida de maneira completamente diferente da esperada. Quem lerá a carta é desconhecido. Ele pode ser hindu, inglês ou apenas uma pessoa com sono. Sempre haverá diferenças no entendimento de palavras específicas e, sem entrar em detalhes técnicos, mostrarei como minimizá-las.
Atenção: a história contém sarcasmo.
Dicas ruins para um colaborador
Não discuta um novo recurso com ninguém
Se você deseja implementar um novo recurso, em nenhum caso discuta sua revisão com ninguém. Alguém pode escutar e fazer isso antes de você! Ou, depois de ouvir os detalhes, eles podem dizer que você não entendeu algo - para criticar sua ideia. A crítica dói muito. Talvez um recurso como o seu já tenha sido discutido e você precise de outro ... Em geral, nunca diga a ninguém o que você deseja fazer. Nunca.
Nunca faça documentação técnica
Committers e caras experientes da comunidade gostam muito de entender o código do patch recebido. Portanto, em nenhum caso, não faça documentação técnica. Discussão sobre Wiki, Jira, lista de e-mails - tudo isso é um absurdo completo. E a besteira não é para você!
Quando você envia um patch para [+5000, -3500] com uma descrição dos aprimoramentos na forma de "aprimoramentos dos métodos de fábrica e alguns outros aprimoramentos", todos descobrirão eles mesmos e, ao mesmo tempo, entenderão como você é bom.
Nunca execute testes
Qualquer teste é perigoso porque pode quebrar alguma coisa. Se você ainda conseguiu executar os testes, não mostre seus resultados. Erros nos resultados podem levar à rejeição do patch! E definitivamente nunca escreva novos testes. Executar Tudo será mais longo, o consumo da CPU aumentará. De qualquer forma, bons desenvolvedores escrevem código sem erros - qualquer colega experiente examinará suas correções e entenderá que não há erros.
Nunca Leia Como Fazer
Entrando em um projeto de código-fonte aberto, nunca leia nenhum manual de instruções. Eles são escritos para tolos, certo?
Crie seu código à sua maneira. Caso contrário, como todos entenderão que você é um bom desenvolvedor e uma pessoa criativa versátil com um senso de beleza desenvolvido?
Envie correções conforme for conveniente para você. Por exemplo, o projeto está vinculado à infraestrutura do GitHub - envie-o como é enviado ao kernel do linux, diretamente na carta. Você pode até não no anexo, mas diretamente no texto. Afinal, Linus Torvalds não aconselha mal! E se o projeto for adotado de maneira diferente, esses são problemas do projeto.
Sinta-se livre para complicar a API pública
Ao desenvolver a nova API pública, tente torná-la a mais abstrata e complexa possível. Qualquer dúvida do usuário sobre o comportamento não óbvio da API sempre pode ser respondida: “Você não leu o manual? Página 42, tudo está escrito claramente! Leia de novo! Em projetos sérios, tudo deve ser complicado. Temos um projeto sério?
Não aconselhe ou fale sobre problemas
Não consulte ninguém e não conte a ninguém sobre os problemas encontrados no desenvolvimento. É muito mais divertido entender uma coisa. De qualquer forma, bons desenvolvedores sempre obtêm sucesso na primeira vez, não têm problemas. Se outras pessoas descobrirem seus problemas, elas se tornarão mais inteligentes e escreverão um código mais rapidamente que você. Isso não deve ser permitido. E, de fato, não é habitual falar sobre seus problemas.
As limitações da decisão final também não merecem destaque. Afinal, a solução pode ser solicitada a finalizar. Quem se importa com restrições? Quando um usuário começa a apresentar seu produto e encontra restrições, ele fica mais interessado e mais divertido. Ele virá até você e solicitará que você termine. E até este ponto, em nenhum caso, não conte a ele sobre as restrições - e se ele decidir não implementar nada?
Um revisor realmente bom encontrará tudo e solicitará detalhes. Em nenhum caso, não conte a ele nada.
Se você tiver dúvidas, escreva para a lista dev
Esta dica complementa a anterior. É melhor não apenas não contar nada a ninguém, mas também fazer perguntas principalmente na lista de desenvolvedores.
Aqui estão exemplos de perguntas que todo mundo gosta de responder. Se você escrever algum tipo de teste, não deixe de perguntar: "Você precisa verificar se há nulos nesta coleção?". Você não precisa descobrir por conta própria, sempre pode perguntar na planilha do desenvolvedor. Afinal, há muitas pessoas que estão apenas esperando para fazer essa pergunta. Eles procurarão responder mais rapidamente.
"Como faço a tarefa?" - Outra ótima pergunta. Em nenhum caso, não indique detalhes: o ID da tarefa será suficiente. Todos que precisarem verão por si mesmos.
"Qual estrutura usar?" - também é uma pergunta muito boa. É sempre interessante responder e você pode debater.
Corrija todos os problemas do projeto em uma solicitação pull
Esta é a minha dica favorita. Corrija todos os problemas do projeto em uma solicitação pull, especialmente se você estiver trabalhando na empresa. Havia apenas tolos no projeto antes de você, eles escreveram o código mal. E você escreve bem. Portanto, você simplesmente deve:
- Refatore todo o código existente que você não entende;
- renomeie todas, na sua opinião, variáveis nomeadas incorretamente;
- corrija todos os comentários javadoc existentes.
Em geral, você pode tirar e tirar algumas classes, fábricas etc., fazer outras transformações para que o código seja melhor. Isso parecerá especialmente impressionante em áreas que não são relevantes para sua tarefa. Para que você possa revelar mais plenamente seu potencial. Para a glória do POO! Amém!
Solicite uma revisão de código com antecedência
Quando você executa uma tarefa e envia uma solicitação para revisão de código, o processo pode demorar um pouco. Todos os especialistas geralmente estão ocupados. Aproveite o truque: quando sua tarefa, como parece para você, terminar em breve, solicite uma revisão com antecedência. Afinal, eles não parecerão imediatamente - até que suas mãos cheguem até você, você pode simplesmente terminar tudo.
Bem, se o revisor repentinamente tiver tempo, embora a tarefa ainda não tenha sido concluída, ele teve azar. Explique a situação, diga que amanhã tudo estará pronto. Dessa forma, você acelera o processo (pelo menos por revisão) e se mescla mais rapidamente.
Cansado da tarefa - abandone-o
Todo mundo que trabalha em código aberto tem muito tempo. Não há necessidade de terminar nada. Revisão de código aprovada, comentários recebidos. E por que editar e trazer algo para mesclar? Pegue o quebra-cabeça a seguir e faça-o. Este é o caminho para o sucesso! O revisor tem muito tempo e o próximo patch ficará sem resultado!
O revisor é seu inimigo
E o que mais para nomear a pessoa que fica entre você e o commit no mestre? A crítica ao código é uma crítica a você pessoalmente! Quem ele pensa que é? Na comunicação pessoal, bombardeie o máximo possível! Caso contrário, como o revisor sabe que você se importa? Esta é a regra básica do desenvolvimento!
Eu recomendo este conselho no desenvolvimento diário. Isso ajuda a alcançar o resultado e fazê-lo corretamente.
Mau conselho para o revisor
Não automatize verificações de rotina
Se você atingiu o nível no projeto quando as correções para revisão já estão sendo enviadas a você, em nenhum caso, não automatize as verificações de rotina! É muito mais divertido passar alguns ciclos de revisão na solução de problemas e discussão:
- formatação de código;
- nomeação de variáveis;
- verifica se essas variáveis estão marcadas como finais, que podem ser marcadas por elas;
- ... e tudo mais.
Em nenhum caso as verificações de rotina devem ser automatizadas. Sim, e testes para não levar a nada.
Nunca revele todas as regras do jogo até o fim.
Para estar à frente, você sempre precisa manter um par de ases na manga. Não conte a ninguém sobre a necessidade de compatibilidade com versões anteriores. É melhor dizer logo antes do commit: "Aqui, de acordo com nossas regras, a compatibilidade com versões anteriores deve ser garantida. Por favor, corrija. Isso será especialmente eficaz se você já tiver revisado cinco vezes. No sexto, ainda se pode dizer: "Eu não sou especialista, então você precisa aguardar a revisão do Sr. X, que procurará novamente".
Tais comentários, especialmente na fase final da revisão, sempre adicionam motivação aos colaboradores.
Emoções, autoridades e não, obrigado
Essa dica se sobrepõe à mais recente dica de colaborador. Escreva comentários sobre a solicitação pull o mais emocionalmente possível. Se algum lugar não estiver marcado como nulo ou a variável não tiver esse nome, adicione paixão aos seus comentários. Deixe-os ver que você se importa.
Se surgir uma disputa, em nenhum caso forneça argumentos técnicos. Com argumentos técnicos, pode acontecer que você esteja errado. Consulte as autoridades - este é o melhor argumento da disputa, você sempre vencerá.
Se alguém passou por sua análise, você nunca deve agradecer. Ainda assim eles querem se comprometer com o código aberto! Em nenhum caso, não tem que agradecer, e assim eles virão novamente!
Agora, falando sério: o que você deve pensar ao preparar e conduzir uma revisão de código?
Espero que todos tenham entendido como conduzir e passar na revisão? Em cada uma dessas dicas, além do sarcasmo, há dores que geralmente ocorrem na prática.
Serei o capitão da Evidence e direi o que você realmente precisa pensar ao preparar e conduzir uma revisão de código. As considerações se aplicam ainda àquele que desenvolve o recurso e àquele que o revisará. Ainda assim, esses são dois lados da mesma moeda.
O consenso na comunicação é, primeiramente, alcançável e, em segundo lugar, é necessário que o projeto avance. Atualmente, poucos produtos podem ser desenvolvidos sozinhos. Geralmente isso é trabalho em equipe.
Use o bom senso
Este é o conselho mais importante. Use o bom senso, ele dirige. Parece-me que este conselho se aplica a todas as situações da vida. Se você estiver fazendo algo, considere se isso atende à regra simples do senso comum?
Suponha ...
Isso é sobre cultura. Estive em várias grandes comunidades de código aberto. Não sei se isso faz parte da mentalidade russa, mas muitas vezes uma pessoa que pode ser vista como chefe é simultaneamente vista como uma pessoa que acidentalmente se encaixou. Acredita-se que ele te queira mal, por padrão, há dúvidas sobre seu profissionalismo. Portanto, é muito importante em qualquer trabalho assumir pelo menos por um segundo que:
- O revisor (colaborador, seu chefe ou colega) não é seu inimigo . Ele não quer que você seja ruim. Essa é uma suposição simples, mas geralmente não é feita. Eu o aconselho a fazer o mesmo.
- A pessoa que escreve seus comentários também é um bom engenheiro. Você, é claro, é bom, criou esse recurso. Mas existem muitos outros bons engenheiros no mundo. E quem enviou os comentários também se aplica a eles.
- Essa pessoa também quer que sua tarefa seja realizada.
Quando ele pede alguma coisa, ele tem algum tipo de motivação. Ele faz isso por uma razão. Especialmente se essa pessoa não for o primeiro dia do projeto. Certamente há alguma razão. Você pode perguntar sobre este motivo: Por que você precisa fazer exatamente isso? Por que a compatibilidade com versões anteriores é necessária aqui? Se você fizer perguntas simples com calma, razoabilidade e ouvir as respostas, poderá obter mais.
Qual o valor que o produto trará?
A revisão não é apenas correções prontas, mas também melhorias, correções do projeto. De fato, a revisão de código começa no momento em que você está apenas discutindo sua revisão. Nesse ponto, pergunte-se: que valor o produto trará para o produto?
- Será um novo recurso?
- Isso é uma melhoria existente?
- Extensão de um recurso existente?
- Será uma refatoração de código? Não há nada de errado nisso. Alguns são críticos da refatoração, mas é necessário. E você precisa estar ciente de que está fazendo isso, e não um novo recurso ou outra coisa.
- Está acelerando um processo, melhorando o desempenho?
- Isso é uma correção de bug?
Existem outras opções. De qualquer forma, começando a desenvolver algo, a resolver um problema, você deve entender qual valor agregará ao projeto.
Por que a revisão (recurso) é assim?
Há várias perguntas úteis a serem feitas.
Por que criar um recurso? Por que esse recurso é necessário? A resposta a esta pergunta é importante.
Onde é o início do trabalho? Na minha prática, aconteceu que me pediram para refazer uma certa aplicação. Há um aplicativo A, você precisa fazer um aplicativo B, que faz quase o mesmo com pequenas alterações. Começo a fazer o trabalho e acontece que A basicamente não funciona. De fato, ele é usado em algum lugar da produção usando a interface homem-máquina - ou seja, alguém senta e reinicia constantemente o programa, corrigindo literalmente a exceção do ponteiro nulo no ar. Onde é o início do trabalho? Nesse caso, ele estará consertando o programa A para que funcione de maneira estável e, em seguida, escrevendo o programa B.
Onde está a conclusão completa do trabalho? Como o trabalho realizado deve parecer ideal? É importante formular desde o início aonde você está indo.
Onde está o fim do estágio atual? É claro que você não pode comer um elefante imediatamente e é melhor dividir o trabalho em etapas. É importante entender onde está o fim do estágio atual. Muitas vezes, os projetos são inflados e não terminam apenas porque o escopo do projeto se torna infinitamente grande.
Por que o recurso é dividido precisamente nessas etapas? Isso é sobre MVP e tudo isso. Por favor, pense sobre isso também.
Agora sobre a API pública
Existem muitos artigos sobre as propriedades da API pública. Leia antes de implementá-lo. Como um bom exemplo, posso citar a estrutura JQuery Spring em Java. Existem também exemplos negativos. Quem programa em Java há anos, provavelmente se lembra do terrível do ponto de vista da API pública EJB 2.1. A funcionalidade pode ser boa, mas se a API pública for ruim, ninguém poderá convencer os usuários a usar o produto.
A API pública não é apenas uma ferramenta para usuários de terceiros. Isso e a API dos componentes internos, que você mesmo reutiliza entre si. Propriedades importantes da API pública:
- Simplicidade.
- A evidência.
- Os padrões corretos. Vale a pena pensar neles, se, por exemplo, em um ambiente de teste, você criar 500 threads, como na produção. Ou vice-versa, na produção, por padrão, existem três threads, como em um ambiente de teste.
- Limpar mensagens de erro. Este é o flagelo de tantos produtos. Quando algo cai dentro do sistema, não está claro o que é feito de errado. Ontem funcionou, hoje uma exceção de ponteiro nulo. O que exatamente você fez de errado e como corrigi-lo não está claro na mensagem de erro.
- É difícil cometer um erro. Há muitas recomendações sobre essa pontuação. As verificações em tempo de compilação são sempre melhores que as verificações em tempo de execução, etc.
- Logs claros e suficientes. Isso é especialmente importante quando você escreve um código que será reutilizado e implantado em algum lugar do servidor.
- A capacidade de monitorar. Você precisa entender que os logs e o monitoramento também fazem parte da sua API pública. Ao analisar erros, os usuários verão como se comportam as métricas que você expõe no monitoramento.
Alterações do subsistema
Quando você vem para a revisão de código, é importante ter em mente uma lista completa de sistemas e subsistemas de um grande produto em que você está alterando. Em projetos empresariais, pode não estar claro: se é um esquema de banco de dados, um controlador ou uma apresentação, algum tipo de sistema de relatórios, uploads, downloads etc.
Ao trabalhar com um produto in a box, é importante se perguntar: como as mudanças afetam os processos existentes no sistema? Existe uma compatibilidade com versões anteriores? Isso afeta o desempenho? Se isso afeta, então o desempenho de quê? Como isso afeta a experiência do usuário?
Processos padrão do sistema
Cada sistema comercial possui processos padrão: início, instalação, alguma lista de operações. Como eles vão fluir agora? Antes da revisão do código, é importante entender isso. Você deve passar pelo código que implementa esses processos. No caso do Ignite, é o seguinte:
- Início / Parada do Nó (servidor / cliente, coordenador / regular) - inicia, para um nó, inicia um servidor ou nó do cliente, inicia um coordenador ou um nó normal
- Junção de nó - em termos de um novo nó / coordenador / servidor / cliente
- Ativação de cluster (e desativação)
- Mudança de coordenador
- Criar / excluir cache
- Persistência / BLT / MVCC
É claro que o conjunto desses processos é bastante grande. É importante entender que esses processos existem e como eles mudam.
Caixas de canto
Em seu aplicativo de negócios, recuperação de desastre, inicialização inicial do sistema, desligamento do nó, reinicialização, atualização do aplicativo e coisas semelhantes podem acontecer. No caso do Ignite, temos os seguintes casos de canto:
- mudança de coordenador;
- queda de nó;
- problemas de rede - quando as mensagens da rede não chegam;
- arquivos quebrados.
Devemos verificar e verificar essas coisas para que tudo esteja em ordem.
Bons recursos de código
Então chegamos ao código. Eu aconselho você a não ser preguiçoso e procurar nele:
- simplicidade
- extensibilidade
- testabilidade
- confiabilidade
- alta velocidade de trabalho.
Concorrência
Java tem suas próprias peculiaridades ao escrever código de simultaneidade. Se você possui um sistema comercial e há pouca concorrência lá, não precisa considerar esses recursos. No entanto, geralmente algumas sincronizações passam pelo banco de dados. Em coisas como Ignite, isso é um pouco mais complicado. E aqui, não apenas a funcionalidade do código é importante, mas também suas propriedades:
- Quão difícil é entender o seu modelo de concorrência?
- Estrutura de dados compartilhada - como é garantida sua integridade?
- Fechaduras - o quê e por quê?
- Threads - quais pools são usados? Porque
- Garantias de visibilidade das mudanças - para que são fornecidas?
Essas perguntas devem ser feitas antes da revisão do código de simultaneidade. É claro que esta lista pode ser continuada por um período muito longo.
Testes de desempenho. Benchmarks
Se você estiver desenvolvendo algum tipo de sistema, ele possui clientes, instalações, e obviamente funciona com algum desempenho. No mundo de hoje, é impossível aumentar a potência do hardware indefinidamente. Precisamos de testes e monitoramento de desempenho. Ao realizar uma revisão de código, é importante entender:
- O teste de desempenho é necessário? Talvez seja algum tipo de refinamento que não precise de testes de desempenho?
- Se necessário, qual? Existem muitas técnicas e métodos de medição, etc.
- Onde-como-o que precisa ser medido?
- Quais referências são indicativas? O número de nós? Ferro? Acender configuração? A natureza da carga?
Total
No geral, a revisão de código é uma prática muito gratificante. Espero que todos os desenvolvedores (incluindo produtos empresariais) já o tenham implementado em casa. Caso contrário, implemente o mais rápido possível. Ficarei feliz em discutir as práticas de revisão de código com você nos comentários.
Vídeo da palestra:A apresentação está disponível aqui .