A importância da qualidade na programação de software segundo E.W. Dijkstra

Olá a todos,

Para os engenheiros de software tradicionais, o nome de E.W.Dijkstra evoca muito respeito pelo trabalho realizado no campo da informática e programação de software. Eu, sendo da geração mais jovem, fui apresentado a EWD (o nome curto usado pelo Sr. Dijkstra em todas as suas publicações) através de seu artigo em que considerava prejudicial o uso do GOTO. Recentemente, a palestrante Bodil Stokke me deixou sem palavras com novas revelações e ideias sobre as obras de EWD. Como reflexão posterior, tentei ler alguns de seus artigos sobre programação de software: 'A tarefa do programador considerada como um desafio intelectual' e 'Em direção a programas corretos'. A declaração que mais me impactou foi, segundo EWD, que o procedimento de garantia de qualidade ou teste seguido após a fase de implementação é semelhante a colocar o carro na frente dos bois. Neste blog, pretendo aprofundar mais nesta declaração e algumas outras declarações de EWD relacionadas à garantia de qualidade através de testes e depuração.

Todos nós somos treinados para acreditar em estruturas testadas e comprovadas. Todos nós somos educados com os passos para o sucesso e tendemos a seguir esse pensamento. EWD é conhecido por fazer declarações contundentes relacionadas à programação de software que com o tempo se mostraram certas. Por experiência, observei que o processo de controle de qualidade nos ajuda a identificar os erros na solução. Isso implica que os erros foram introduzidos na solução pelo programador, já que o programador tem controle total sobre a solução (apesar de todas as reclamações do programador de que está sendo controlado pelo cliente/gerente/colega/RH, etc.). Portanto, introduzimos o erro e depois introduzimos o passo para identificar os erros.

Avançando, identificamos os erros e os registramos no rastreador. Em seguida, o programador queima o óleo da meia-noite ou a eletricidade da meia-noite para converter todos os casos de teste de VERMELHO para VERDE. Em seguida, passamos a solução como funcionando perfeitamente e pronta para uso pelo cliente. Se a fase de testes é para eliminar todos os erros, por que continuamos mantendo a fase de suporte para rastrear os erros uma vez em produção? EWD diz: "os testes de programas podem ser usados de forma muito eficaz para mostrar a presença de erros, mas nunca para mostrar sua ausência". Os testes são uma fase importante, mas temos dado muita importância a eles para entregar uma solução de qualidade. É uma forma de avaliar uma solução, mas não de garantir uma solução de qualidade. A qualidade é um pensamento que deve ser invocado quando iniciamos o processo de design da solução. Tentar inseri-lo no final do processo de entrega é um processo de limpeza inútil. É semelhante a limpar a parte externa de um novo prédio onde não podemos fazer nada sobre a estrutura interna.

EWD fala muito sobre a importância de compreender a estrutura interna das entidades abstratas. Nunca poderemos gerar e testar todos os casos de teste possíveis para uma solução específica para determinar sua completude. EWD acredita que temos que chegar a um processo de dedução semelhante à matemática onde provamos fórmulas com base em certos casos e se forem válidas nesses casos, garantimos que também funcionarão em outros casos. Bem, é um pensamento complexo e arriscado depender totalmente do processo anterior de solução. Também não sugere que se abandone o teste como procedimento. São ferramentas/processos necessários na programação de software. Mas, observamos repetidamente que tentamos o velho vinho e ele deixa o mesmo gosto amargo na boca.

O programador deve pensar nas características necessárias da solução de programação antes da implementação e não como uma ideia posterior. Todos tendemos a pensar nos atributos do programa após sua implementação, em vez de incluí-los como parte das especificações antes do desenvolvimento.

Uma das razões por trás da profunda proliferação desses terríveis hábitos na indústria de software, segundo EWD, é que a necessidade de atender à crescente demanda por software é cumprida chamando mais programadores, em vez dos mais capazes, que poderiam derivar sua maior capacidade de uma melhor compreensão da natureza da tarefa de programação.

Ao olhar para trás em minha carreira, é desconcertante ver que, apesar de todas as advertências dadas pelos grandes engenheiros de software como EWD desde os anos 60 e 70, ainda estamos presos na mesma forma antiga de desenvolver software de (baixa) qualidade. Mesmo agora, recorremos aos mesmos passos e acabamos com o mesmo produto. Ágil ou não-Ágil, precisamos de uma grande sacudida no processo de pensamento. Também é responsabilidade dos programadores se firmarem e assumirem a responsabilidade pela garantia da qualidade. Se os programadores não estão qualificados/interessados nisso, então é responsabilidade do líder da equipe/gerentes incentivá-los. Por fim, é responsabilidade de todos nós limpar a bagunça e colocar as coisas em ordem. Tornou-se algo semelhante à política, onde todos que entram nela tentando se livrar da corrupção acabam sendo corrompidos pelo sistema. Como de costume, acabamos culp