I don’t have to remind everyone that we’re in the middle of a world-wide economic downturn. When the economy is good, it is hard enough to convince your client to re-build an application from scratch. When the economy is bad, it is close to impossible. As developers, we’re going to see more push from our clients for evolutionary development of applications rather than wholesale replacement. We will be called upon to improve existing codebases, implement new features, and take these projects in initially unforeseen directions.
In this nine-part article series, I will take you on a journey to improve an existing "classic" ASP.NET Web application. By classic, I mean a Web application written in ASP.NET 1.X or 2.0, but before the widespread use of AJAX techniques or ASP.NET MVC. In other words, a Web application that you wouldn't be surprised to find running in your corporate data center or somewhere on the internet, or a workhorse of an application that gets the job done, but doesn't necessarily do it in a manner that is maintainable or that improves the productivity of its users.
In choosing a suitable Web application, I had a few requirements:
· Typical ASP.NET 2.0 codebase
· Good quality codebase
· Familiar business domain concepts
· Real Web application with publicly available source
Based on these requirements, I chose ScrewTurn Wiki, which is available from http://www.screwturn.eu/.
Let me explain why I chose ScrewTurn Wiki.
Typical ASP.NET 2.0 Codebase
I wanted the code to feel familiar so that techniques discussed can be easily transferred to your own codebases. The ScrewTurn Wiki codebase should be familiar to anyone who has ever written an ASP.NET 2.0 Web application—ASPX pages, ASCX controls, master pages, dynamic content stored in a database (or files).
Good Quality Codebase
I wanted the code to look like code that any of us could have written last year, last month, or last week. I want to show ways to improve the codebase, not ridicule its inadequacies. The reason for selecting ScrewTurn Wiki is not because it is desperately in need of improvement. On the contrary, ScrewTurn Wiki is an overall good codebase and could use improvement the way any quality codebase would benefit from improvement.
Familiar Business Domain Concepts
I wanted to choose a business domain that was easily recognizable and understandable to nearly everyone. Shopping carts and eCommerce sites have been used as examples far too frequently. A stock trading application is not a good choice in the current economy. Many other business domains, such as shipping, accounting, and others, simply require too much explanation of core concepts.
With the success of wikis such as Wikipedia.org, every developer should have at least a passing familiarity with the business domain concepts in a wiki—pages, edits, history, diffs, and similar. I hope that this familiarity makes the code easily approachable for a wide developer audience.
Real Web Application with Publicly Available Source
I wanted to improve a real Web application, not some contrived example. Additionally, I wanted to find an application with the source code available so that you could follow along as I refactored the codebase (a code download is available from the MSDN Code Gallery). ScrewTurn Wiki has a public Subversion repository and you can get the latest version of the source code from here:
You'll need a Subversion client such as TortoiseSVN, available from http://tortoisesvn.net, to download the latest source.
Note that I will be starting from the ScrewTurn Wiki 3.0 Beta codebase, "The Trunk" (noted above). Most ScrewTurn Wiki sites are currently running ScrewTurn Wiki 2.0. I felt that it would be more valuable and relevant to work with the latest source code rather than a previous version.
Choosing ScrewTurn Wiki for this series has a number of other advantages:
· It is the software behind many wikis on the internet
· It was recently included in Microsoft Web Platform Installer v2
As such, many of you have probably heard of ScrewTurn Wiki even if you haven't looked at the source code.
Another big advantage is that when I contacted ScrewTurn Wiki's author/maintainer, Dario Solera, about using it as the Web application for this article series, he was excited and supportive. When finished with the article series, I will donate all source created back to the ScrewTurn Wiki project.
So what will I be doing to ScrewTurn Wiki in this nine-part series? I will apply a combination of good software engineering practices and integrate new technologies into the existing ScrewTurn Wiki 3.0 codebase. Each article will cover a different type of improvement and can be read alone or as part of the larger series. Topics will include everything from build automation/scripting, testing, and refactoring to HTTP handlers/modules, AJAX, jQuery, and ASP.NET MVC. This article will focus on “Brownfield Basics” or how to get started with improving an existing application.
What is a Brownfield Application?
Most developers have probably heard the term "greenfield development," meaning a brand new project without any existing source code. The project is a clean slate on which you can make your mark as an architect, developer, or designer. It is your own personal playground.
So what is brownfield? Wikipedia defines brownfield as:
...land previously used for industrial purposes, or certain commercial uses, and that may be contaminated by low concentrations of hazardous waste or pollution and has the potential to be reused once it is cleaned up.
In software development terms, a brownfield application is an existing application which is developmentally hindered by poorly implemented practices, but has the potential for improvement. Poor practices might sound overly harsh, but almost every project can improve its software development practices in one way or another. When starting (or continuing) work on an existing application, we should consider the current practices implemented on the project and how they can be improved. I will examine ScrewTurn Wiki in light of some brownfield basics. (For a deeper look at brownfield development, I recommend Brownfield Application Development in .NET by Kyle Baley and Donald Belcham.)
There are some fundamental software engineering principles that every project should adopt, regardless of the particular methodology to which you might subscribe. They are:
1. Version control
2. Issue tracking
3. Automated, self-contained builds
4. Automated testing
In the rest of this article, we will discuss the first three. Automated testing will be the topic of the next article.
Other videos from this article