“O problema com o software”

Felix Raab Blocked Desbloquear Seguir Seguindo 13 de janeiro

Sempre me interessei em encontrar novos livros valiosos de engenharia de software e, em meu artigo “ Os 5 melhores livros contemporâneos de engenharia de software ”, elaborei uma lista dos meus favoritos atuais. “ O Problema com o Software: Por que Engenheiros Inteligentes Escreverem Código Ruim ” por Adam Barr (2018) – se eu tivesse lido antes – provavelmente teria entrado nessa lista. Aqui está uma revisão e histórias da minha experiência pessoal relacionadas a alguns dos conteúdos do livro.

O problema com o software
The Problem With Software tem 2 avaliações e 0 avaliações. Uma fonte do setor explica por que há tanta coisa ruim… www.goodreads.com

Raiz dos problemas

Barr basicamente apresenta uma longa história de ciência da computação e tecnologia e discute criticamente o fato de que há pouco acordo comum sobre padrões e abordagens de SE confiáveis. Ele afirma:

Ao contrário de outras disciplinas de engenharia, ter um diploma em engenharia de software não garante que você compreenda um corpus conhecido de ferramentas e técnicas de programação, porque tal coisa não existe.

O livro não contém muitos conselhos concretos, como “Se você estruturar seus métodos dessa forma, melhorará seu design de software e escreverá menos códigos ruins”. Em vez disso, o autor concentra-se em algumas das causas e explica por que o estado da indústria é do jeito que é hoje. (Spoiler: Entre outras coisas, a instrução GOTO e a linguagem de programação C são responsáveis por muitas coisas ruins que aconteceram no software).

O primeiro par de capítulos lidos um pouco longo e para mim a segunda metade parecia mais interessante e instigante. Isto é provavelmente devido ao fato de que, apesar de alguma exposição precoce ao BASIC no meu Commodore C64 e Amiga 500 dias quando criança, eu poderia me relacionar mais com os desenvolvimentos mais recentes da minha experiência profissional. No entanto, até os primeiros capítulos citam fragmentos perspicazes de pesquisas:

“Existe um aspecto de manutenção exclusivo chamado 'recuperação do conhecimento' ou 'compreensão do programa'. Ele se torna um componente de custo importante à medida que o software envelhece (presuma 50% de melhorias e correção de defeitos). ”Metade dos custos de manutenção futuros serão gastos reaprendendo os detalhes do programa que você terá esquecido enquanto isso!

ou

"… Assim, a maioria dos programadores não pode testar efetivamente seus próprios programas, porque eles não conseguem formar a atitude mental necessária: a atitude de querer expor erros".

Desafios

No geral, gostei muito do estilo de escrita equilibrado e ponderado e do vasto conhecimento de Barr sobre a indústria e a pesquisa. Ele examina principalmente a questão central “ O desenvolvimento de software é realmente difícil ou os desenvolvedores de software não são bons nisso? De vários ângulos. Além disso, o que eu gosto é que ele não afirma saber todas as respostas, o que no caso dele é certamente uma forma de subavaliação e humildade. (Eu voltarei a isso no final do artigo.) O autor destaca alguns de seus desafios pessoais, causados pela falta de conhecimento padrão do SE e refletidos em declarações como:

Eu poderia orientar as pessoas sobre como navegar nas águas da vida corporativa, mas isso era um conselho genérico que eles poderiam obter de alguém. Como outros, minha orientação foi vaga: "Bem, neste caso eu lembro que esse tipo de coisa funcionou bem, então por que não tentar isso?"

Contexto

O impacto do contexto nos projetos de SE e um fenômeno que ele menciona chamado de “ efeito de amnésia de Gell-Mann ” se torna ainda mais claro quando Barr diz:

Se você dissesse aos membros de uma equipe da Microsoft sobre a experiência de engenharia de outra equipe, eles imediatamente seriam capazes de identificar – por causa de seu conhecimento dos internos da Microsoft – as maneiras pelas quais a outra equipe era diferente de sua equipe e, portanto, descartariam. a orientação como não relevante. Enquanto isso, eles ficariam felizes em receber orientação sobre o Scrum, mesmo que isso fosse completamente inaplicável para sua equipe, porque eles não estavam cientes dos detalhes do ambiente no qual ele havia sido bem-sucedido.

No capítulo “ Design Thinking ”, ele aborda tópicos como os benefícios dos padrões de design e explica em quais situações eles podem ser úteis, por exemplo, quando é provável que você queira modificar ou estender código no futuro (já que muitos padrões focam sobre extensibilidade futura). Sua aplicação pode ser inútil, no entanto, se futuras mudanças em um módulo forem improváveis, caso em que elas apenas introduziriam complexidade. Além disso, o capítulo contém referências a termos divertidos de pessoas notáveis como Spolsky (por exemplo, “Arquitetura Astronauta” – alguém vendo abstrações e padrões mais amplos em todo lugar…) ou outras observações espirituosas:

Embora arquitetos de software fundamentados, neste momento, sejam considerados melhores que os privados de oxigênio, o fato de os arquitetos precisarem de imersão contínua no projeto atual de sua equipe é outro sinal de que não há conhecimento e vocabulário aceitos em torno da engenharia de software.

O autor enfatiza que “conselhos razoáveis” de livros como “ Código Limpo ” e “ O Programador Pragmático ” não apresentam “abordagens específicas”. O design de software é único no sentido de que os sistemas desenvolvidos dificilmente são comparáveis entre si. Como geralmente lidamos com domínios e problemas comerciais completamente novos, a qualidade dos resultados do projeto varia muito, mesmo para pessoas muito experientes. Barr afirma que “quando você tira o absurdo do design de software, você fica com padrões de design e não muito mais”.

Algo relacionado ao contexto , no capítulo “ Your Favourite Language ”, ele menciona que a principal questão com a multiplicidade de linguagens de programação diferentes e seus designs opinativos é que há muito pouca orientação sobre quando uma linguagem é superior a outra para resolver uma certa problema. E, novamente, mais tarde, no capítulo “ Ágil ”, temos pouco conhecimento sobre quando metodologias e práticas de software ágeis, como o Scrum, são realmente valiosas. O capítulo conclui com:

Embora o Agile facilite um pouco os problemas, ele não ajuda nos problemas difíceis. É atraente para os programadores, mas para tornar a engenharia de software mais uma disciplina de engenharia, outra coisa é necessária.

Pesquisa

Quando passei alguns anos pesquisando e lecionando na Universidade, depois de ler artigos relevantes ou “ Making Software ” (um dos livros raros que tentam levar a pesquisa da SE para um público maior), fiquei surpreso ao saber o quanto da pesquisa do SE realmente existe. Muitas vezes, porém, isso me deixou de alguma forma insatisfeito com as conclusões, pois você secretamente esperava respostas universais como "Não, TDD não é útil" ou "Sim, padrões de design são valiosos" – argumentos que você espera usar em suas próximas discussões com colegas para desmantelar seus argumentos religiosos e evidência anedótica. É claro que, através das restrições dos desenhos experimentais, as respostas eram frequentemente semelhantes a “Sim, sob estas condições e nesse contexto específico, pode fazer sentido…”. Além disso, muitas vezes senti que os projetos de estudo não captavam muito bem as realidades de desenvolvimento de software (que é um dos principais desafios da SE baseada em evidências).

Dojo de Codificação

Eu particularmente gostei do capítulo final “ O Futuro ” e as sugestões do autor sobre o que podemos realmente fazer para melhorar a situação e, naturalmente, muitas das ideias de Barr têm a ver com educação, como ensinamos SE na universidade, e como os estudantes são preparado para empregos na indústria. O capítulo é inspirador e, quando mais uma vez penso na minha própria experiência acadêmica, a lacuna entre a academia e a indústria sempre me incomodou. Barr cita Weinberg, que escreve:

Projetos de software feitos em universidades geralmente não precisam ser sustentáveis, utilizáveis ou testáveis por outra pessoa.

Em uma tentativa de fechar um pouco essa lacuna, o que um colega meu e eu fizemos naquela época foi criar um novo conceito de curso para nossos alunos chamado “ Coding Dojo ”. A ideia principal era criar um seminário intensivo de vários dias para ensinar aos participantes o que considerávamos importante para trabalhar na indústria mais tarde e o que de outra forma não aprenderiam no currículo de ciência da computação. Por isso, pensamos, criamos ideias, imprimimos um panfleto que deveria atrair estudantes e construímos um sistema interativo para ensinar tópicos como legibilidade de código, cheiros de código, refatoração etc. Passamos todos os feriados da Páscoa projetando esse sistema em tempo real que poderia apresentar fazia exercícios com avaliações automáticas e tentava incorporar tudo o que sabíamos sobre o assunto naquela época, incluindo material de livros como “ Código Completo ” ou “ Refatoração ”.

Ainda estou orgulhoso do conceito e o curso foi um sucesso (pelo menos em termos de feedback e popularidade), mas até onde eu sei, até hoje ainda tem sido um esforço único. Além disso, seminários como “ Coding Dojo ” não ajudariam no problema de que os estudantes normalmente não precisam trabalhar com “softwares maiores” que, segundo Barr, os expõem cedo a programas que são “construídos a partir de conexões através da API”. limites ”e, assim, confrontá-los com importantes atividades de desenvolvimento, como ler, entender e depurar um sistema significativamente grande.

Especialização

Há muito o que melhorar nos currículos de CS e SE e, como Barr argumenta, a especialização pode ajudar, já que todo o campo se tornou muito amplo e complicado para obter uma compreensão completa de tudo. Então, em vez de criar tópicos como compiladores, gráficos e estruturas de dados avançadas – tópicos com fundamentos bem pesquisados – obrigatórios, os alunos em seus cursos de graduação poderiam optar por se concentrar em seus assuntos preferidos. Isso ajudaria a moldar seu perfil para futuros empregadores e a dar mais credibilidade. Barr escreve:

Atualmente, os engenheiros de software que saem da faculdade são vistos como fungíveis; Espera-se que qualquer programador, se for considerado competente por qualquer procedimento de contratação, possa trabalhar em qualquer parte de um programa. À medida que o software se torna mais e mais complicado, no entanto, faz mais sentido que as pessoas se especializem em diferentes áreas.

Humildade Intelectual

Finalmente, o meu conselho favorito mencionado no livro e também ouvido em outros lugares no passado é “ The humble improve ”, enfatizando o ponto de que se você ficar curioso e continuar aprendendo enquanto tem a atitude de “Apesar de ter anos de experiência, eu não não pretendo ser um especialista nesse assunto e sempre há mais para saber ”. Mesmo que esse conselho possa parecer simples, tenho sido repetidamente surpreendido pelo alto número de candidatos que se candidatam a um cargo de SE avaliam seus próprios níveis de habilidade (pedimos aos candidatos que preencham uma “folha de autoavaliação” antes de uma entrevista técnica). Minha impressão é que geralmente é um sinal de antiguidade quando as pessoas com experiência substancial não se dão as classificações mais altas em áreas específicas – indicando que elas permanecem intelectualmente humildes e podem, de fato, ser as que melhor aprimoram suas habilidades.