𧡠Kent Beck's "First make the change easy, then make the easy change" applies here. There's no single best way of organizing a codebase. Rails gives you initial structure, which is a good start, but it shouldn't end with the 3 directories in "app/" (1/9)
https://twitter.com/JacobDaddario/status/1578083937787707392
When it comes to default directories I don't recommend putting non-AR classes under app/models simply because it is the convention that AR models go there. Mixing them up with other types of classes makes things more difficult (2/9)
When it comes to lib/ it's a good place for files that provide abstract or shared functionality that you can then leverage in concrete implementations under app/*. Remember these files are not reloaded in development by default but you can change that in the config (3/9)
When it comes to app/** - this can be dictated by your domain. You can start with a separation between app/commands (objects that have side-effects) and app/queries (objects that just return data). Over time you discover more concrete ways of organization (4/9)
ie you may end up with app/lessons/{commands,queries} as the edu platform you're building clearly has a distinct "Lessons domain" that can live in its own directory. The trick? Goes back to the beginning of this thread - make the easy change, assuming it's easy to do so π (5/9)
Being able to move things around, rename classes, modules etc. can be simple when your codebase is consistent. If you have a crappy piece of code but it's consistently crappy, it is actually easier to make it better then when you have inconsistent crappyness (π€£) (6/9)
What it means is that if you made a design choice - stick to it everywhere until you decide to change it. This will help π― That's of course not everything (I wish it was haha). Another big factor is the level of coupling that you have across your codebase (7/9)
That's why you need to be very cautious about things like constants and bi-directional coupling. Quite often you may realize that coupling could only go in one direction. Maybe Teacher needs to know about Lesson but Lesson doesn't really need to know about Teacher. (8/9)
With consistency and low coupling, it's easier to move things around and re-organize your codebase and that's really the only reasonable way. You can't come up with a great organization structure upfront because you don't know what you don't know.
(9/9) The end π
(9/9) The end π
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
