Because there's a common expectation of where things go, and not following that expectation is problematic. You don't want to force people to use your facets, but you want to allow them to if they find it a helpful alternative view on the structure of the application. Basically, it can provide supplemental context.
if I create a gem:
what changes something from a leaf to a non-terminal node is a collision (like in the immutable js talk)
The structure of the linked file names can act like a filtered version of the real files, or you can change the names because you have the feature context. You can use shorter names, omit the directory, etc
The file names in Nerdtree function like well organized tab names which never move.
Like Kaushik said, you also need to be able to navigate quickly between the files using things like ctags, file finding, etc.
comment-lots-of-little-classes-hard-to-reason-about
The gem-chanko has the idea of these units that I'm talking about here, but it's non-standard.
need to be able to get back to context quickly (like you push a new feature to production and discover an issue with it when looking at monitoring/metrics... want to get whole feature context back into your head)
becomes more important as you break more things out (like network adapters, helper objects, etc) and you have them in their expected places
talk-scaling-a-large-monolithic-rails-app (talks about https://github.com/cookpad/chanko gem which has units that are models, views, and controllers in one place)
might be applicable on platforms other than Rails, but Rails is particularly good because the default structure is so function-based, not feature based. You put controllers in the controllers folder and models in the models folder. I've seen people bend over backwards to attempt to avoid being shoehorned into Rails' defaults, but they end up altering their codebase so as to make it unrecognizable (to new and experienced developers). The facets directory doesn't alter your Rails app at all, except to provide new views into your pre-existing code.
helped with identifying boundaries... do I really want to put the entire "User" class in the feature? How about if I create a class that has all the user-associated functionality for the feature in it, instead.
A parley thread about this pain: http://parley.rubyrogues.com/t/organizing-models/3108
Other people can enter the module and clearly see the requirements at the higher level
omit routes and migrations and images
but! some of the files linked by the feature are shared with other features! Actually, that's a good indication that you should use SRP a little more aggressively. A massive user model that supports feature-specific functionality should be broken apart.
A reasonable way to logically deconstruct a monolith without actually having to deconstruct it totally.
It's very easy for people to reason about features... it's a much better entrypoint than just looking at the code.
talk about how it gave quick insight into the slideshow feature (which was a feature branch that someone else did)
git diff --name-only foo bar
The messaging feature
http://en.m.wikipedia.org/wiki/4%2B1_architectural_view_model
Google had a funny April fools joke where they would print out your Gmail for you, but what folder would you put it into? You can only put printed stuff out into one folder, whereas tagging lets you put it into a bunch of different virtual folders.
I now heave a sigh of relief when the thing I need to work on is one of these features, and I go back and put the effort in to make features of things that weren't features beforehand, since I know how great it is.
33 files spread out all over the project. SRP and we use a lot of classes, but we're not even that aggressive about breaking them apart.
can remove a lot of the nesting... if you only have one view in the feature you can have it be called "view"
really hard for Toni to know when to invest in stuff. Can seem like investing in tooling is overkill (or takes away from coding... and it can!)
They struggle a lot with where to put stuff, even the two of them that work at the same company disagree: podcast-bike-shed-episode-5-rails-is-not-your-arch
I remember that in the dhh keynote from 2011 where he introduced the asset pipeline he was happy that they finally had an opinion about where files should go.
Am I the only one who has difficulty remembering exactly what the file name is when using control P?
You can open these things up and all your tabs, but what about when you move away and then you later on need to add a new feature to the feature?
You can run focus tests on just the things inside the feature. Reference the talk by Erin Patterson
I'm currently using it primarily for features, but you could do all sorts of other ways of slicing and dicing the code
Mount a defense against knee-jerk reactions to the idea
Concede that the alias management is in early stages
Creating these things is especially easy when using feature branch based development. Would be more difficult to tease out what files are associated with the feature on trunk based development after-the-fact.
Talk about how I also have "" smart folders but that I haven't use them nearly as much as feature development.
Having this is great in the moment, but it's especially great when revisiting a feature. It's so easy to get the rest of the context of the application out of your mind and to be able to focus on only the things that I actually need to be focused on.
Mount a defense of NERDTree.
O recursively opens the feature, showing all the files involved in the feature. If you nest them nicely it can be very easy-to-read
You can link in documentation from docs into a README per feature which is a very clear place for people to look.
It's not per user set up specific like stars or IDE shortcuts, or even open tabs would be. This means that one developer can improve it for others to
The real files remain in their canonical rails locations
Talk about the different ways of doing views in system architecture from CMU
If you try this with the tabbed approach he have to keep opening them and rearranging them just so
Great for bug fixes, but also for iterative development where we might release a V one then come back to it and release of you too, and of the three etc.