2 ms·

Wow, sandi's talk was really interesting. She's working on a rails book so i'll be interested to see her approach to rails. I'm pretty good with "small methods

Wow, sandi's talk was really interesting. She's working on a rails book so i'll be interested to see her approach to rails. I'm pretty good with "small methods" but her refactor from that to "small objects", while more flexible, seems like its more complicated in the end. I mean if you're going to have a lot of those it makes sense, but I feel like it could equally be called premature; but I respect that it is more tolerant to future unknown changes. "small methods" is also easier for a junior developer to support, and i think that should be taken into consideration.

mbell 12y ago
I really enjoyed her talk but I found some parts of it slightly contradictory, although I think it's mostly due to a difference in opinion as to what what is or isn't easier to reason about. A point she made earlier in the talk is the piece that I have become more and more in agreement with over time. Paraphrasing: 'bad abstractions are worse than code duplication'. I would go farther and say that in the modern coding world, premature optimization isn't the root of all evil, premature abstraction is. The part that I find contradictory is that breaking larger classes into tons of little classes is, to me, a form of abstraction and carries implicit complexicty. She does hit on this point a bit, but it's easier to dodge the issue with simple examples than it is in the wild. Certainly there is a 'cutoff' where a class is too big, but I find that trying to make every method 1 line long and every class completely contained creates huge nested layers of abstractions that are often difficult to follow and hard to reason about for anyone other than the author or someone who has been working on the codebase for a long time.
- meesterdude 12y ago
  > trying to make every method 1 line long and every class completely contained creates huge nested layers of abstractions that are often difficult to follow and hard to reason I agree a lot with this, and have worked on such codebases. It becomes very difficult to tell whats actually going on, or how. or why! I think like everything else, it's subject to abuse and misuse.

mbell 12y ago

I really enjoyed her talk but I found some parts of it slightly contradictory, although I think it's mostly due to a difference in opinion as to what what is or isn't easier to reason about. A point she made earlier in the talk is the piece that I have become more and more in agreement with over time. Paraphrasing: 'bad abstractions are worse than code duplication'. I would go farther and say that in the modern coding world, premature optimization isn't the root of all evil, premature abstraction is. The part that I find contradictory is that breaking larger classes into tons of little classes is, to me, a form of abstraction and carries implicit complexicty. She does hit on this point a bit, but it's easier to dodge the issue with simple examples than it is in the wild. Certainly there is a 'cutoff' where a class is too big, but I find that trying to make every method 1 line long and every class completely contained creates huge nested layers of abstractions that are often difficult to follow and hard to reason about for anyone other than the author or someone who has been working on the codebase for a long time.

meesterdude 12y ago
> trying to make every method 1 line long and every class completely contained creates huge nested layers of abstractions that are often difficult to follow and hard to reason I agree a lot with this, and have worked on such codebases. It becomes very difficult to tell whats actually going on, or how. or why! I think like everything else, it's subject to abuse and misuse.