Pattern vision
37signals.com
37signals.com
Particularly the Law of Demeter and the Single Responsibility Principle are frequent offenders.
You end up with something that could have been handled in one or two small classes and/or Concerns split up over 30 or so files neatly organized in a module hierarchy.
End result is that every single file has a single responsibility yet it's extremely difficult to see whats going on.
Rails 3 I think unintentionally started this. Through it's use of Concerns. This is good in a very large framework such as Rails and when the Concerns like in Rails contain a decent chunk of related code grouped together in one readable chunk.
I use Concerns within my own apps as well to maintain readable re useable code that can be used in multiple models.
If you have 20 Concerns each containing one or two methods split all over the file system it's difficult to maintain, but even harder to understand.
The Law of Demeter has also brought us ActiveModel wrapper classes that wrap all of this code together and when you add a column to the underlying table you can't use it with the wrapper class since it's not a real AR model. So you now have to fork the library or write your own models.
(edited to use the word Concern instead of the more generic Mixins)
This is a consequence of the source code persistence mechanism being also used as a browsing and organization system. It's an impedance mismatch problem only Smalltalk tried to tackle in the past. Code Bubbles and Light Table have mentioned it more recently.
What if one could tag code and easily browse it by tag?
One of the original beauties of Rails was it's pragmatic approach. It took a couple of key patterns and bent it into a less pure yet easy to use way of writing maintainable code.
I'd argue that the directory structure and conventions behind it was DHH's main innovation here. Of course Rails own code base was quite ugly out of necessity before the 3.0 rewrite to handle this.
I think the current trend to use patterns blindly comes from the fact that there are so many large Rails legacy apps now. We need better ways of organizing the code. Yet we shouldn't break what made Rails good in the first place or we end up with the Ruby equivalent of EJB's.
If we are in the business of writing Rails apps and not innovative new IDE's we need to write code in a way that works with our existing tool belt.
If we start blindly following patterns without being pragmatic about our current tool belt we may very well see the ruby equivalent of EJB's.