Prova 4 · Sistema e artesanato
Partes VI e VII (cap. 27–35): tamanho do projeto, gestão da construção, integração, ferramentas, layout, comentários, caráter pessoal, temas do artesanato
Objetivas
0/20 respondidas1.
Uma equipe passa de 5 para 15 pessoas. Os canais de comunicação vão de:
2.
Num projeto muito grande, comparado a um pequeno, espera-se:
3.
O que o livro aponta como padrão mínimo e fácil de aplicar para o código da equipe?
4.
O projeto atrasou e a diretoria quer contratar 10 pessoas para o último mês. A melhor resposta, segundo o livro, é:
5.
Por que pedidos de mudança devem passar por controle de mudanças?
6.
Segundo dados citados, ambientes de trabalho silenciosos e com privacidade:
7.
Qual é a principal vantagem da integração incremental sobre a integração em fases?
8.
Na integração bottom-up, o que é necessário para testar as classes de baixo nível antes das de cima?
9.
O que é o teste de fumaça do build diário?
10.
Uma ferramenta nova promete dobrar a produtividade sem esforço. Qual postura o livro recomenda?
11.
O código abaixo tem
if (a) if (b) x(); else y();, com o else indentado sob o primeiro if. Qual o problema?12.
Por que o livro desaconselha o layout de fim de linha?
13.
Qual comentário descreve a intenção do código, o tipo mais valioso?
14.
Uma expressão com operações de bits obscura tem um comentário de 8 linhas. O que o capítulo 32 recomenda?
15.
Qual informação é mais útil num comentário de declaração de dado numérico?
16.
No paradigma do livro (book paradigm) para documentar código, o programa é organizado como:
17.
Qual traço pessoal o livro considera mais importante que a inteligência bruta?
18.
Um programador recusa um prazo que sabe ser impossível e explica o porquê. Isso demonstra:
19.
Programar "em termos do domínio do problema" significa:
20.
Qual atitude expressa "separar software e religião"?
Dissertativas
autoavaliação · não entram na notaD1.
Explique como o tamanho do projeto afeta comunicação, defeitos, produtividade e a fatia de construção. O que isso implica para o processo?
Ver resposta modelo
Canais de comunicação crescem em n(n−1)/2, então equipes maiores gastam mais tempo coordenando. A densidade de defeitos aumenta e a produtividade por pessoa cai. A fatia da construção diminui, enquanto arquitetura, integração e testes de sistema crescem. Produtos e sistemas custam várias vezes mais que um programa simples. Implicação: a formalidade do processo deve crescer com o tamanho, sem impor a projetos pequenos a burocracia dos grandes.
D2.
Compare integração em fases e incremental e descreva o build diário com teste de fumaça, incluindo regras para mantê-lo útil.
Ver resposta modelo
Em fases (big bang), tudo é juntado no fim e os erros aparecem juntos, difíceis de localizar. Incremental integra pedaço por pedaço (top-down, bottom-up, sanduíche, por risco, por funcionalidade, em T): erros fáceis de achar, sistema funcionando cedo, progresso visível. Build diário compila tudo e roda um teste rápido do sistema inteiro. Regras: build quebrado é prioridade, desenvolvedores rodam o smoke antes de integrar, o teste é mantido atualizado e automatizado, e o build continua mesmo sob pressão.
D3.
Discuta os temas centrais do artesanato de software (cap. 34) e como eles aparecem em layout e comentários (cap. 31 e 32).
Ver resposta modelo
Temas: conquistar a complexidade, escolher o processo, escrever para pessoas primeiro, programar para dentro da linguagem, usar convenções, programar em termos do domínio, prestar atenção a sinais de alerta, iterar e não tratar métodos como religião. Em layout, o teorema fundamental (mostrar a estrutura lógica) serve a pessoas, não ao compilador. Em comentários, explicar a intenção e o porquê, e reescrever código truque em vez de comentá-lo, reduz complexidade e eleva o nível de abstração.