I agree 110% on my friend Derik Whittaker’s post about maintaining & refactoring project structure not just code structure and I’m sure many will agree but most do not put in to practice weekly on their teams.
Breaking your code into physical projects and solutions is a no brainer so I’m not going to ramble on about that.
I'm currently working on a new UI layer for our website in MVC and making a structure that is much more logical even down to the Images folder itself...why the heck not?
Example: Images\Site (means it is used site-wide), Images\Product , Images\[whatever other business function], etc. so that you don't have to jumble through a huge mess of pictures in one huge folder. Obviously I’m not going to create a folder with just one image in it but sure is much more clear when you separate into function. This is just one minor example out of many in the new structure.
One reason I like ASP.NET MVC also is because of physical folder structure out of the box with controllers and views. Logical folders for Views and controllers and you name each folder corresponding to function. It forces you to have a logical structure because the routing engine uses it and RESTful names help organization a lot as well. Excellent!
Controls also need to be more organized. Sounds simple but how much easier is it to see this physical folder structure as your application grows huge: Controls\User and Controls\Custom
rather than one folder Controls\(with a huge messy list of both in the root). You could even go a step further and include function which makes it even more clear:
(mini example here for folder structure with your controls)
Controls\User\Cart
Controls\User\Checkout
Controls\Custom\Cart
Controls\Custom\Checkout
Controls\Custom\[thridpartyname]
…etc. you get the point
Who cares if you can see the extension on your controls, that's not the point and no excuse not to organize them into well named folders. Point is I want to go from A to B quickly in a solution and without effort and find stuff quickly.
Having too many folders is bad, but lack of folders is also a bad thing. If you have a huge pile of files in some folder roots, you need to refactor and use more folders, projects, or solutions to organize your files to make things quickly discoverable. One thing I cannot stand is just a ton of .aspx files (even intermixed with too many other file types) in the root of a web project. Organize them into very basic clear logical folders! My eyes are getting blurry just looking at this list! I’ll soon need a pair of reading glasses after my eyes go bad! As far as folders, as long as you don't go lets say 5+ folders deep and they are very straight forward in their naming and very organized and generalized, I think you're just fine. If you're starting to get too many folders created (but you know it's making the project well organized and discoverable) then maybe it's time to move it into a new project and/or solution as part of your main application.
Structure of an application does not stop at code. Like Derik said basically is that it is an extension of your code and your patterns. Why? Here’s my own set of reasons:
1) Project file structure IS and at all times should be viewed as a form of pattern and directly relates to good process. I say process loosely as process relates to many aspects of development so having a project pattern is essential. Just as there are patterns in anything we do in development, code or otherwise, physical file structure should have a recognizable pattern.
2) It helps complement a manageable and sane build process..it's critical for managing, maintaining and pushing logical standardized builds across departments so that you structure is idiot proof clear.
3) It helps newbie's or even existing programmers find things quick. Makes your project discoverable immediately before even the code
4) overall maintenance is reduced
5) Having a good structure encourages and sets an example for other developers on your team to keep the goodness that's already there (because it is already easy to see what's going on) when extending it. It's called having team development standards and this just is one example of that! In fact, you can view structure of projects as a pattern. If it's clean and discoverable and logical, most likely other developers will follow that pattern and if they don’t then that’s what reiterating team standards is all about to them. However if it’s always a huge pile and it's just chaotic mess of folders and files, you would be certain to receive chaos back when it’s continually being extended by developers on the team. You find this in a lot of code & run shops because nobody cares to slow down and manage it properly. Developers who really care about team usability and WANT to refactor this can’t if nobody cares about structure. And that’s poor management of a team when you let your project structure grow to chaos.
You should name your projects, solutions, folders, etc. to be very understandable and familiar terminology. Don't use terms that only your mind can infer; use words that anyone can immediately infer no matter if they are an Architect lead, Jr. Developer, or mid-level. Obviously if you have frequent questions come up about “what does that mean” from other developers in terms of naming convention or structure, you may want to refactor and look at how to improve it or clean it up.
Your physical abstraction names should be very clear and familiar. If it's a Data Layer, state that in the name. In fact stop using the “DL” acronym as an example. If it's a Service later, etc. call it ServiceLayer…you get the point. I’m not saying you need huge long words, but use full words if you can. Being too short with names just so that everything looks so “compact” can be dangerous and can also product more code smell and waste time for developers trying to learn the application or just simply find stuff. Be careful of the total # acronyms you plan on using overall in your projects and how much you shortcut names. Not everyone infers the same or wants to dig to figure out what 100 acronyms mean after just opening a solution. Sure you argue “hey if you don’t know what the acronym is, just look at the files inside the folder” but that again is not the point here and drives directly against the whole point of project structure. I agree that there are going to be some acronyms that are business related but don’t abuse it just to be “sexy” with your application because everything looks so concise. It's just like variable & method names, keep them short but also keep them meaningful. Keep it sexy but there’s a fine line between “sexy” and “discoverable”.
Finally, code reviews should not only go over code but structure. Did a developer add a new folder(s), project(s), etc. this time? if yes, then talk about it if it does not seem logical to you or organized or too much. Don't immediately be a dictator though and say “move this and rename this” type type type and it’s done without them being able to discuss what they did with you. Maybe the developer had a good reason to do so. Talk about it and discuss as part of the code review which will help you maintain you project structure for the long haul. Hold team code review meetings and include talks about the team .NET file solution structure standards in addition to just patterns all the time.
Print | posted on Wednesday, April 15, 2009 11:23 PM
