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.

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!