Grátis: Assinale a alternativa que apresenta uma recomendação correta para revisores de código, de acordo com os autores Aline Torres e Marco Tulio Valente... – Questões Respondidas

Engenharia de Software

Outros

Assinale a alternativa que apresenta uma recomendação correta para revisores de código, de acordo com os autores Aline Torres e Marco Tulio Valente.
Evite imagens e screenshots.
Evite sugestões relacionadas a estilos pessoais.
Não faça perguntas nos comentários, apenas sugestões diretas.
Evite usar o pronome “nós”, pois o código não foi feito por você também.
Na dúvida, o revisor deve sugerir uma alteração.

Desvendando com Questões

há 8 meses

Desvendando com Questões

há 8 meses

Gerencia e qualidade de software sem 6

Gerencia e qualidade de software sem 6

UNIVESP

Respostas

Ed

há 8 meses

A recomendação correta para revisores de código, de acordo com Aline Torres e Marco Tulio Valente, é: Evite sugestões relacionadas a estilos pessoais. Essa abordagem ajuda a manter o foco na qualidade do código e na conformidade com as diretrizes do projeto, em vez de opiniões pessoais.

Essa resposta te ajudou?

0

0

left-side-bubbles-background

right-side-bubbles-background

Crie sua conta grátis para liberar essa resposta. 🤩

Já tem uma conta?

Ao continuar, você aceita os Termos de Uso e Política de Privacidade

Ainda com dúvidas?

Envie uma pergunta e tenha sua dúvida de estudo respondida!

Essa pergunta também está no material:

Gerencia e qualidade de software sem 6

Gerencia e qualidade de software sem 6

UNIVESP

Mais perguntas desse material

Assinale a alternativa que apresenta uma questão que deve ser considerada em revisão de código de acordo com os autores Aline Torres e Marco Tulio Valente.
Código muito simples.
Código com problemas de indentação.
Alguns bugs específicos.
Uso de bibliotecas ou frameworks em geral.
Excesso de documentação.

Assinale a alternativa que apresenta uma informação correta em relação às variações no pareamento para a programação pareada de acordo com o texto “Programação em par”, da Wikipédia.
No pareamento novato-novato, há a vantagem de se conseguir melhores resultados do que cada um dos novatos trabalhando de forma independente.
No pareamento especialista-novato, há a desvantagem de que o novato não possui perfil para questionar as práticas estabelecidas.
No pareamento especialista-novato, há a desvantagem de que os especialistas não têm a paciência necessária para permitir a participação construtiva de novatos.
No pareamento especialista-especialista, há a vantagem de ambos os especialistas sempre questionarem as práticas estabelecidas.
No pareamento novato-novato, há a vantagem de que ambos os novatos possam desenvolver bons hábitos de programação em conjunto.

De acordo com o autor Everson Mauda, assinale a alternativa que apresenta um pensamento correto de um time de desenvolvimento de software, considerando o perfil desse time em relação à dívida técnica.
Imprudente e negligente: “O que são camadas?”.
Prudente e proposital: “Nós não temos tempo para design”.
Imprudente e proposital: “A entrega tem que ser feita e lidaremos com as consequências”.
Imprudente e proposital: “Agora nós sabemos como deveria ter sido construído”.
Prudente e negligente: “Nós não temos tempo para design”.

De acordo com o autor Everson Mauda, assinale a alternativa que apresenta uma descrição correta do perfil de um time de desenvolvimento de software em relação à dívida técnica.
Prudente e involuntário: isso é verdade para times com excelentes arquitetos. Eles fornecem uma solução que agrega valor ao negócio, mas depois o time não tem tempo para o design e utiliza uma solução rápida e com pouca preocupação com a qualidade.
Prudente e negligente: o time não tem consciência dos princípios básicos de design, então, nem sequer imagina a bagunça que estão adicionando.
Imprudente e proposital: isso é verdade para times com excelentes arquitetos. Eles fornecem uma solução que agrega valor ao negócio, mas depois de completar a solução, eles entendem que a abordagem de design poderia ter sido melhor.
Imprudente e negligente: o time não tem tempo para o design e utiliza uma solução rápida e com pouca preocupação com a qualidade.
Prudente e proposital: o time precisa entregar o produto agora, com todas as limitações conhecidas, e assume de maneira proativa as consequências para futuras correções.

Assinale a alternativa que descreve corretamente uma vantagem para o uso de programação pareada de acordo com o texto “Programação em par”, da Wikipédia.
Melhorar qualidade do código: como todo código produzido é revisado e aprimorado constantemente por diferentes integrantes da equipe, isso aumenta a qualidade do código.
Gerar mais união na equipe: os participantes mais experientes ficam com pena daqueles menos experientes ao ver o quanto eles ainda precisam avançar e isso acaba gerando mais união na equipe.
Melhorar a disciplina do time: como a prática de programação é bastante divertida, isso faz com que os programadores não a levem a sério quando programam sozinhos.
Ausência de gerência: por ser uma atividade par-a-par, nenhum gerente é necessário.
Compartilhar conhecimento: como há sempre um participante experiente e um inexperiente, aquele experiente está sempre compartilhando seu conhecimento com o participante inexperiente.

Assinale a alternativa que apresenta a principal motivação para revisão de código de acordo com a pesquisa apresentada pelos autores Aline Torres e Marco Tulio Valente. Detectar bugs. Aumentar qualidade. Melhorar o código. Transferir conhecimento. Soluções alternativas.

Assinale a alternativa que apresenta uma informação correta sobre dívida técnica de acordo com o autor Everson Mauda.
Dívidas técnicas do tipo “proposital” devem ser evitadas.
O time de desenvolvimento não precisa ter pressa para pagar uma dívida técnica.
Dívidas técnicas do tipo “negligente” são mais fáceis de serem quitadas.
Um exemplo de dívida técnica é a escolha de um design mais rápido e de baixa qualidade.
Um time de desenvolvimento deveria buscar nunca adquirir dívidas técnicas.