In terms of scaling and operational complexity, it's worth noting that the underlying runtime was originally developed to run telephone switches - a very demanding set of requirements, which has received continuous development and improvement since. Elixir code tends to be clean and the functional programming paradigm encourages re-factors. The simplicity of the programming model also translates into a codebase that can be effectively re-factored and extended without costly effort for developers to clean it up. For example, skipping an external API at the beginning saves time and Phoenix allows easily leveraging business logic to add this external API later, when needed. LiveView doesn't force tradeoffs between quick progress and doing things the “right-way” or closing the door to further enhancements. "How do the support costs scale with user adoption or usage?". Sustainabilityīeyond simply making sure that your initial feature-set is robust enough to support customers, the next set of questions include: This means it’s easy to include them from the beginning rather than having to come back later for a retrofit. These features are so accessible that even in an initial sprint, their value outweighs their cost to implement, which translates into developers actually doing just that. Don't have any consideration for package and deployment mechanisms? It's part of Elixir's core tooling as well. Don't have time to implement telemetry? It’s already there. The boilerplate includes good starting tests for everything it creates. Experienced developers can minimize it, but a short schedule will mean shortcuts taken somewhere.Įlixir can substantially help with this problem. This process always incurs some tech debt. Typically, building software to test a business hypothesis means coding the happy path first, then coming back and turning it into production software later. You can de-scope your effort by half (or more) with just the selection of the environment. No tests in another environment, no coordination on deployments, no having to figure out type specs or troubleshooting breaking changes to an API across code bases.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |