I am interested in building flexible, scalable and extensible architecture of my Web project. It will be a multifunctional project. The problem is that from the very beginning we will have only _simple_ specification, with list of only _basic_ functionality and screens. When this kind of project will be ready, we will be working directly with end-users, and project will be growing.
As you can see, project requirements could be changed and new constructive features could be added at any step of projects "life". I need to build proper architecture, which we will be able to easily expand when needed. How to do that correctly?!
I don't want to end-up with this project, wchich will consists of multiple "hacks" and "workarounds", with terrible trash in the code, and mixture of crazy database tables. Of course this "thing" will work, but I do not want such a headache.
Guys, I am asking for your help. Help me with choosing the right way with architecting such project. I've read few books on Agile Modeling, but there are a lot of books explaining Agile _project management_, but not _architecting_. I am stuck on this.
I am open for any help!!! Thank you.
<a href="http://www.BossTalks.com" target="_blank" rel="nofollow">http://www.BossTalks.com</a><br />Free advices and help for entrepreneurs: from Idea to IPO<br />Software and IT Project Management forum
Unlike some people here, I don't think an agile approach is good for every project. For your project, though, it sounds like an agile approach would be perfect.
Agile development doesn't emphasize architecture and design that much. The reason is that the agile approach focuses on keeping the code mutable, so it can adjust to developing requirements. That's good for a situation like yours, where you know that you'll eventually be developing something much beyond your initial requirements, but you don't yet know what the later requirements will be like. However, it means you won't be able to do a detailed design at the start and expect to stick to it; the design will have to change as the code base grows.
Since you know you're going to have to be changing the design anyway, start with the simplest, cleanest design that will let you meet your minimal initial requirements. This prevents the code from being junked up with unused hooks for potential future features that end up never being required.
In subsequent iterations, refactor aggressively - and that includes being willing to redesign. Remove obsolete code and modules that are no longer required. Resist the impulse to keep code around "because it might be needed again". Removing that code will help keep the code base clean.
To facilitate refactoring and redesign, you'll want to write automated unit tests. These tests will help make sure you don't accidentally break anything in the process of changing the code. [ December 29, 2004: Message edited by: Warren Dew ]
Also answered up in OO, UML, etc. forum. Moderator pick one?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jul 11, 2004
Thank you very much for your answer. To tell the truth - you described exactly what I was keeping in my mind, but wasn't sure, is that the right way. But, I see that I really will have to refactor code all the time to keep it working.
Thank you for clarifying my thoughts! :-)
Joined: Jul 11, 2004
Originally posted by Stan James: replace any component X without breaking some component Y. Some of the GoF design patterns and most of Robert Martin's Agile Software Development book focus on this aspect.
Martin talks a lot about stable packages vs volatile ones. What parts of your system are likely to change and what parts are not? He also talks about abstract packages vs concrete ones. Which ones have interfaces and abstract classes and which ones have implementation details? He suggests the degree of stability should match the degree of abstractness. Some very cool ideas.
The "agile methods" folks believe that if you pay careful attention to this kind of stuff, you can evolve an architecture over time, adapting it to changing needs at low cost and risk. I tend to believe them, but it takes serious effort to do it well.
Thank you Stan,
I understood that there is no any common solution for my task. I guess, everything is only about smart refactoring and applying right patterns.
To reiterate with other words: the best way to get a flexible framework is to flex it, that is to impose changes on your design early and often. You are right to be concerned about hacks and workarounds! The best reaction is to not let them survive for longer than a few minutes - once the system works as expected, refactor mercilessly to the best design you can imagine for the current system.
In my opinion, at least as important as unit tests are system level "Acceptance Tests" that test the system as a whole. I'd probably use FitNesse for those tests.
"Agile Software Development" by Robert Martin really is a great book - get it! Another must-read is "Refactoring" by Martin Fowler.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus