Book
Last week I finally finished reading "Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith" by Sam Newman.
Aside from learning that breaking apart of the monolith in to microservices and breaking apart the database is not always the best idea, another key take-away that I took from the book is the naming of patterns.
- Strangler Fig Application
- UI Composition
- Branch by Abstraction
- Parallel Run
- Decorating Collaborator
- Change Data Capture
When we agree upon the meaning of the above terms, we now have a shorthand for describing a complex idea. We abstract away the details to be able to have conversation that that leans towards the terse side, rather than a verbose conversation that requires a lot more words to convey the same meaning.
Podcast
In the same week, I listened to a the following ADSP, The Podcast: "Episode 197: 🇬🇧 Algorithms & Tersity" with Aaron Hsu. In the podcast, Aaron has a lengthy monologue about how mathematics condenses complex ideas in to a very terse syntax. Some programming language follow this philosophy. However, the majority of programming languages have a very verbose form. This has resulted in growth of ideas such as clean and solid code.
 |
| source: thesaurus.plus |
Final Thoughts
Like most things, you can sound intelligent in any conversation by saying "it's all about finding the right balance." When it comes to this topic - I think that tersity and verbosity is a spectrum. If we add another axis to this spectrum that includes simplicity and complexity - we can then start to map out whether code is:
- Terse and simple
- Terse and complex
- Verbose and simple
- Verbose and complex
Assuming that the complexity is intentional and not accidental - I will leave it to the reader to decide what kind of code they would like to write and what they actually write.
My code is verbose and (unintentionally) complex. With enough practice I hope to one day be able to write terse and simple code.
No comments:
Post a Comment