Team Name: the breakers the code breakers splice and slice devisive Iron Maidener DRAGONFORCE II
We aim to split the nitro_component_transition component into two components: one containing models, and one containing controllers and views.
This will allow us to enjoy the established benefits of Nitro componetization for these two new components:
- Faster test runs because tests can be parallelization
- Faster test runs because only the changed components need be tested (example: if you change a view, the corresponding model need not be tested)
The team has nearly unanimously identified test run times (and therefore long deploy times) of ~2 hours as one of the largest obstacles to coder productivity and happiness. The nitro_component_transition component, as the largest component, is responsible for the bulk of these long spec/deploy times. At the end of this task, we will have two components each with a test time of ~1 hour.
We can reduce dependency complexity: components that currently depend on the (rather monolithic) nitro_component_transition component can now depend on the relatively svelte $NEW_MODEL_COMPONENT
By reducing test run times for $NEW_CONTROLLER_VIEW_COMPONENT, we will encourage developers to contribute more tests in these areas (areas in which Nitro is currently lacking)
We believe that by having two components, will result in a better test run time, we will know we have succeeded when tests are running under ~1 hour.
At the end of this iteration we'll have two components: $NEW_CONTROLLER_VIEW_COMPONENT and #NEW_MODEL_COMPONENT
We will not address Rubocop failures for this initial iteration; we'll generate a new Rubocop "todo" file for $NEW_CONTROLLER_VIEW_COMPONENT.
We'll do the initial move in a single branch. Then, we'll observe breakage, and split into teams to tackle the issues that surface.
Script to move models (idempotent)
We will (via overcommit) prevent users from creating new files in the wrong component (views/controllers in the model component, or models in the views/controllers component, and guide them in the right direction
The components' respective README.md files will guide users
Standard Rails generators will no longer work. If that is a problem in practice, in the future we could modify the stock generators.
Note in the wiki (onboarding guide?)
- Onboarding new developers used to "standard" Rails applications will require a bit more effort
- Extra cognitive overload associated with split to NCT
- In this initial iteration, the new components will be "weak" in the sense that they don't represent strictly related functionality; they do not solve the root problem that componentization ultimately solves
Splitting ONLY the tests into two halves, for parallelization
Rewriting all of Nitro as microservices
NO SQL NO SQL NO SCHEMAS NO MASTERS NO RULES NODE JS SERVERLESS AMAZON S3 EVERYTHING IS A LAMBDAAAAAAAAAAAAAAAAAA 🍸🎉💊 YEAH BRO
Alcoholism
Extracting "strong" components, rather than splitting things in half. We should note that our current approach does NOT preclude the extraction of "strong" components - that is still the ultimate goal. However, extraction of "strong" components is much more time consuming and will not provide short-term relief.
-
Our ability to judge the correctness of our code relies upon our test suite. However, our test suite is lacking in places, particularly our controllers.
-
If the models rely on helpers, we need to address it in a way that does not involve circular dependency. If the model relies on the helpers in NCT, and NCT relies on the model component, we lose the values of splitting them.
- Look at Support tickets as guidance (models still in NCT)
- While ideal, we're not namespacing in this iteration
- Do we want to merge it this week? This will create conflicts with almost any opened PR. And there is an impact in the business.