15 fatos sobre programação que você provavelmente não sabia | iMasters
Tem 121 artigos publicados com 330479 visualizações desde 2011
A tarefa de programar está se tornando cada vez mais comum, porém ainda existem muitos fatos que as pessoas não conhecem sobre programadores e a programação em si. Acompanhe comigo o conteúdo deste artigo que apresenta 15 fatos pouco conhecidos sobre a programação.
Assim como outras atividades intelectuais, a tarefa de programar e de como as pessoas aprendem a programar computadores é muito estudada. De fato, com cada vez mais pessoas aprendendo a programar, independentemente da linguagem, ferramenta ou plataforma utilizada, é natural que poucas pessoas realmente saibam de certos fatos importantes já bem conhecidos sobre programação e desenvolvimento de software.
Do ponto de vista acadêmico, as áreas de engenharia de software e educação apresentam diversos pontos muito interessantes obtidos por meio de experimentos cujos resultados são apresentados em teses de mestrado e doutorado ou papers da área. E com base nesses resultados escolhi os fatos a serem citados neste artigo, junto com as devidas referências. Ou seja, se você, leitor, ficou com vontade de saber mais sobre cada um dos pontos discutidos aqui, recomendo fortemente procurar a referência completa para mais informações.
Com base nesse contexto, vou apresentar 15 fatos importantes e que, infelizmente, são pouco conhecidos por quem programa. Mas antes faço um aviso: esses fatos apresentam resultados de pesquisas experimentais e empíricas que possuem contextos específicos. O que quero dizer é que existe certa margem para discussão da aplicabilidade e generalização, porém conhecer o que já foi estudado e descoberto é importante e, no mínimo, pode instigar a discussão e o quão perto da realidade do leitor estão essas informações.
1) Programadores demoram para pedir ajuda quando têm problemas
Este é um fato relacionado à maneira como as pessoas aprendem a programar, pois basicamente o ensino segue a linha de aprendizado da matemática: um pouco de teoria, um ou dois exemplos e muitos exercícios. Esse formato leva os aprendizes a tentar muito nos exercícios e, muitas vezes, tentando resolver tudo sozinhos sem pedir ajuda.
Essa atitude não é ruim e é até recomendada, mas é preciso saber até que ponto deve-se deixar de tentar e pedir alguma forma de ajuda.
Este fato é relacionado a pesquisas da área da psicologia, indicando que quando uma pessoa tem algum problema ela não fornece todas as informações completas sobre os problemas, especialmente quando ele é o responsável de forma direta ou indiretamente.
Esse resultado já foi comprovado experimentalmente com programadores, e uma das principais justificativas é a seguinte: reportar de forma completa um problema é visto como sinal de fraqueza que pode levar a algum tipo de julgamento de habilidade e proficiência por quem está ouvindo o relato. Essa situação é muito mais comum quando se trata de um erro básico de principiante.
O fato de a comunicação com outras pessoas não assumir a prioridade quando um programador precisa de ajuda está relacionado novamente à sensação de julgamento que outras pessoas fazem ao saber da dificuldade.
Não obstante, sites como o StackOverflow floresceram explorando esse tipo de comportamento por meio da agregação da ajuda com diversos conceitos de comunidade para desenvolvedores.
Além disso, é importante saber em qual fase de progresso o desenvolvedor está para, entre outras atitudes, oferecer algum tipo de ajuda para que ele não fique muito tempo emperrado em um local específico a ponto de atrasar alguma entrega. Uma classificação interessante identificou (de forma automática) quatro possíveis estados de progresso:
Emperrado (stuck)
Este fato pode parecer óbvio, mas ele é muito importante de ser detectado, uma vez que uma barreira de programação pode levar sérios problemas de prazo, moral da equipe e confiança.
Uma das principais dificuldades de se detectar barreiras e classificá-las está no fato de que essa informação pode ser subjetiva. Ou seja, perguntar diretamente para o programador se ele está com alguma barreira superável ou insuperável já afeta o resultado, pois ele nem sempre pode ser sincero. Há também algumas implicações em termos de ego e moral, apenas pelo fato de identificar esse tipo de barreira na programação,
Além da classificação de barreiras de programação superáveis e insuperáveis, há um estudo muito interessante que caracterizou cada uma das possíveis barreiras de programação. Para ajudar a entender as barreiras, os pesquisadores evidenciaram frases comuns em cada uma das classificações abaixo:
Design: "Eu não sei o que o computador deve fazer".
Seleção: "Eu sei o que fazer, mas não sei o que usar".
Coordenação: "Sei o que usar, mas não sei como combinar o que preciso".
Uso: "Eu sei o que usar, mas não sei como usar".
Compreensão: "Pensei que sabia usar X, mas ele não faz o que eu esperava".
Informação: "Compreendo o que aconteceu, mas não consigo checar".
7) Programadores passam aproximadamente 30% do tempo navegando no código-fonte
Quem programa sabe que a maior parte do tempo é gasta dentro de uma ferramenta de edição de código-fonte. Contudo, o tempo é divido entre as tarefas de edição do texto representado pelo código-fonte.
De acordo com um estudo muito importante, descobriu-se que aproximadamente 30% do tempo de trabalho de um programador não são gastos editando o texto (incluindo, alterando o excluindo), mas sim navegando entre diversos arquivos com códigos-fontes. Essa navegação envolve pesquisa, observação, coleta de informações, memorização e outras atividades. Ou seja, dá para dizer que a programação é uma atividade cuja terça parte é apenas contemplativa.
Esta afirmação sobre produtividade é polêmica, especialmente no momento em que se fala cada vez mais em home office, trabalho remoto e projetos globais de desenvolvimento de software. De qualquer maneira, existem evidências concretas baseadas em diversas métricas de software que, de fato, programadores remotos não produzem tanto quanto programadores que estão no mesmo local.
Faz sentido pensar dessa maneira se analisarmos os outros fatos desta lista, como a preferência pela falta de comunicação com outras pessoas. De fato, a comunicação informal é um dos principais fatores que influenciaram o resultado dessa pesquisa, pois pedir aquela dica no encontro durante uma pausa para o café é muito importante de acordo com que foi apurado.
Esta afirmação sobre a diversidade de programadores não veio exatamente de uma pesquisa acadêmica, mas sim de Adda Birnir, que é a fundadora do site de recrutamento e seleção Skillcrush. Essa declaração foi apresentada no vídeo "Is CODE the most important language in the world?".
Atualmente, é muito comum destacar minorias na programação, especialmente a baixa quantidade de mulheres. Contudo, como certos dados mostram, esse não é o único grupo de possui baixa representatividade na programação, e isso pode ter uma implicação séria quando falamos em código de aplicações que precisam lidar de forma adequada com certos grupos de usuários.
Mensagens de erro, problemas de tempo de execução e erros de compilação são muito específicos para cada linguagem. Para destacar alguns casos, cito a tese de mestrado da pesquisadora Suzanne Marie Thompson, pois ela analisou uma grande quantidade de programadores Java em diversos cenários e coletou muitos dados interessantes sobre isso. As tabelas abaixo contam um pouco da história sobre erros e tempo médio para corrigi-los.
Apesar de o estudo se concentrar em um contexto muito específico (aprendizado da linguagem Java), é possível fazer um paralelo com outros cenários e situações, e comprovar que realmente boa parte dos erros mais comuns é replicada por programados em diferentes contextos.
Tabela 6.2. Erros mais frequentes (Java) e tempo médio de execução.
Tabela 6.12. Frequência de erros de execução em Java (runtime).
Tabela D.1 Principais erros de compilação (Java) e tempo médio para resolvê-los.
A manutenção de um software envolve a manipulação de código legado, assunto que já abordei antes. Porém, desta vez, cito um estudo que fala sobre esforço e que mostra como resultado que a divisão não é igual entre a criação e a manutenção.
No estudo que citou esse valor de mais de 50% de esforço, há uma ótima discussão sobre evolução do software no sentido da sua manutenção e das tarefas necessárias para tanto. Com certeza vale a pena dar olhada uma nessa referência antes de tomar aquela decisão sobre começar do zero ou trabalhar com uma base de código existente.
12) A manutenção de software consome entre 40% e 90% dos custos
Uma das principais regras de quem trabalha com negócios diz que é muito mais caro conseguir um cliente novo do que manter um cliente já existente. Contudo, de acordo com pesquisas da área de engenharia de software, a realidade é um pouco diferente quando se fala de código: manter um código em funcionamento por meio de tarefas de manutenção pode chegar a custar até 90% de todos os custos do projeto.
Essas estatísticas são bem genéricas e foram obtidas em um contexto muito particular das 487 organizações estudadas nessa pesquisa, sem contar que o estudo é de 1980. Certamente existem diversos fatores a serem considerados, mas ao menos existe um ponto de partida para analisar cursos e discutir sobre esse aspecto quando se fala de manutenção de software.
Ainda falando sobre manutenção de código-fonte, um estudo que influenciou muito a comunidade de engenharia de software classificou por meio da análise de resultados de questionários as principais práticas da manutenção de software. Quatro práticas foram identificadas:
Melhoria: envolvem mudanças de funcionalidades.
Adaptativa: são mudanças no ambiente para adaptação a requisitos
Corretiva: atividades para a correção de erros
Preventiva: melhorias para evitar problemas futuros
14) Custos da correção de defeitos após a implantação são 10x maiores do que na fase de construção, e 100x maiores do que na fase de design
Este fato é um clássico da área e motivou a evolução dos processos clássicos de desenvolvimento de software até chegarmos ao que temos hoje. O principal ponto aqui é a identificação de custos elevados quando não se dá a devida atenção à construção e design do software.
A revisão de código feita por outras pessoas, seja na modalidade de pair programming ou não, é realmente efetiva. Existem diversos estudos sobre isso, mas um dos principais indica que até 60% dos defeitos podem ser descobertos (mas não necessariamente corrigidos) quando mais de uma pessoa revisa o código-fonte.
Esse estudo é relativamente antigo e pode-se dizer que ele é um dos principais influenciadores de técnicas envolvendo processos ágeis (Agile) e outras formas de desenvolver software cujo principal foco é nas atividades, etapas, organização e outras habilidades não tão técnicas quanto a programação.