Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Reading Other Peoples Code (Web Rebels 2018)

594 views

Published on

Someone else's code. Even worse, thousands of lines, maybe hundreds of files of other peoples code. Is there a way to methodically read and understand other peoples work, build their mental models? In this talk I will go through techniques I have developed throughout 18 years of programming. Hopefully you will walk away with a plan on how to approach a new code base. But even more I hope you walk away with a feeling of curiosity, wanting to get to know your fellow programmers through their code.

Published in: Technology
  • Be the first to comment

Reading Other Peoples Code (Web Rebels 2018)

  1. 1. @pati_gallardo
  2. 2. Reading Other People's Code @pati_gallardo Patricia Aas Web Rebels 2018
  3. 3. Patricia Aas - Vivaldi Browser Programmer - mainly in C++ Currently : Vivaldi Technologies Previously : Cisco Systems, Knowit, Opera Software Master in Computer Science - main language Java Twitter : @pati_gallardo
  4. 4. - So… You Got Someone Else’s Code? - Before You Start - 10 Techniques - Different is Good @pati_gallardo
  5. 5. @pati_gallardo So… You Got Someone Else's Code?
  6. 6. This is not a code review @pati_gallardo
  7. 7. Code is the serialized version of a mental machine @pati_gallardo
  8. 8. What We Are Lacking Is: The Mental Model What we are faced with is: pages and pages of code. This is fine @pati_gallardo
  9. 9. @pati_gallardo Before You Start
  10. 10. #preperation - Get the code - Put it in source control - Put it in a “smart” IDE - Try to build it - Try to run it - Preferably in a debugger @pati_gallardo
  11. 11. Browsers are MASSIVE Vivaldi: 600,000 files @pati_gallardo
  12. 12. @pati_gallardo 10 Techniques That Will Help You Understand Other People’s Code
  13. 13. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  14. 14. @pati_gallardo 1. Grepping
  15. 15. Strings you see as ends to pull on - in the GUI - on the commandline - in the logs @pati_gallardo
  16. 16. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  17. 17. @pati_gallardo 2. Where Is This Button?
  18. 18. - Grep for the button text - Find the button - Set a breakpoint on onClick - Click on the button - Look at the stack - Traverse up the widget hierarchy @pati_gallardo
  19. 19. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  20. 20. @pati_gallardo 3. Following Inputs Events
  21. 21. Investigating Your GUI framework - Trace platform events - Look at graphics output - Find the platform integration architecture @pati_gallardo
  22. 22. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  23. 23. @pati_gallardo 4. What Do The Tests Do?
  24. 24. Integration / System Tests - How to run it - Use Cases - Write tests to drive the code you’re looking at - Write tests to examine your assumptions @pati_gallardo
  25. 25. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  26. 26. @pati_gallardo 5. Refactoring
  27. 27. Refactoring is Opinionated: Don’t get attached This is throw-away code @pati_gallardo
  28. 28. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  29. 29. @pati_gallardo 6. Reading “main”
  30. 30. The How Execution Architecture - Mainloop & event handling - Read top to bottom - Take notes & draw - Important objects/functions - Watch for common types - Recurse@pati_gallardo
  31. 31. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  32. 32. @pati_gallardo 7. The Graphical Layout
  33. 33. - Find the Main Layout - Find the (implicit) State Machine - This is what changes the window contents - Maps often to Use Cases @pati_gallardo
  34. 34. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  35. 35. @pati_gallardo 8. Runtime Investigation
  36. 36. Rough Outline of Architectures - Event driven : main loop, async, event handlers - Request handling : one thread per request - mostly synchronous - Command line tool : mostly synchronous, takes input, produces output @pati_gallardo
  37. 37. - Use the debugger to examine runtime state and stacks - Read the logs to see flow - Run the tests - Add logging - Add tests and assertions - Add a feature@pati_gallardo
  38. 38. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  39. 39. @pati_gallardo 9. Reading A “Class”
  40. 40. - Which interfaces does it implement? - Who uses it and how? - Public functions are the “mains” of a class (Getters don’t count) @pati_gallardo
  41. 41. 1. Grepping 2. Where is this button? 3. Following input events 4. What do the tests do? 5. Refactoring 6. Reading “main” 7. The graphical layout 8. Runtime Investigation 9. Reading a class 10. Retelling or Rubber Ducking@pati_gallardo
  42. 42. @pati_gallardo 10. Retelling or Rubber Ducking
  43. 43. Explain It To Someone Write a (fictional) blog post Write some documentation Make an internal prestation (Ducks aren't very motivating)@pati_gallardo
  44. 44. @pati_gallardo Conclusion : Different Is Good
  45. 45. Great code should be personal We want people to take pride in their work Learn to appreciate other people's code Style is individual @pati_gallardo
  46. 46. Make Everyone Feel Safe To Be Themselves @pati_gallardo
  47. 47. @pati_gallardo
  48. 48. Vivaldi Swag Patricia Aas, Vivaldi Technologies @pati_gallardo Photos from pixabay.com
  49. 49. Don’t be tempted to criticize If only… it were different... No. Breathe and accept @pati_gallardo
  50. 50. #philosophy Running code is not linear, reading code cannot be linear either. @pati_gallardo
  51. 51. #goals - Establishing a vague outline and fleshing it out in an iterative process - Taking notes and drawing - Make documentation - Teach others @pati_gallardo
  52. 52. Code is like Balls of Yarn on the FLoor It’s a mess. How do you know where to begin? Find an interesting end: Pull on it @pati_gallardo
  53. 53. Refactoring is opinionated Use it to understand, throw it away and go back to the original code Do not judge @pati_gallardo
  54. 54. You Need a Full Toolset For synchronous execution the debugger is useful For async the log will yield interesting places @pati_gallardo
  55. 55. If you approach other people's code wanting to learn: You will learn If you approach to criticize: You will criticize @pati_gallardo
  56. 56. “Instead of condemning people, let’s try to understand them. Let’s try to figure out why they do what they do. That’s a lot more profitable and intriguing than criticism; and it breeds sympathy, tolerance and kindness.” Dale Carnegie, How to Win Friends & Influence People @pati_gallardo

×