3 ms·

> Large Rails projects are difficult to work in because of that abstraction. It can be hard to even figure out what code is running let alone identifying bugs t

> Large Rails projects are difficult to work in because of that abstraction. It can be hard to even figure out what code is running let alone identifying bugs there. I read this a lot, but I have never experienced it, even on projects that I have joined after they were already huge. Rails conventions are pretty reliable. Most Rails developers choose predictable patterns that resemble the framework conventions. Obviously people coming from other frameworks will often build things differently (sometimes fighting Rails to do so), but a few minutes in the REPL makes everything clear.

Fire-Dragon-DoL 5y ago
Throw a junior rails developer in a big app and let them work. Is shocking the amount of overhead we get used to as Rails developers. You get used to it, but it shouldn't be like that
- quesera 5y ago
  I think this is a universal truth, with nothing specific to Rails. What framework/language/environment can you think of where a junior dev can be dropped in to a big project, and not flounder?
  - Fire-Dragon-DoL 5y ago
    It's probably a problem related to any framework with a lot of magic. With Go and Phoenix, this problem is not there. They are very explicit, so when something unknown is found, it's written there what it does. With rails there are things going on at all time: write a record? Some stuff is written on the db, other stuff is triggered, some stuff depends on thread variables, then other stuff is magically saved in other tables, other is updated (touched), which in turn might trigger more things. It is painful for a new developer because all of this happens implicitly.
    - quesera 5y ago
      Coming from a systems background, I might have a higher tolerance for "implicit" actions. They're always there, and almost never covered in code, although your code depends on them to function. But I think I understand your point. You can ask a neighbor to "run to the market to get bread and milk" and expect reasonable results -- but you'll need to be more explicit with a foreign visitor. Rails optimizes for neighbors, but in fairness the phrasebook and guidebooks are excellent. :)
      - Fire-Dragon-DoL 5y ago
        They are, indeed
treis 5y ago
>I read this a lot, but I have never experienced it, even on projects that I have joined after they were already huge. You've never been in an IDE, tried a go to definition, and have it not work?
- quesera 5y ago
  No, but I do not use an IDE to write Rails code. I can think of a few cases where Rails architecture would be relatively difficult for IDEs: ActiveRecord callbacks, and of course metaprogramming and magic methods like "find_by_x". In most cases this sounds like a mismatch between IDE and framework, but the "method_missing" chain could be a unique challenge. I avoid using that construct in application code, and just accept that some of it exists in the framework -- but that it's almost certainly not the cause of any problem I'm debugging.
  - treis 5y ago
    But sometimes it is. As an example, I've been trying to track down the code that runs for uncaught exception in a controller. It's (probably) somewhere in ActiveController but there's no easy way to find it.

Fire-Dragon-DoL 5y ago

Throw a junior rails developer in a big app and let them work. Is shocking the amount of overhead we get used to as Rails developers. You get used to it, but it shouldn't be like that

quesera 5y ago
I think this is a universal truth, with nothing specific to Rails. What framework/language/environment can you think of where a junior dev can be dropped in to a big project, and not flounder?
- Fire-Dragon-DoL 5y ago
  It's probably a problem related to any framework with a lot of magic. With Go and Phoenix, this problem is not there. They are very explicit, so when something unknown is found, it's written there what it does. With rails there are things going on at all time: write a record? Some stuff is written on the db, other stuff is triggered, some stuff depends on thread variables, then other stuff is magically saved in other tables, other is updated (touched), which in turn might trigger more things. It is painful for a new developer because all of this happens implicitly.
  - quesera 5y ago
    Coming from a systems background, I might have a higher tolerance for "implicit" actions. They're always there, and almost never covered in code, although your code depends on them to function. But I think I understand your point. You can ask a neighbor to "run to the market to get bread and milk" and expect reasonable results -- but you'll need to be more explicit with a foreign visitor. Rails optimizes for neighbors, but in fairness the phrasebook and guidebooks are excellent. :)
    - Fire-Dragon-DoL 5y ago
      They are, indeed

treis 5y ago

>I read this a lot, but I have never experienced it, even on projects that I have joined after they were already huge. You've never been in an IDE, tried a go to definition, and have it not work?

quesera 5y ago
No, but I do not use an IDE to write Rails code. I can think of a few cases where Rails architecture would be relatively difficult for IDEs: ActiveRecord callbacks, and of course metaprogramming and magic methods like "find_by_x". In most cases this sounds like a mismatch between IDE and framework, but the "method_missing" chain could be a unique challenge. I avoid using that construct in application code, and just accept that some of it exists in the framework -- but that it's almost certainly not the cause of any problem I'm debugging.
- treis 5y ago
  But sometimes it is. As an example, I've been trying to track down the code that runs for uncaught exception in a controller. It's (probably) somewhere in ActiveController but there's no easy way to find it.