Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Inheriting code… and I don’t mean classes

C05edcc8a57f64b4e040d94ad89cee57?s=47 flaper87
August 09, 2019

Inheriting code… and I don’t mean classes

One of the hardest things to do for developers, especially freelancers, is to inherit someone else’s code. Let alone doing it when the original author is not around anymore. Whether it’s an open source project, an internal project, or some small web page that your best friend asked you to fix. Code that has not been written by us is always ugly, not performant, and broken.

* How does one go about inheriting other people's code?
* How do you wrap your head around the (wrong?) ideas, the (flawed?) logic, and the (lack of?) taste of * other developers(?)?
* How can you take such code, make it yours, make it better, and sprinkle your fairy dust all over it? Also, do you really write better code? ;)

Join me while I share some of my experience on this topic, some strategies to inherit old code without (totally) going mental, and how to rant about it without looking like a douchebag.

C05edcc8a57f64b4e040d94ad89cee57?s=128

flaper87

August 09, 2019
Tweet

Transcript

  1. 1 Me: @flaper87 Slides: https://s.f87.me/2M8sxUE Inheriting code… and I don’t

    mean classes
  2. 2 2 Flavio Percoco @flaper87 Elastic Inc

  3. 3 3 Wait, did you say Elastic? Yes, I did.

    Why did you leave Red Hat? I’ll buy you a coffee
  4. 4 Inheriting stuff from someone that hated you

  5. 5 The sad story • There is no documentation •

    There are no tests • Code is written poorly • Use cases are unclear • Deadlines are around the corner
  6. 6 The process to adopting code One step at a

    time 1 Understand what, then how, and finally why. No judging.
  7. 7 The what, the why, the how What How Why

    • What are the use cases? • What is the adoption? • What is the planned work? • What has been done already? • How were things done? • How was the software written? • Why was it written this way? • Why are tests missing? • Why is the documentation missing?
  8. 8 A mature developer seeks for the why before judging

    the how
  9. 9 The process to adopting code One step at a

    time 1 2 Understand what, then how, and finally why. No judging. Familiarize yourself with the environment, user base, evaluate rewrite.
  10. 10 10 Learn how users are consuming the software

  11. 11 11 Run the software, use it. Leave changes for

    later
  12. 12 12 Read the documentation, the code, and everything there

    is.
  13. 13 Evaluate rewrite 99.9% of the times it’s not needed

    • Are you familiar with the language and the ecosystem? • Would a rewrite be faster? • Would a rewrite make it easier to maintain? • Would a rewrite have side-effects on the users? • Will other members of the team be able to contribute?
  14. 14 The process to adopting code One step at a

    time 1 2 3 Understand what, then how, and finally why. No judging. Familiarize yourself with the environment, user base, evaluate rewrite. Build your guarantees first, refactor or implement next.
  15. 15 15 If there are no guidelines, write them.

  16. 16 16 Document everything: usability, API, environment.

  17. 17 17 All existing tests must pass. Write them if

    they don’t exist.
  18. 18 The process to adopting code One step at a

    time 1 2 3 4 Understand what, then how, and finally why. No judging. Familiarize yourself with the environment, user base, evaluate rewrite. Build your guarantees first, refactor or implement next. Break down your strategy. Small and focused changes.
  19. 19 19 One small change at a time

  20. 20 20 Focus on progress, not perfection.

  21. 21 21 Don’t change functionality during a refactor

  22. 22 The process to adopting code One step at a

    time 1 2 3 4 5 Understand what, then how, and finally why. No judging. Familiarize yourself with the environment, user base, evaluate rewrite. Build your guarantees first, refactor or implement next. Break down your strategy. Small and focused changes. Get paid and run… far… fast
  23. 23 The process to adopting code One step at a

    time 1 2 3 4 5 Understand what, then how, and finally why. No judging. Familiarize yourself with the environment, user base, evaluate rewrite. Build your guarantees first, refactor or implement next. Break down your strategy. Small and focused changes. Repeat 3 and 4! Congratulations, you have a new baby.
  24. 24 Don’t take the shortest path, aim for the fastest

    even if it ends up being the longest.
  25. 25 * Some highlights You can go now :) Understand

    the what, the why, and the how * * * * Build your guarantees before changing the software Focus on progress, not perfection Know who the consumers are Document everything (API, architecture, environment, code)
  26. 26 THANKS!