Rodrigo Allemand

Recentemente um desenvolvedor da minha equipe e eu estavamos conversando sobre como dar soluções bem feitas. Ele se queixava de demorar muito para achar uma solução, construindo e re-construindo por muitas vezes um determinado pedaço de código até chegar a uma solução realmente boa. Refactoring é a saida para um bom código, mas existem outos pontos de falha na sua maneira de programar.

O conhecimento hoje é uma jóia que está a apenas alguns cliques de todos nós. Hoje em dia se aprende desde a fazer arroz a até uma bomba nuclear. Mas como adquirir conhecimento na nossa área? Como programar melhor? Como otimizar o seu tempo de desenvolvimento? Muitas dessas respostas estão a disposição de todos os programadores desde o inicio do ano 2000, numa das melhores -senão a melhor – compilações de boas práticas para a área de desenvolvimento de software.

Trata-se do livro The Pragmatic Programmer, From Journeyman to Master, de Andrew Hunt e David Thomas. Eu já li o livro pelo menos umas duas vezes (falando nisso, preciso entregar o livro ao dono!) e recomendo a quem não leu ainda, seja ele junior ou sênior.

O livro traz uma série de dicas sobre como se tornar um bom programador. Segue um pequeno resumo.

1. Preocupe-se em fazer um código bom
2. Pense!! Critique o seu trabalho
3. Dê opções, não dê desculpas.
4. Conserte falhas ao encontrar a falha
5. Seja um catalizador de mudanças
6. Lembre-se o ‘porquê’ do projeto
7. Faça da qualidade um requerimento
8. Invista regularmente no seu portifólio de conhecimento
9. Analise e critique o que você ouve e vê
10. É o que você fala e COMO você fala
11. DRY – Don’t Repeat Yourself
12. Faça facil para ser reutilizavel
13. Elimine efeitos entre coisas não relacionadas
14. Não existem decisões finais
15. Use traçantes para achar o alvo
16. Prototipar para aprender
17. Programe para o problema do domínio usando a linguagem do domínio
18. Estime para evitar supresas
19. Itere o cronograma com o código
20. Deixe o conhecimento em arquivos textos
21. Use o poder das linhas de comando
22. Use BEM apenas um editor
23. Sempre use um controlador de versão
24. Resolva o problema, não a culpa
25. Não entre em pânico ao debugar
26. O problema normalmente não é no ’select’
27. Não assuma algo, prove!
28. Aprenda uma linguagem de manipulação de texto
29. Excreva código que escreva código
30. Não, você não pode escrever softwares perfeitos. Proteja o seu código.
31. Desenhe soluções baseadas em contratos
32. Pegue os problemas precocemente. Teste desde o inicio.
33. Use asserções para prevenir o impossivel
34. Use exceções apenas para o excepcional
35. Termine o que começou
36. Minimize acoplamentos entre módulos
37. Configure! Não integre!
38. Coloque abstração no código e detalhe no metadata
39. Analise o workflow para melhorar a concorrências
40. Desenhe usando serviços
41. Sempre desenhe pensando em concorrência
42. Separe a visão do modelo
43. Desenhe e conheça o fluxo da informação
44. Não programe por concidência
45. Estime a complexidade dos seus códigos
46. Teste as suas estimações em unidades reais
47. Refatore frequentemente, agora e sempre!
48. Desenvolva para os testes
49. Teste o seu software, ou os usuários testarão
50. Não use geradores de código que você não entenda o que foi gerado
51. Não apenas leia os requisitos. Mergulhe neles. Escave eles!
52. Trabalhe com um usuário para pensar como um usuário
53. Abstrações sobrevivem mais do que os detalhes
54. Crie um glossário de projeto
55. Ache, pense e pese as ‘necessidades’
56. Comece quando estiver pronto!
57. Algumas coisas são melhores prontas do que descritas
58. Não seja escravo da formalidade
59. Ferramentas caras não produzem as melhores arquiteturas
60. Organize o time por funcionalidades, e não por funções.
61. Automatize o que puder ser automatizado.
62. Teste frequentemente e automaticamente
63. Só está pronto quando o teste roda com sucesso
64. Use sabotadores para testar o seu teste
65. Não teste apenas o código. Teste as situações do domínio
66. Ache erros apenas uma vez
67. Escreva documentos com os mesmos princípios que vc escreve código
68. Não separe tanto a documentação do código
69. Exceda a espectativa do seu cliente
70. Assine o seu trabalho

PS: Qualquer duvida, só comentar que eu detalho os itens.

Comente e Recomende!!

Ainda não decidi se é com felicidade ou não que eu escrevo este post.

Felicidade de ver todo um trabalho ganhar repercussão nacional, aparecendo numa mídia de alto nível e o melhor, falando muito bem!
Por outro lado, mais uma vez, quem realmente fez isso acontecer, não apareceu…
Não tirando os méritos dos lideres, que existem, mas acho que ao menos um “graças aos nossos colaboradores” nós mereciamos. Mas faz parte. Uns fazem, outros aparecem.

Estou falando dessa matéria do jornal O Globo, do caderno de tecnologia (não se tem que estar cadastrado, mas é free).

Quatro projetos envolvendo alta tecnologia no combate e no controle do câncer estão em andamento no Rio e no Brasil. E, ao contrário do que possa parecer, trata-se de projetos de âmbito público, não privado, todos a cargo da Fundação do Câncer, que desenvolve as iniciativas para apoiar o Inca (Instituto Nacional de Câncer), hospital de referência na área, na Praça da Cruz Vermelha.

Além da simpatia da equipe, trabalhar no INCA tem um apelo que pouquissimas empresas pode trazer, que é a parte social dos produtos finais. Afinal, não estamos aqui para trazer mais clientes, pelo contrário, quanto menos melhor! Não queremos ganhar dinheiro com os produtos, pelo contrário, todas as ferramentas são para um fim privado, que indiretamente gera um valor agregado muito grande para o INCA.

Não é como trabalhar aqui ou ali, onde tudo o que é desenvolvido e criado é visando dinheiro, lucro, clientes, posições, alianças, opniões, etc. Se você pensar no resultado do produto, no fundo, estamos ajudando a muitas pessoas!

Portanto, gostaria de agradecer a todos os que trabalharam nestes projetos que me orgulho de ter, de alguma forma, ajudado a construir.

Projeto QID РQualidade da Interpreta̤̣o Diagnostica

O primeiro projeto é o desenvolvimento de um sistema para unificar as informações sobre os exames – e consequentemente diagnósticos – do câncer de mama no país.

Elizabeth Ribeiro da Silva
Evandro Ribeiro Gomes

Projeto BPW РBase de Registro Populacional de C̢ncer

Outra frente em que a tecnologia ajudará é uma espécie de “censo” da incidência de diferentes tipos de câncer na população brasileira.

Pedro Paulo dos Santos
Elaine Cristina Soares Nunes
Tiago Ribeiro de Azevedo
André Luiz Guedes

Projeto RBTMO – Registro Brasileiro de Transplante de Medula Óssea

O terceiro projeto envolvendo tecnologia e câncer diz respeito a transplantes de medula.

Shiela de Oliveira Prado
Filipe André Paes Souza

Projeto AD РAssist̻ncia Domiciliar

Finalmente, o quarto projeto usa a tecnologia dos telefones celulares para uma missão nobre: dar mais conforto a pacientes em estado terminal.

Anderson Ambrósio
Wagner Shimatai

Parabés a todos pela conquista!!!

Em um ciclo de desenvolvimento em cascata, existe um processo chamado Revisão de Código (Code Review), onde uma pessoa avalia o trabalho de outra pessoa em busca de qualidade, etc. Nas metodologias ageis, esse processo foi substituito por uma ação mais inteligente, que é a Programação em par.

Revisão de código

Sempre me perguntei:

“Como vou deixar claro pra uma pessoa no futuro que o que eu pensei foi asssim, e não assado sem usar somente a documentação?”.

Normalmente, em equipes heterogêneas no carater de senioridade, as solições podem pensar bastante diferente, fazendo com que só a documentação não seja suficiente. E esse cenário de equipes heterogêneas é o mais comum em ambientes de fabricas, onde se misturam plenos – chamados de seniors – com estagiários – chamados de juniors. Então, por ser um processo requerido – por exemplo no CMMi – um pleno desenvolve e um estagiário revisa.

Caso Veridico

Esse lance de revisão me lembra um caso acontecido com um grande amigo meu.

Lá no inicio de vida, a ‘tia’ avisa que fará o ditado do emprego de L e do U, mas que haverá uma surpresa na correção, que será feita pelo coleguinha ao lado. Pois bem, começou o ditado e André foi escrevendo:

1. Salto
2. Alto
3. Saudade
4. …

Ao fim, a professora pede pra trocar com o coleguinha ao lado e André troca com o seu amiguinho Filipe (nome fictício). Ao começar a ver o ditado, André percebe que Filipe inverteu todos os empregos de U x L, colocando Sauto, Auto, Saldade, etc. Com isso, André começou a dar errado em cada item do ditado, fazendo com que Filipe ficasse com zero. André entrega a prova a Filipe e recebe a sua. Ao ver o seu ditado, André fica indignado! Filipe corrigiu tudo como escreveu (Sauto, Auto, Saldade) dando zero para André tambem! (É mais engraçado ele contando…)

Conclusão: Pessoas de niveis diferentes não conseguem estabelecer um nivel de revisão satisfatório.

Programação em Par

Já na programação em par (Pair Programming) as duas pessoas estão no mesmo momento desenvolvendo o código, fazendo com que a conversa, as duvidas e as soluções faça o código sair da melhor maneira possivel para as duas pessoas, evitando retrabalho.

Moral da História: se fosse um ditado em par, de repente, Filipe aprenderia mais rapido e as notas seriam melhores na turma toda.

Obs.: Um ótimo post da InfoQ-Br.