Git Driven Refactoring - Speaker Deck

Slide 1

Slide 1 text

Git Driven Refactoring

Slide 2

Slide 2 text

Ashley Ellis Pierce  Application Engineer @ GitHub @aellispierce

Slide 3

Slide 3 text

Refactoring?

Slide 4

Slide 4 text

Changing the structure of existing code without modifying it’s behavior

Slide 5

Slide 5 text

We make mistakes

Slide 6

Slide 6 text

Where we went wrong -> Where we need to be

Slide 7

Slide 7 text

Design problem -> Refactoring technique

Slide 8

Slide 8 text

Design problem -> Refactoring technique

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

S.O.L.I.D  principles

Slide 11

Slide 11 text

S.O.L.I.D  Single Responsibility Principle

Slide 12

Slide 12 text

Single Responsibility Principle A class should have only one reason to change. 

Slide 13

Slide 13 text

S.O.L.I.D  Single Responsibility Principle Open/Closed Principle

Slide 14

Slide 14 text

Open/Closed Principle A class should be open for extension but closed for modification. 

Slide 15

Slide 15 text

S.O.L.I.D  Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle

Slide 16

Slide 16 text

Liskov Substitution Principle Every subclass/derived class should be substitutable for their base/parent class. 

Slide 17

Slide 17 text

S.O.L.I.D  Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle

Slide 18

Slide 18 text

Interface Segregation Principle No client should be forced to depend on methods it does not use.

Slide 19

Slide 19 text

S.O.L.I.D  Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle

Slide 20

Slide 20 text

Dependency Inversion Principle Entities must depend on abstractions, not concretions.

Slide 21

Slide 21 text

Easier to understand Easier to change. SOLID code is:

Slide 22

Slide 22 text

We’re done!

Slide 23

Slide 23 text

… not quite. We’re done!

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

You can’t recognize design patterns in isolation, you need context.

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

S.O.L.I.D  principles

Slide 32

Slide 32 text

Single Responsibility Principle

Slide 33

Slide 33 text

Single Responsibility Principle A class should have only one reason to change. 

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Why has my class changed recently?

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

git log app/models/engine.rb

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

git log app/models/engine.rb

Slide 46

Slide 46 text

git log app/models/engine.rb

Slide 47

Slide 47 text

Power Remote Start

Slide 48

Slide 48 text

git log app/models/engine.rb

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

Git as documentation

Slide 51

Slide 51 text

Git as documentation

Slide 52

Slide 52 text

git log app/models/engine.rb

Slide 53

Slide 53 text

Open/Closed  Principle

Slide 54

Slide 54 text

Open/Closed Principle A class should be open for extension but closed for modification. 

Slide 55

Slide 55 text

How do you extend something without modifying it?

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

You’re doing amazing sweetie

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

You shouldn’t have to change existing code to add new functionality

Slide 61

Slide 61 text

When adding features, there should be no red in the diffs

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

Consistent style matters

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

Liskov  Substitution  Principle

Slide 66

Slide 66 text

Liskov Substitution Principle Every subclass/derived class should be substitutable for their base/parent class. 

Slide 67

Slide 67 text

You should be able to call the same method on a subclass as you could on a parent and get a compatible result

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

is_a? respond_to?

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

Let bots do the nagging for you.

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

Interface  Segregation  Principle

Slide 75

Slide 75 text

Interface Segregation Principle No client should be forced to depend on methods it does not use.

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

No content

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

Interface Segregation Principle Many small client-specific interfaces are better than one large general purpose interface

Slide 81

Slide 81 text

Can you violate Interface segregation in Ruby?

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

No content

Slide 84

Slide 84 text

Java Fake Typed Ruby

Slide 85

Slide 85 text

No content

Slide 86

Slide 86 text

No content

Slide 87

Slide 87 text

No content

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

No content

Slide 91

Slide 91 text

No content

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

You CAN violate ISP in Ruby

Slide 95

Slide 95 text

You CAN violate the spirit of ISP in Ruby

Slide 96

Slide 96 text

Small Client-specific interfaces > Large general-purpose interfaces

Slide 97

Slide 97 text

https://freephotos.cc/image/5a1d48dc4bf957c95a7e32ac30c60f3e

Slide 98

Slide 98 text

git log --grep “CsvAircraft”

Slide 99

Slide 99 text

Dependency   Inversion  Principle

Slide 100

Slide 100 text

Dependency Inversion Principle Entities must depend on abstractions, not concretions.

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

No content

Slide 103

Slide 103 text

No content

Slide 104

Slide 104 text

No content

Slide 105

Slide 105 text

Recap

Slide 106

Slide 106 text

How can Git help you refactor?

Slide 107

Slide 107 text

Use the git log to group commits into topics and recognize when a class is doing more than one thing

Slide 108

Slide 108 text

Keep an eye out for red in the diff when you're adding functionality, this could indicate a violation of the Open/Closed principle

Slide 109

Slide 109 text

Integrate tools like automatic style linters with your GitHub account to make code cleaner and easier to recognize problems

Slide 110

Slide 110 text

Use git log and git blame to find how often classes or methods have had to change. This tells you where your worst offenders most in need of refactor are.