O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Reading source code is usually underestimated by many developers and AQA engineers as they are mostly focused on writing it.
Moreover, some people find reading someone else’s code boring, frustrating or even creepy. Others consider this activity a waste of time.
However, this is a common misconception which must be cleared. Do you want to know why? Are you still wondering how to master the art of reading code? Then come and hear it! This talk will be helpful for newbies who got stuck and don’t know how to start reading and understanding someone else’s code, as well as for professionals who want to structure their knowledge and learn some new patterns.
QA Fest 2019. Сергей Король. Mastering the Art of Reading Code
MASTERING THE ART OF
AQA Geek, mentor,
speaker, consultant and
• Technical QA Manager
• Consultant: http://sdclabs.com
• GitHub contributor: sskorol
• Email: email@example.com
• Twitter: @ss_korol
WHO AM I?
701 contributions in the last
HOW MUCH SHOULD I READ A
THE PAOMNNEHAL PWEOR OF
I cna elasiy rade tihs ifrontamoin.
It manes taht oru barin has
amiznag pewor! As I culod raed
scuh pecie of txet woihtut ayn
porlebm, I nac laren woh to rade
ceod as wlel. Tsurt yuro biran adn
it wlil ecixte yuo!
• Learn common design patterns
• Locate common patterns in existing
• Focus on your daily reading style and
find out how does your brain optimize
different code parts
• Coding standards are finalized
• Git flow is selected / hooks are configured
• Branch / commit message conventions are
• Key branches are protected
• Minimal amount of approvers is set
• Code owners are assigned
• Required checks are integrated into dev
ToDo before code review integration:
DOWN THE RABBIT HOLE
• The code is well-designed
• The functionality is good for users of the code
• The code isn’t overcomplicated
• There’s no code “for future” if it’s not required
• Tests are present and well-designed
• The code conforms style guides and name
ToDo while reviewing someone
DOWN THE RABBIT HOLE
• Keep reading code to improve
• Collect metadata to reduce
• Practice abstract thinking
• Learn existing / highlight new