Escrevendo um código melhor para projetos baseados em WordPress

Não me lembro exatamente quando me deparei com o blog de Joel Spolsky, Joel on Software, mas foi em algum momento no final do ensino médio.

Eu não sabia o suficiente sobre todo o processo de desenvolvimento de software para entender muito do que ele estava falando, mas gostei de seu estilo de escrita e gostei do que ele tinha a dizer.

Na verdade, eu era tão fã que, quando me formei, passei a comprar os livros dele (que eram coleções dos artigos do site dele) e os li de capa a capa. Eu mantinha cópias deles na minha mesa de trabalho e usei um de seus livros – Smart and Gets Things Done – quando eu era líder de equipe.

Os artigos que mais me chamaram a atenção, porém, foram aqueles que tratavam de escrever código melhor. Aqui está a coisa, no entanto: esses artigos não incluíam nada sobre realmente escrever código.

Escrevendo um código melhor

Em vez disso, era tudo sobre os processos em torno de um código melhor. E me deparei com um artigo – com 16 anos, no entanto – e ainda o acho tão relevante hoje quanto quando o encontrei pela primeira vez.

Exceto agora, eu me pergunto como isso se aplica ao meu trabalho de desenvolvimento atual.

O teste de Joel

Primeiro, o artigo em questão é um que me pego lendo pelo menos uma vez por mês – se não pelo menos uma vez por semana – e tudo gira em torno do que ele chama de The Joel Test. São doze perguntas que você aplica à sua equipe de desenvolvimento atual.

1. Você usa o controle de origem?
2. Você pode fazer uma construção em uma etapa?
3. Você faz builds diários?
4. Você tem um banco de dados de bugs?
5. Você corrige bugs antes de escrever um novo código?
6. Você tem uma agenda atualizada?
7. Você tem uma especificação?
8. Os programadores têm condições de trabalho silenciosas?
9. Você usa as melhores ferramentas que o dinheiro pode comprar?
10. Você tem testadores?
11. Os novos candidatos escrevem código durante a entrevista?
12. Você faz testes de usabilidade de corredor?

Dado que essas questões foram escritas há 16 anos e são amplamente baseadas em código compilado, algumas das terminologias podem precisar ser ajustadas.

O legal do Teste Joel é que é fácil obter um rápido sim ou não para cada pergunta. Você não precisa descobrir linhas de código por dia ou erros médios por ponto de inflexão. Dê à sua equipe 1 ponto para cada resposta “sim".

Por exemplo, em vez de perguntar se você pode fazer uma compilação em uma etapa, talvez devêssemos perguntar se podemos fazer uma implantação em uma etapa. Você sabe o que quero dizer – fazer ajustes em coisas assim.

Em segundo lugar, algumas das perguntas precisam ser adaptadas às equipes remotas, porque não estamos mais no mesmo escritório. Ou seja, em vez de fazer testes de usabilidade no corredor, você pode precisar pegar alguém que você conhece online, enviá-lo para o seu ambiente de teste e perguntar sobre o projeto.

O teste de Joel para WordPress

Talvez, para aqueles de nós que usam o WordPress como nossa base de desenvolvimento, nosso conjunto de perguntas seria algo assim:

1. Você usa o controle de origem?
2. Você pode fazer uma implantação em uma etapa?
3. Você faz implantações diárias?
4. Você tem um banco de dados de bugs?
5. Você corrige bugs antes de escrever um novo código?
6. Você tem uma agenda atualizada?
7. Você tem requisitos e modelos?
8. Os programadores têm condições de trabalho silenciosas? Ou, se remoto, os programadores têm permissão para entrar no modo “Não perturbe”?
9. Você usa as melhores ferramentas do mercado, seja algo gratuito e de código aberto ou algo premium?
10. Você tem testadores? (E eu poderia perguntar se o orçamento do projeto permite tempo para escrever testes de unidade para testes automatizados também)?
11. Os candidatos têm exemplos de código disponíveis no GitHub, um blog ou um local disponível publicamente que pode ser revisado?
12. Você tem um grupo de pessoas que você pode usar para testar seu trabalho em andamento?

Novamente, isso é amplamente baseado na ideia de uma equipe pequena e remota, em vez de uma grande empresa ou agência de produtos de nível empresarial. Mas é algo que eu ainda volto de vez em quando e me pergunto como as outras lojas se comparam.

Ah, e a coisa toda de pontuação?

Uma pontuação de 12 é perfeita, 11 é tolerável, mas 10 ou menos e você tem sérios problemas. A verdade é que a maioria das organizações de software está executando com uma pontuação de 2 ou 3 e precisam de ajuda séria…

Todos nós temos algo para apontar, certo?

Para a próxima década?

Não é tanto que eu ache que é uma competição, mas sei que gostaria de poder responder sim à maioria dessas perguntas para mim e para aqueles com quem trabalho.

Mas no momento deste artigo, posso dizer que não posso dizer sim a todos eles, muito menos talvez metade deles. Talvez até o final do ano, eu possa, no entanto.

E talvez o resto de nós que trabalhamos na indústria possa avaliar nossas equipes em relação a essas questões. Embora a Internet e as tecnologias relacionadas se movam rapidamente, essas questões têm se mantido bem por mais de uma década.