Skip to content

Instantly share code, notes, and snippets.

@ecuageo
Created September 6, 2017 18:11
Show Gist options
  • Save ecuageo/cda05f25ab13d787c3e9529c989d6041 to your computer and use it in GitHub Desktop.
Save ecuageo/cda05f25ab13d787c3e9529c989d6041 to your computer and use it in GitHub Desktop.

A livable codebase

Some context, my journey

Two Concerns:

  1. Almost all codebases become a royal pain to work with overtime
  2. We don't come close to agreeing on the solution

To avoid some assumptions

  • Is the first concern really a problem?

  • Do you feel confident in your efforts?

  • Do you feel like it's ok for our code to rot, because "We'll rewrite it anyway"?

  • Assuming the first is a problem, is there a solution we can agree on?

    • finding material was hard
    • every community is different (the 4 minute mile)
  • Have you worked on a codebase that was mature and was a joy to work with?

Qualities of a Livable Codebase

  • simple
    • how much mental juggling?
  • discoverable
    • can I move around in the code and find what I expect?
  • clear & discernible abstractions
    • absent abstraction (or cohesion) you get coupling
    • the car abstraction and the leaking abstraction
    • coupling is dependency, dependency is volatile
    • leveraging others abstractions, can we do the same? ok or not?
  • bug-free
  • tested
  • easy to test

What are the qualities you see that make a codebase livable?

Programming Paradigms

Refactoring is a thing

  • not just moving code around
  • having specific reasons to change (defensible)
  • the process
    • shameless green
    • smells
    • "refactorings"
    • patterns
    • tests
    • small increments

Domain Driven Design

OO

  • what is SRP?
  • what is encapsulation?

FP

  • abstracting out imperative code
  • too scandalous to print!!

Team/Organization Strategies

Buying time

  • showing the business a plan
    • show you can do it
    • how long?
    • what result?
    • I've never been told know, which means it's on us
  • A plan for tech debt
    • ok to create debt in the beginning?
    • when is the right time to clean up?
    • can we spread the cost of new technologies?
  • proof is in the pudding
    • why the business is hesitant
    • what we can do about it

The art of persuasion

  • POC's
  • Presentations
  • Pair Programming
  • By example
  • respect and humility
  • consensus
  • commitment

Automation

  • style guides
  • CD/CI
  • code coverage

Design Discussions

  • code review
  • retrospectives
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment