Em 1992, eu achava que Eu era o melhor programador do mundo. Em minha defesa, eu tinha acabado de me formar na faculdade, isso foi antes da Internet, e eu morava em Boulder, Colorado, trabalhando em pequenas empresas, onde eu tinha sorte de conseguir ouvir sobre outros programadores, muito menos conhecê-los.
Acabei me encontrando com um cara chamado Bill O’Neil, que me contratou para fazer programação por contrato. Ele formou uma empresa com o nome lamentavelmente genérico de Computer Research & Technologiese começamos a trabalhar juntos em vários projetos, criando aplicativos CRUD de linha de negócios em Visual Basic ou FoxPro executados no Windows 3.1 (e, às vezes, no DOS, embora já tivéssemos a noção de que essa coisa de GUI nova e moderna tinha vindo para ficar).
Bill foi o primeiro programador profissional com quem trabalhei. Aliás, ele foi o primeiro programador com quem já trabalhei. Ele especificava um trabalho comigo, eu o desenvolvia em Visual Basic e depois o entregava a ele para revisão. Ele, então, calmamente, prosseguia com a demolir meu código:
- Ordem das guias? Errado.
- O senhor está digitando um número em vez de uma string? Crash.
- Digitando uma data no passado? Crash.
- O senhor está digitando muitos caracteres? Crash.
- Alinhamento de elementos da interface do usuário? Desligado.
- Funciona com caracteres incomuns em nomes como, por exemplo,
O'Neil? Não.
Uma coisa que me surpreendeu foi que o código em si raramente era o problema. Ocasionalmente, ele fazia alguns comentários sobre a forma como eu escrevia ou estruturava o código, mas o o que eu claramente não tinha ideia era que o testes meu código.
Eu temia entregar meu trabalho a ele para inspeção. Aprendi lenta e dolorosamente que a parte realmente difícil da codificação é lidar com as milhares de maneiras pelas quais as coisas podem dar errado com seu aplicativo a qualquer momento – a maioria delas relacionada ao usuário.
Essa foi minha primeira experiência com o o sistema de amigose, graças ao Bill, saí desse relacionamento com um profundo respeito pelo trabalho artesanal de software. Não tenho ideia do que Bill está fazendo atualmente, mas tiro o chapéu para ele, onde quer que esteja. Nem sempre gostei disso, mas aprender a desenvolver disciplina para testar (e quebrar) meu próprio material me tornou, sem dúvida, um programador melhor.
É tentador colocar toda essa responsabilidade aos pés do mítico engenheiro de controle de qualidade.
O engenheiro de controle de qualidade entra em um bar. Pede uma cerveja. Pede 0 cervejas. Pede 999999999 cervejas. Pede um lagarto. Pede -1 cerveja. Pede um sfdeljknesv.
– Bill Sempf (@sempf) 23 de setembro de 2014
Se o senhor tiver a sorte de trabalhar com um, o senhor deve ter uma ótima experiência, muito medo saudável de testadores profissionais. Eles são aterrorizantes. Basta digitalizar isto “Lista “Será que me lembrei de testar? e o senhor terá o pior tipo de flashback em pouco tempo. E essa é a abreviado versão abreviada de sua lista.
Acredito que um ponto de virada importante na vida profissional de todo programador profissional é quando o senhor percebe que o senhor é seu pior inimigoe a única maneira de mitigar essa ameaça é aceitá-la. Lei como seu próprio pior inimigo. Quebre sua UI. Quebre seu código. Faça terrível coisas terríveis para seu software.
Isso significa que os programadores precisam ter um bom conhecimento prático de, pelo menos, o comuns os casos frequentes que os programadores comuns tendem a deixar passar, para trabalhar contra eles. O senhor é o testador zero. Essa é sua responsabilidade.
Vamos começar com o clássico de Patrick McKenzie Falsehoods Programmers Believe about Names (Falsidades que os programadores acreditam sobre nomes):
- As pessoas têm exatamente um nome completo canônico.
- As pessoas têm exatamente um nome completo pelo qual são conhecidas.
- As pessoas têm, neste momento, exatamente um nome completo canônico.
- As pessoas têm, neste momento, um nome completo pelo qual são conhecidas.
- As pessoas têm exatamente N nomes, para qualquer valor de N.
- Os nomes das pessoas cabem em uma determinada quantidade de espaço definida.
- Os nomes das pessoas não mudam.
- Os nomes das pessoas mudam, mas somente em um determinado conjunto de eventos enumerados.
- Os nomes das pessoas são escritos em ASCII.
- Os nomes das pessoas são escritos em qualquer conjunto de caracteres único.
Esses são apenas os 10 primeiros. Existem mais trinta. E muito mais nos comentários, se o senhor estiver a fim de obter crédito extra. Ou, como o Falsidades que os programadores acreditam sobre o tempo o senhor se agarra?
- Há sempre 24 horas em um dia.
- Os meses têm 30 ou 31 dias.
- Os anos têm 365 dias.
- Fevereiro tem sempre 28 dias.
- Qualquer período de 24 horas sempre começará e terminará no mesmo dia (ou semana, ou mês).
- Uma semana sempre começa e termina no mesmo mês.
- Uma semana (ou um mês) sempre começa e termina no mesmo ano.
- A máquina em que um programa é executado sempre estará no fuso horário GMT.
- Ok, isso não é verdade. Mas, pelo menos, o fuso horário no qual o programa deve ser executado nunca mudará.
- Bem, certamente nunca haverá uma mudança no fuso horário em que um programa deve ser executado na produção.
- O relógio do sistema sempre será definido com o horário local correto.
- O relógio do sistema sempre será ajustado para uma hora que não seja muito diferente da hora local correta.
- Se o relógio do sistema estiver incorreto, pelo menos ele sempre estará atrasado em um número consistente de segundos.
- O relógio do servidor e o relógio do cliente sempre serão ajustados para o mesmo horário.
- O relógio do servidor e o relógio do cliente sempre serão ajustados para aproximadamente o mesmo horário.
Há mais? De é claro que há! Há até mesmo uma lista adicional de coisas que o ele esqueceu quando ele montou essa lista gigante.
Acho que os senhores podem ver onde isso vai dar. Isso é programação. Fazemos essas coisas por diversão, o senhor se lembra?
Mas, no verdadeiro estilo “feito para a TV”, espere, tem mais! Sério, pessoal, aonde os senhores vão? Voltem para cá. Temos mais estados de fracasso incríveis para conhecer:
A essa altura, eu não o culparia se o senhor decidisse abandonar completamente a programação. Mas acho que é melhor aprendermos a fazer uns pelos outros o que Bill fez por mim, há vinte anos: ensinar aos desenvolvedores menos experientes que um bom programador sabe que têm para fazer coisas terríveis em seu código. Faça isso porque, se o senhor não o fizer, garanto que outras pessoas o farão e, quando o fizerem, irão embora ou criarão um tíquete de suporte. Não tenho certeza do que é pior.