Related link: http://www.cdbaby.com
Pretty soon I’m going to re-write CD Baby from scratch.
CD Baby, including the storefront, backend intranet, members login area, and various cron scripts is made up of 91,345 lines of PHP code in 1105 files. And I did it all myself over the past 5 years.
6 years ago when I started CD Baby, I didn’t know shit about programming. I just knew some basic HTML. The first version of the site was done in Microsoft FrontPage (how embarrassing! It worked hand-in-hand with the shopping cart software, though, so I had to.) When people would mail me CDs, I would open up a template in FrontPage, and cut-n-paste their info into the template, and upload their page.
As it grew, I knew I had to go to something database-driven. But to me, a database was Filemaker Pro. A program where you click things on the screen, drag and drop things, etc. I guess for people using Microsoft servers, it still can be that way. But my gurus taught me the peace-of-mind of open source. Using only non-commercial technologies, so that nobody can decide to start charging you too much.
So I bought some books on PHP and some books on MySQL. I learned s-l-o-w-l-y. I mean REALLY slowly. I mean only really after 3-4 years did I feel I knew what I was doing. Until then I would get by with something just barely good enough to work, which was enough for me.
But now after 6 years and 90,000 lines of PHP code, I really am getting good at this. So I want to go back and re-write CD Baby from scratch, knowing what I know now, to right my past wrongs, and leave a much more flexible, expandable, maintainable program to ride into the future.
This journal will document the re-writing thought process, decisions, philosophies, cool tricks, and all that fun techie stuff.
Cool idea!
Hey Derek,
This is a great idea, and I'm glad you're doing a weblog through the whole thing. My name is Ian, I'm a CD Baby artist (Drop Trio) and a coder by day. Looking forward to reading your story as it progresses!
Ian
ian at droptrio.com
Looking forward to it
This is good. I, too, am a CDBaby artist (the Marzaks), and a software engineer. I've been doing C++ coding of Windows applications for many years years, but I've decided to try being a freelance web guy instead. I've got a lot to learn, but watching this process will really help. So thanks.
A Perspective on Rewrites
Check out this Joel on Software article on rewrites. Food for thought.
A Perspective on Rewrites
Yes, the Joel on Software article is great; you should definitely check it out Derek. Before you do anything with the code, though, I recommend setting up tests to ensure that the system behaves as it should.
I'm not sure if those would all be "integration" tests, or maybe just a collection of unit tests, but that should be priority #1 IMO. The idea would be:
1) While you may not like the underlying code, it _does_ work for users
2) Any redesign should first *not break* things that already work
3) So, identify the major areas of the site that users use and program a set of tests to make sure that those parts of the site work with the current system
4) Break up the redesign into discrete refactoring steps that concentrate on only one or a few subsystems at a time (come up with an overall plan first)
5) Tackle the refactoring one step at a time, running your site-wide (integration?) tests after each refactoring to make sure that nothing has broken
While you're at it, also put in unit tests for all the new code (as part of the refactoring) you write. Since you want to re-do this using best practices anyway, the test-driven approach would seem to be the best way to go IMO.
Oh, one more thing: I'd recommend *not* trying to add new features during the refactoring. If you do, you'll be trying to do too many things at once and hitting (testing) a moving target. First make the underlying code more solid while keeping the functionality for the user _exactly_ the same, then only after that's done and tested, should you consider adding new features (keep a log of any ideas you come up with during the refactoring, though!).
If you finish the refactoring, and the users can't tell that anything happened at all, pat yourself on the back for a great job!