5 ways to make your codebase withstand the test of time

We are on a never-ending quest to find better tools and patterns, but does that mean our code is doomed to become old and wrinkly?

1. Split your code based on domain concepts, not tech concepts

# Split by tech concepts        # Split by domain concepts|- src                          |- auth
| |- controllers | |- controllers
| | |- auth | |- models
| | |- profile | |- views
| | |- article | |- tests
| |- models |- profile
| |- views |- article
|- test (...)
| |- controllers
| | |- auth
(...)

What is easier to maintain, a codebase with 10 files or one with 100 files?

2. Provide a public contract (API) for all your domain concepts

3. Rely on small interfaces

production = Payments.new(
event_publisher: rabbitmq,
event_subscriber: rabbitmq_replicas,
credit_card_charger: stripe,
email_sender: mailgun,
)
development = Payments.new(
event_publisher: in_memory_bus,
event_subscriber: in_memory_bus,
credit_card_charger: stripe_test_mode,
email_sender: muted_mailer,
)

4. Decouple your data from your storage strategy

class Article < ActiveRecord::Base
belongs_to :user
has_many :comments, dependent: :destroy
scope :authored_by, ->(username) { where(user: User.where(username: username)) } validates :title, presence: true, allow_blank: false
validates :body, presence: true, allow_blank: false
before_validation do
self.slug ||= “#{title.to_s.parameterize}-#{rand(36**6).to_s(36)}”
end
end

5. Use events to keep your application connected and your code decoupled

article_published(…) 1 minute ago
article_draft_created(…) 5 minutes ago
user_signed_in(…) 25 minutes ago

Event-driven programming avoids long functions with many different side effects, and makes your tests nicer and more isolated.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store