Deixando código mais amigável para gerações futuras
•
1 gostou•362 visualizações
Este documento discute como deixar o código mais amigável para as próximas gerações através de documentação clara, histórico de commits explicativo, código limpo e testes claros. O autor também enfatiza a importância de merge requests construtivos para tornar o código mais compreensível, reduzir bugs e disseminar conhecimento na equipe.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (11)
Semelhante a Deixando código mais amigável para gerações futuras
Semelhante a Deixando código mais amigável para gerações futuras (20)
Mais de fabio perrella
Mais de fabio perrella (7)
Deixando código mais amigável para gerações futuras
- 1. Deixando o código mais amigável para as próximas gerações
- 2. Fabio Perrella Eng. Computação Poli 2004 Líder Técnico @ Locaweb
- 3. - Líder em Hosting no Brasil - Eleita umas das melhores empresas para se trabalhar - https://www.locaweb.com.br/carreira/
- 4. Como ter assunto para fazer uma palestra?
- 7. 2017 2016
- 10. Como deixar o código mais amigável para as próximas gerações!
- 11. Agenda - Introdução - Documentação - Histórico de commits - Clareza do código - Testes claros - Merge requests construtivos
- 12. Por que falar desse assunto?
- 13. Migração de sistemas legado para novo Sistema Legado - Dificuldade pra entender - Medo de alterar Sistema novo - Fácil de alterar - Uso de tecnologias novas - Mas….. Pode virar o legado de amanhã! (literalmente)
- 15. Tomdoc - tomdoc.org Padrão para documentação de métodos para Ruby
- 17. asciiflow.com
- 19. Documente códigos sem contexto
- 21. Keepachangelog.com Documentação de gems - Ajuda muito na hora de precisar atualizar de uma versão X para Y
- 23. Documente tudo que possa gerar dúvidas
- 25. Clean Code Uncle Bob Código claro > Comentários
- 26. Clean Code - Necessary Comments http://blog.cleancoder.com/uncle-bob/2017/02/23/NecessaryComments.html “But it does happen; and when it does nothing can be more helpful than a well written, well thought through, comment.”
- 28. Contando a história do código através dos commits https://about.futurelearn.com/blog/telling-stories-with-your-git-history/
- 29. Commits atômicos “The smallest amount of code changed which delivers value”
- 30. Explicar o porquê e não só o “como” Padrão para commits: http://chris.beams.io/posts/git-commit
- 31. Utilize o corpo do commit para explicar o porquê
- 32. Remover commits de wip, typo, fix, etc.. $ git rebase -i master (usando squash)
- 33. Preferir rebase para atualizar feature branches Merge só quando for mergear o MR
- 34. Commit --fixup para atualizar commit antigo https://robots.thoughtbot.com/autosquashing-git-commits
- 35. git add . git commit --fixup add92db
- 36. git rebase -i --autosquash HEAD~6
- 38. Cuidado com excesso de indireções Indireção: despachar uma mensagem através de um intermediário https://jaysoo.ca/2015/11/21/avoid-unnecessary-indirection/ Clareza SOLID DRY
- 41. Perguntas para avaliar um código - O quão difícil foi para se escrever? - O quão difícil é para se entender? - Quando custará para alterar? O quão difícil é responder perguntas sobre o domínio olhando o código? - Quais são os estados de um farol? - Qual a sequência de cores do farol? Extraído do livro “99 bottles of OOP - Sandi Metz”
- 43. Evitar o uso de includes Composição > Includes !
- 44. Module prepend para ações secundárias (ex: logs) http://gshutler.com/2013/04/ruby-2-module-prepend/
- 48. Module prepend Vantagens sobre a gem aspector: - fica explícito no código! - aparece no stacktrace explicitamente em caso de exceção
- 49. Mais clareza com keyword arguments http://gshutler.com/2013/04/ruby-2-module-prepend/
- 54. Remoção de código obsoleto gem debride https://github.com/seattlerb/debride
- 58. Proposta
- 59. Proposta - Não se importe muito com DRY. Caso se importe, prefira uso de métodos - Evite o uso de LETs e BEFOREs - Tudo bem colocar mais de 1 expect dentro dos ITs - Separe em 3 blocos: setup, exercise e verify http://blog.locaweb.com.br/geral/melhorando-o-entendimento-de-testes-com-rspec
- 61. Merge requests construtivos - Torna o código mais entendível - Reduz chance de bugs - Espalha conhecimento entre membros - Serve de referência para futuras consultas Sugestão: definir um Guideline!