Skip to content

Instantly share code, notes, and snippets.

@monfresh
Last active May 31, 2023 18:55
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save monfresh/3165bc6dd9d17d76c237cb8f6af8615f to your computer and use it in GitHub Desktop.
Save monfresh/3165bc6dd9d17d76c237cb8f6af8615f to your computer and use it in GitHub Desktop.
Wisdom Wednesday - Refactoring

Intros

Code Climate guidelines

  • If PR is urgent, ask a GitHub repo admin to approve in Code Climate, then immediately fix the offenses. Don't open a new ticket.
  • If PR is not urgent, take the time to understand the issue and fix it, unless it's a false positive.
  • Walk through reading up on offense in CC

OO principles

Sandi Metz

  • https://www.sandimetz.com/blog/2009/06/12/ruby-case-statements-and-kind-of
  • It is not the job on any object to tell any other object how to behave.
  • Objects create behavior by passing messages back and forth. They tell each other what, not how.
  • What is the event/notification/request and it is the responsibility of the sender.
  • How is the behavior/implementation and it should be completely hidden in the receiver.
  • Each object knows its own implementation and it exhibits that behavior when it receives a message.
  • No object in your system should have to know the class of any other object in order to know how to behave. Everything is a Duck. Tell the Duck what and the Duck should know how.
  • The last object that could possibly receive the message is the object that should implement the behavior.

Kevin Berridge

  • https://vimeo.com/91672848
  • The only thing an object can do with another object is send it a message
  • The only thing an object can know about another object is what messages it accepts
  • Message describes the what, and hides the how
  • To control complexity, one must embrace simplicity
  • Traffic light example: all it knows about is its current color state and the passage of time. It doesn't know anything about what type of intersection, vehicles, etc.
  • End goal: malleable, extensible, reusable, simple
  • Blind trust: allows objects to collaborate without binding themselves to context and is necessary in any application that expects to grow and change.
  • OO design requires that you shift from thinking of the world as a collection of predefined procedures to modeling the world as a series of messages that pass between objects.

Examples

AppealEvents

Why is code not OO?

  • Adding a new appeal type will require modifying the all method, leading to Divergent Change.
  • The logic and data for combining the events for each appeal type is jammed into one class, resulting in a Large Class
  • AppealEvents should not know how LegacyAppeal implements all
  • Tell, Don't Ask
  • AppealEvent takes in different arguments at different times: hearing, type, disposition

Benefits of refactoring

  • Reveals unused code: AppealEvent#to_hash, calling to_hash in V2::LegacyAppealStatusSerializer#events
  • Code is easier to read
  • Makes testing easier, not clear where everything is tested. For example, supplemental claims tested in spec/feature/api/v2/appeals_spec.rb
  • Reveals missing specs: appeal_events_spec was only testing legacy appeals
  • Reveals code in AppealEvent that only applies to legacy appeals and can be extracted out: disposition=, issue_disposition=
  • date, type Data Clump or Parameter Object

Code smell examples

Special Case Pattern

https://www.rubytapas.com/2013/07/01/episode-112-special-case/

Null Object Pattern

https://thoughtbot.com/upcase/videos/live-coding-session-replace-conditional-with-null-object https://www.sandimetz.com/blog/2014/12/19/suspicions-of-nil

  • Avoid try

Concerns

  • Moving lines from a class into a concern and the including the concern back in the class (shoving under the rug)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment