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

Inheriting code… and I don’t mean classes

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.

flaper87

August 09, 2019
Tweet

More Decks by flaper87

Other Decks in Programming

Transcript

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

    Why did you leave Red Hat? I’ll buy you a coffee
  2. 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
  3. 6 The process to adopting code One step at a

    time 1 Understand what, then how, and finally why. No judging.
  4. 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?
  5. 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.
  6. 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?
  7. 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.
  8. 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.
  9. 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
  10. 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.
  11. 24 Don’t take the shortest path, aim for the fastest

    even if it ends up being the longest.
  12. 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)