Compartilhando algumas experiências sobre armadilhas encontradas durante o processo de desenvolvimento de software

1. Armadilhas no Desenvolvimento
de Software
Jamerson Lima
Software Developer

2. Quem sou eu
• Natalense
• Engenheiro de Computação – UFRN 98
• 10+ de programação
• Clipper, Pascal, C, C++, Delphi, PHP, Perl, C#, Java, Ruby, Python...
• IBMista a ~1 ano
• Desenvolvimento do Maximo Scheduler+
• Grupo de CD e Unit Tests

3. Computação Ontem e Hoje
Console do operador do IBM 701, autor da foto: Dan (Flicker)
Emulador de dBase:
https://archive.org/details/msdos_shareware_fb_DR
EPORT

4. Computação Ontem e Hoje
Fonte:
http://www.informatio
nisbeautiful.net/visualiz
ations/million-lines-of-
code/

5. Computação Ontem e
Hoje
Fonte:
http://www.informationisbeautif
ul.net/visualizations/million-lines-
of-code/

6. Computação
Ontem e Hoje
Fonte:
http://www.informationisbeautiful.n
et/visualizations/million-lines-of-
code/

7. O que são essas armadilhas
1. Público ignorado
2. Procedimentos
1. Não priorizados durante o planejamento
2. ignorados durante o desenvolvimento
3. Por que é uma armadilha:
• Complexidade de desenvolvimento aumenta
• Não vende
• Maior esforço de testes
• Maior Infraestrutura
• Apoio especializado
• Não está no radar das pessoas envolvidas
Retrabalho

8. O que vou falar
• Baseadas em experiência e ensinamentos
• Não são verdade absolutas
• Ponto de vista para consideração
• Dicas do que ficar de olho

9. Acessibilidade
• Dados do IBGE revelam que 6,2% da população brasileira tem algum
tipo de deficiência. (~12,4 milhões de pessoas)
• Dentre os tipos de deficiência pesquisados, a visual é a mais
representativa e atinge 3,6% dos brasileiros, sendo mais comum entre
as pessoas com mais de 60 anos (11,5%).
Fonte: http://www.ebc.com.br/noticias/2015/08/ibge-62-da-populacao-tem-algum-tipo-de-deficiencia

10. Acessibilidade
• População envelhece e adoção da tecnologia aumenta.
• Deficiência temporária não é considerada.

11. Acessibilidade
• O que fazer?
• Conheça as deficiências e como elas podem afetar o uso de aplicações
• Empresas especializadas
• Suporte de Sistemas Operacionais, HTML, iOS, Android, ...
• Testes de acessibilidades
• Usuários alpha, beta com deficiências

12. Internacionalização
• Que língua seus usuários falam?
• Aplicações são globais
• Sua aplicação suporta uma mudança de idioma?
• E escritas com diferentes direcionalidades?

13. Internacionalização
• O que fazer?
• Serviços de tradutores
• Bateria de testes em diferentes idiomas
• Testem as mensagens de erro
• Conheça o suporte das plataformas utilizadas

14. Internacionalização
O projeto que parou antes de começar por causa do Japonês (não o da
Federal)

15. Baixa Conectividade
• Como sua aplicação se comporta no mundo real?
• Ambiente de desenvolvimento x mão do usuário
• 3G, Edge, GPRS...
• Conexão intermitente
• Não estamos mais programando apenas para computadores de mesa

16. Baixa Conectividade
• O que fazer?
• Não deixe sua aplicação travar
• Tratamentos de chamadas assíncronas: Promises, Futures
• Dê opção de cancelamento da requisição
• Realize testes com baixa conectividade
• Carregue os dados por partes
• O mais importante, antes
• Cache offline, salve para mais tarde

17. Baixa Conectividade
Enviar
A operação está
levando mais tempo
do que deveria.
Cancelar
Suas informações foram
salvas para serem enviadas
mais tarde.
EnviarEnviar
Salvando dados
Cancelar

18. Massa de Dados
O caso da página que levava 20 minutos para abrir

19. Massa de Dados
• Qual a ordem de magnitude da quantidade de dados sua aplicação
suporta?
• 10 registros, 100 registros, 10000 registros
• Se não há limites, quer dizer que há um limite e você não sabe qual é

20. Massa de Dados
• O que fazer?
• Além das dicas de Baixa Conectividade.
• Não comece otimizando.
• Esteja ciente da necessidade.
• Teste de carga com dados falsos.
• Questione quanto de dados determinada tela ou funcionalidade vai precisar
processar.
• Ninguém vai saber responder, então estime ordem de magnitude.

21. Massa de Dados
O caso da agulha no palheiro

22. Refatoração
• Ninguém é perfeito na primeira iteração
• O mundo muda e os requisitos também
• Não existe código perfeito
• Não existe dono do código

23. Refatoração
• O que fazer?
• Revise o seu código
• Revise o código do parceiro
• Programe em pares
• Revise em pares
• Fique atento ao code smells
• Sugira mudanças
• Use ferramentas de análise de código, trace objetivos
• Abra tickets para futuros refatoramentos

24. Refatoração
”A cada Sprint, uma história de refatoração”

25. Testes automatizados
• Quantos testes automatizados existem na sua aplicação?
• Prova que funciona
• Melhora seu design
• Documentação
• Traz paz de espirito durante o refatoramento

26. Testes automatizados
• O que fazer?
• Conheça as técnicas
• TDD
• Red-Green-Refactor
• Aplique no seu dia a dia
• Não precisa de aprovação gerencial
• O tempo usado na criação dos testes vai ser recuperado no futuro

27. Testes automatizados
O caso da marca de 98% e da malandragem

28. Logs e Relatórios
• O que sua aplicação faz quando falha catastroficamente?
• Sua aplicação vai quebrar em produção
• O usuário vai fazer um fluxo inesperado
• A sua aplicação vai fechar na cara do seu usuário
• Falhe com elegância

29. Logs e Relatórios
• O que fazer?
• Tenha uma forma de habilitar criação de log
• Gere relatórios com os erros
• Tem que ser amigável

30. Logs e Relatórios
O caso do erro erro trolador

31. Privacidade
• Como sua aplicação trata os dados de seus usuários?
• Manipulamos dados sensíveis
• Ética e Responsabilidade são necessários
• Como a informação é enviada, recebida e armazenada?
• Você realmente precisa de todas essas informações?
• Como você armazena senhas? Como elas são recuperadas?
• Você realmente precisa da localização? E do acesso as fotos?

32. Privacidade
• O que fazer?
• Trabalhe perto da equipe de segurança da informação
• Criptografe dados sensíveis (ou melhor, nem guarde)
• Use embaralhadores de dados
• Seja claro quando pedir algum tipo de acesso: Porquê? Por quanto tempo?
• Tenha claro e sucinto a política de uso de dados sensíveis.

33. Conclusão
• Mundo real é mais complicado
• Sempre existirão concessões
• Planejamento de um projeto é um cabo de guerra
Perguntas?
Contato:
Email: jraposo@br.ibm.com
Twitter: @jamersonlima