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
   

   View Slide

2. 2
   2
   Flavio Percoco
   @flaper87
   Elastic Inc
   

   View Slide

3. 3
   3
   Wait, did you
   say Elastic?
   Yes, I did.
   Why did you
   leave Red Hat?
   I’ll buy you a
   coffee
   

   View Slide

4. 4
   Inheriting stuff
   from someone that hated you
   

   View Slide

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
   

   View Slide

6. 6
   The process to adopting code
   One step at a time
   1
   Understand what,
   then how, and finally
   why. No judging.
   

   View Slide

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?
   

   View Slide

8. 8
   A mature developer seeks for the
   why before judging the how
   

   View Slide

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.
   

   View Slide

10. 10
    10
    Learn how users are
    consuming the software
    

    View Slide

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

    View Slide

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

    View Slide

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?
    

    View Slide

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.
    

    View Slide

15. 15
    15
    If there are no guidelines,
    write them.
    

    View Slide

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

    View Slide

17. 17
    17
    All existing tests must pass.
    Write them if they don’t exist.
    

    View Slide

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.
    

    View Slide

19. 19
    19
    One small change at a time
    

    View Slide

20. 20
    20
    Focus on progress, not
    perfection.
    

    View Slide

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

    View Slide

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
    

    View Slide

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.
    

    View Slide

24. 24
    Don’t take the shortest path, aim
    for the fastest even if it ends up
    being the longest.
    

    View Slide

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)
    

    View Slide

26. 26
    THANKS!
    

    View Slide