4 ms·

This has been a big frustration for me as a new engineer in a Rails codebase: my ability to 'discover' how the system works is extremely limited because I can't

This has been a big frustration for me as a new engineer in a Rails codebase: my ability to 'discover' how the system works is extremely limited because I can't 'see' a lot of the relationships between code. I've grown comfortable with just searching the entire codebase for a given string to find a relevant class or variable, but it's extremely failure-prone without types or import paths to follow. I love the syntax and elegance of Ruby, but it really is maddening how difficult it is to hold all the abstractions and state in my head without the mental boundaries that good type support provides. I often commiserate with a coworker who came from a Java background (and I from Swift/Python) about how frustrating it is when type-based issues leak to prod and cause trouble, or how it lengthens the development process insofar as determining what a given object _is_ at any point in the logical execution. I really understand how unit testing became so popular, given Rails's historical popularity: there's simply no other way to move with confidence through the codebase without a plethora of specific tests for each individual component.

gls2ro 2y ago
Ruby and Rails via rails console or irb is these days pretty inspectable. Say you want to understand what does `belongs_to` do? Just open `rails console` and you can do: User.method(:belongs_to).source_location And opening the file that is printed at the specified line, you can discover the following code: def belongs_to(name, scope = nil, **options) reflection = Builder::BelongsTo.build(self, name, scope, options) Reflection.add_reflection self, name, reflection end And moreso that method has a very good comment before the declaration, documenting everything it does You can also try `show_source` command in Rails console if you have the debug gem installed: show_source User.find And this will directly show the source code of the `find` method. I do agree that for methods defined with meta-programming it will be harder to find the methods. But again here rails console comes with help: For example if you do: User.method(:find_by_name) => #<Method: User(id: integer, nickname: string, name: string, created_at: datetime, updated_at: datetime).find_by_name(_name) <edited by me>/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.8.4/lib/active_record/dynamic_matchers.rb:65> Of course, this is mode complex meta-programming code, but you can still go to it, read it, and see what it does. In case of relationships between entities in the code, you can try Sorbet. It is pretty good these days.
- tenacious_tuna 2y ago
  Coming from a paradigm of being able to read code and understand what it does, having to drop into console to poke at things, even just to then find the source for a given function, was extremely unintuitive to me. At this point I always have a rails console up, just to be able to poke at objects and whatnot, but it feels... clunky. Similarly, when designing system changes I first go through with breakpoints in an existing flow to see what objects and behavior actually are when invoked, because I can't tell just from reading the code half the time--and that drives me bananas.

gls2ro 2y ago

Ruby and Rails via rails console or irb is these days pretty inspectable. Say you want to understand what does `belongs_to` do? Just open `rails console` and you can do: User.method(:belongs_to).source_location And opening the file that is printed at the specified line, you can discover the following code: def belongs_to(name, scope = nil, **options) reflection = Builder::BelongsTo.build(self, name, scope, options) Reflection.add_reflection self, name, reflection end And moreso that method has a very good comment before the declaration, documenting everything it does You can also try `show_source` command in Rails console if you have the debug gem installed: show_source User.find And this will directly show the source code of the `find` method. I do agree that for methods defined with meta-programming it will be harder to find the methods. But again here rails console comes with help: For example if you do: User.method(:find_by_name) => #<Method: User(id: integer, nickname: string, name: string, created_at: datetime, updated_at: datetime).find_by_name(_name) <edited by me>/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.8.4/lib/active_record/dynamic_matchers.rb:65> Of course, this is mode complex meta-programming code, but you can still go to it, read it, and see what it does. In case of relationships between entities in the code, you can try Sorbet. It is pretty good these days.

tenacious_tuna 2y ago
Coming from a paradigm of being able to read code and understand what it does, having to drop into console to poke at things, even just to then find the source for a given function, was extremely unintuitive to me. At this point I always have a rails console up, just to be able to poke at objects and whatnot, but it feels... clunky. Similarly, when designing system changes I first go through with breakpoints in an existing flow to see what objects and behavior actually are when invoked, because I can't tell just from reading the code half the time--and that drives me bananas.