One of the questions that came up a lot during my last developer bootcamp was : "JP, this is a lot of stuff to take in, what is a path you recommend for us to start implementing these techniques over the next little while?"
My answer to this question is twofold. The first and hardest answer to swallow is that you need to "Be Prepared To Unlearn". In my opinion, it is a lot harder for people to unlearn bad practices and ideas, as opposed to picking up potentially good and useful new ideas. The biggest unlearning comes from the fact that most developers truly believe that they are taking advantage of OO programming, when in reality the majority of their code is just procedural code utilizing objects. The shift that has supposedly happened has not truly been realized by lots of developers (this is not just applicable to the .Net world either).
Once people realize that they have not really been utilizing OO and its accompanying set of principles and practices, they want to know how they can start leveraging TDD, mock objects, ORM etc. Again, too much too soon is not necessarily a good thing. The other problem that people encounter is that once exposed to these new principles, devs want to rush back and start applying them to their existing (often bloated untested, fragile) systems. In reality, it is impractical to learn these new techniques and go back and tear the application apart (especially if it is working for the most part). The following list outlines a strategy that I suggest for blending new techniques, patterns, practices , and tools into your development environment (current project):
If you're not using source code control, stop reading this right now and go and get your code into an SCC, Subversion is a great free source code repository server.
Get a continuous build environment configured using a combination of either NAnt/MSBuild/FinalBuilder and CruiseControl .Net.
Set up automated scripts that can compile, and deploy your project (this will save countless time over the course of a month)
If you are in the camp that realizes that you are not truly sure what real OOP looks like, spend a bit of time reading up on some good material that will help you get an idea of what OOP is all about, some of my personal recommendations are:
Identify hot spots in your application that cause you headache (lots of bug tickets), and make a strong effort to get some automated unit testing around those areas. Utilize frameworks like MbUnit or NUnit to accomplish this.
If step 5 is proving problematic because of a highly coupled system. You may need to start teasting apart dependencies and refactoring for a bit more testability. Again, only focus on the hotspots. If you are unsure about how to proceed, pick up the awesome book Working Effectively With Legacy Code which will introduce you to a host of techniques for getting yourself out of tangled messes in your application.
Get into the habit of unit testing new code that you write. This is not test driven development, but it will get you in the habit of ensuring that to the best of your knowledge, new functionality you are working on has a safety net of testing around it. This will serve many purposes down the road, especially if refactoring needs to take place.
Get some design patterns knowledge. It will allow you to speak a lot more concisely with your team members, and well as help you think about way to build more cohesive objects. If you are starting down the patterns path, beware of patternitis. In all honesty, when you are learning, you will rush to try and find a way to apply design patterns, with experiece you will realize that although you could use a pattern in a certain scenario, another solution could be simpler.
Start introducing the concept of interface based programming into your applications. By coding to abstractions, you will allow for systems that are far more loosely coupled as well as extremely testable.
By this point you should be comfortable with the concepts of unit testing and interface based programming, and all of the new development you have done, sticks out like a bright light surrounded by the darkness that is your old code. Now is the time to start getting into the habit of doing test driven development.
Getting into TDD is a bigger shift than the jump you will have already made to object oriented programming. The best piece of advice I can give is to stick with it. Code your tests imagining that the pieces you want to exists are already there and you can use them as you would want to, simply and easily. The nice thing about TDD is that you are designing your object from the perspective of a consumer of that object, this inherently will constrain you to keep the design as simple as possible. It is definitely beneficial if you are able to pair with someone who can help you down the TDD path (heck bring me in for a week or 2!!).
So you are now comforable with traditional test driven development, it is now time to add a new tool to your TDD arsenal, a mock object framework. By utilizing mock objects, you will be able to focus on writing tests for only one class at a time, while simulating any dependencies the class you are testing may have. My current favourite mock object framework is Rhino Mocks. By the time you introduce a mock object framework, you should already be comfortable with interface based programming, which will allow you to start integrating it into your tests very quickly.
Start playing around with some more OSS software, leverage dependency injection to acheive truly decoupled components, downlod and look at the source for existing open source projects.
This is the last and most important point:
Become a student of your profession - this is so important, most of the people who embark down this style of development do so because they have a passion to want to deliver applications that both please the user, as well as please other developers who maintain the code. Like anything else in life, if you want to excel in anything you have to be willing to sacrifice a little. What does this mean? Make a commitment to read a book a month. Take time to download a tool you have no idea about and start spiking it. Speak at a user group. Write a magazine article about your learning. Passion breeds passion, if you get infected, more often than not, others around you will want to have a "piece o dat"!!
It should be noted that the above 14 points cannot be acheived in a short amount of time, it is a proposed plan of attack for starting down a new path of development. It could take 6 months, 1 year, 2 years before you feel comfortable with all of the new techniques and practices you will be utilizing. Speaking from personal experience, it will be one of the best investments you make for your career.
Enjoy the journey!!