Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Day #1


  • Concerns/Mixins vs. Explicit classes for business logic

    • Cons for Concerns:
      • Concern will grow in responsibility and behavior
      • Concerns across repos are hard to manage
      • "floating" methods are implicit
      • Poor naming standards across teams. The behavior encompassed in a concern is not explicit. e.g. CaseStatusConcern could be improved by CaseStatusFetchable
    • Pros for Concerns:
      • If we established a naming convention such as "#{behavior}able" (e.g. Taggable, Discountable, Uploadable) then some of the cons of using concerns can be alleviated
      • Concerns folder makes it easier to identify code as opposed to creating explicit objects and putting them in app/models
  • Recommendations

    • Establish guidelines for when to use a concern vs a plain ruby object
    • Agree on a folder structure for plain ruby objects
    • Revisit existing Concerns and potentially rename them or extract them into POROs (Plain Old Ruby Object)

DAY #2

Discussed: - Dependency Injection -Cons for DI -Takes more code -More complex than calling explicitly calling methods - Might be unessesary -Pros for DI -Makes code more flexible -Makes testing easier(No need for webmock) - Recommendations - People should know that DI is an option in ruby - If the reccomendation to use modules less is taken, there will be many more oportinities to use DI - DI shoudl be used on application external dependencies

Day #3


  • Class Inheritance Pros and Cons

  • Cons for Inheritance

    • When inheriting more than one level, it can become a convoluted path to follow to identify a method being invoked
    • We don't get an immediate overview of what methods, callbacks, and instance variables are defined when looking at the child class
    • Callbacks can get invoked "mysteriously" when they are higher up the inheritance chain and unknown to the child
  • Pros for Inheritance

    • DRY's up the code
    • Ensures consistency of doing things across child classes
    • By declaring empty methods with raise in the base class, we can create a de-facto interface
  • Recommendations

    • Inheritance is good and should be used
    • Ensure when declaring base classes that any methods that need to be defined in the child classes are defined in the parent with raise exceptions to notify developers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment