At the end of the year, the Advent calendar is booming. Rails entries are also busy. Inspired by the following entries, I thought I'd try to summarize how development can proceed even a little even if it becomes a large-scale development. https://okuramasafumi.hatenablog.jp/entry/2020/12/16/224401 https://blog.unasuke.com/2020/i-have-to-learn-those-things-in-the-future/
This article does not deal with discussions about DDD or architecture, but focuses on specific Ruby coding methods. First of all, why is Rails not suitable for large scale in principle? Let's think about why it gets harder as development progresses.
Reasons not suitable for large-scale development: -** The reference point of the class or object cannot be grasped accurately. For this reason, it is difficult to add functions as well as refactoring, and the speed and quality of development deteriorates. ** **
You do not have this experience? --I was following the Gem source code, but I don't know where the method definition is. --The nesting is too deep and you cannot understand the processing contents.
One of the major differences between scripted and compiled languages like Ruby is dynamic function calls, which is a major reason why development becomes more difficult as it grows in scale. As a means to solve this, I think that methods such as DDD are often adopted.
To make the reference explicit, you can roughly say ** "Avoid Metapro" **.
In particular,
--Avoid dynamic method definitions =
--Avoid code that changes processing using # respond_to?
--Do not use # send
--Do not process static processing dynamically
(Example: Create a display using .each for ActiveRecord attributes in view)
It's like that.
It's not a metapro, but there are some standard Rails features that you should avoid.
--Avoid including/mixins of modules such as Concern
Should be transferred to another class
--Avoid ActiveRecord's before_ */after_ *
Call a method from another class with a service pattern, command pattern, etc.
Considering more practical operation, if you set the points introduced so far as coding rules and share them with the team, you can prevent the increase of debt and create a desirable situation. Also, it will be necessary to check in the review whether these things are observed, but it will increase the burden on the reviewer, so it is ideal to detect it with a tool such as querly. With this, even when new members join, the burden on the team is reduced, quality is maintained, and new members can become familiar with themselves as much as possible.
It became like a miscellaneous note book because it was collected, but I also want to re-edit it in an integrated manner.
By all means, I would be grateful if you could comment on things you don't understand (reasons to avoid and remedies) and other points that you should be aware of.
Recommended Posts