Que partes do Code Complete não passaram no teste do tempo? [fechadas]

Eu estava olhando o código completo na prateleira, pensando: "Fora do Mês do Homem Mítico, este pode ser um dos poucos livros de engenharia de software do mercado de massa que resistiu ao teste do tempo". Por esse motivo, estou pensando em pular para relê-lo.

Estou curioso - alguém mais deu uma segunda olhada recentemente? Eu sim, você viu alguma coisa que ele errou muito?

Isso não é um ataque e nem um pedido de resenha - estou mais interessado em quais idéias mudaram ao longo dos anos.

E, por favor - nenhum comentário sobre "Demarco / Spewak / Zachman resistiu ao teste do tempo ..." Estou especificamente interessado no Código Completo, devido à amplitude do terreno que abrange e à amplitude do impacto que teve no campo.

O Code Complete abrange muitos conceitos atemporais, como:

• coesão forte
• acoplamento solto
• bons nomes de rotina
• programação defensiva
• código de auto-documentação
• revisões de software
• teste de unidade

que certamente são relevantes hoje.

Agora, alguns dos conceitos defendidos no CC são aplicados de forma sintática nas linguagens mais recentes, por exemplo, o C # não permite que variáveis ​​nos sub-escopos sejam definidas de uma maneira que oculte uma definição com super-escopo.

Outros conceitos, como a notação húngara para nomes de variáveis, foram deixados de lado na programação convencional (embora alguém que ainda esteja trabalhando com a API do Win32 argumente com veemência que está vivo e bem). No entanto, o conceito real por trás da convenção de nomenclatura variável é transmitir o significado necessário e esclarecer o código, conceitos que eu argumentaria também são atemporais.

No total, pelo que me lembro (e uma rápida espiada na minha venerável cópia do CC), eu diria que certamente vale a pena revisar.

Não creio, no entanto, que chegue à natureza verdadeiramente atemporal do mês do homem mítico. O MMM aborda questões sobre quem está fazendo o trabalho, como e por que eles estão fazendo; bem como os custos e a complexidade das comunicações (humanas). O MMM trata de questões fundamentais para tudo o que fazemos. O CC, em comparação, enfoca questões práticas e pragmáticas de como fazemos isso. Dito de outra forma, se um projeto estiver atrasado e um gerente decidir adicionar 100 pessoas à equipe, escrever código compreensível não fará muita diferença.

O CC realmente não trata de problemas significativos que afetam nossa indústria; mas fornece uma boa base para buscar o melhor resultado em uma situação muitas vezes impossível.

Eu certamente consideraria as duas leituras obrigatórias para quem se preocupa com o desenvolvimento de software; e recomendo reler o MM sempre que precisar de uma atualização. Vale a pena reler o CC se você estiver liderando uma equipe de desenvolvimento, estabelecendo padrões de grupo ou treinando desenvolvedores mais novos; fora disso, pessoalmente acho que há muito tempo internalizei o material no CC e o pratico diariamente.

Espero que ajude. Eles são certamente dois dos meus favoritos.

No geral, o livro ainda é bom. No entanto, tenho alguns pequenos problemas com ele:

• Capítulo 17 ( "Estruturas de Controle incomuns") faz declarações menção de guarda como retornar de uma função no início, mas os exemplos dados no Capítulo 15 no "se" declarações aconselhar contra declarações de guarda. (Cláusulas de guarda chamadas / retornos antecipados no livro)
• O exemplo na seção 14.2 parece se contradizer. Primeiro, ele fornece um exemplo de código "ruim" e como torná-lo "bom". Ele então afirma que, ao agrupar as instruções relacionadas, por dados ou por semelhança de tarefas, seria "bom". O exemplo "ruim" também deve ser considerado "bom" - e, acho, muito mais fácil de ler do que o exemplo "bom", porque todos os dados estão sendo calculados na mesma taxa - há menos estado para se pensar em sua cabeça .
• Capítulo 23, Depuração, onde instruções de impressão são vilizadas em um marcador. Embora eu concorde que eles não devam ser a única ferramenta, eles são extremamente úteis para reduzir o intervalo de código em que o erro ocorre. Polvilhe um pouco para ver onde os dados de repente não são o que você espera, fornece um bom ponto de partida para depuração, dependendo do código com o qual você está trabalhando.

Tenho uma vaga memória de outra envolvendo argumentos de função, mas não consigo encontrá-la no momento. Pode ter sido outro livro.