Clippings of 2019 Nov
I'm super excited after reading this article, because it summarizes the ideal application architecture based on my current understanding, and I can't explain it better than Aaron.
Abstracting by layers is the most important weapon (if not the only) we have when programming. So if you want to learn how to write programs in this way, please do read this article.
And the same thinking can be applied to not only Elixir, but also other languages like Ruby, Java, Python, etc. It's just that Elixir makes it easy for us to write programs in layers.
I don't know if the author use Elixir/Phoenix or not, but designing a Rails application in this way is like implementing Phoenix Context in Ruby.
Private AR Models
module Accounts def self.fetch() # ... end class Model < ApplicationRecord self.table_name = 'accounts' end class Account attr_reader :id, :name # ... end end
defmodule Accounts do use MyApp.Context def fetch() do # ... end defmodule Model do use MyApp.Schema schema "accounts" do # ... end end defmodule Account do defstruct [:id, :name] end end
In the end, the principles behind these two design choices are the same: have a deeper class/module. (which is the lesson I learned from A Philosophy of Software Design)
Deploying something useless into production, as soon as you can, is the right way to start a new project.
Measuring the time to production is a good start point to measure the delivery lead time (which is one of the most important indicators for development performance).
Plus, “Much of the essence of building a program is in fact the debugging of the specification.” - Fred Brooks. So, why not deploy to production early and start debugging the specification as soon as possible?
it’s almost never the case that folks don’t care about something, they’re merely care more about something else.
I had the same feeling that "nobody cares about quality (especially testing)" when I started my career. Until latter I found that people actually care about quality very much. Whenever I asked someone, they would definitely tell me that they want to improve the quality of their application, and they want to write robust code. Then I asked "You know, writing tests can help you reduce bugs and refactor, so you can improve quality easily." Often, the answer was either:
- "What do you mean by tests? We do tests manually every time we change our code and we have QA people..." (Then I would explain what automated test is.)
- "We think maintaining a test suite would slow us down. And we still have tons of features to develop." (Then I would start writing tests myself and try to let them see tests would actually save us time.)
So you see, people actually cares about quality, it's just that they either don't know how to improve quality or work on other things that they think are higher priorities.
In these two cases, I think it's better to model, document and share than to only align priorities:
- You don't need to ask permission to start improving the quality of your project.
- Start writing tests for new features.
- Add or fix CI pipelines for your project.
- Add linter or formatter to your project.
- Describe how much the quality is improved via these methods.
- Error rate is reduced by X.
- Feature development time is reduced by Y.
- Debug time is reduced by Z.
- Share these outcomes with your team. If you did the first two steps well, people would come to you and learn from you.
Finally, nobody cares about quality and model, document and share are from the same author Will Larson. And I also finished his great management book: An Elegant Puzzle: Systems of Engineering Management. Highly recommended!