August 5th, 2009 — 9:50am
As I’ve been reading through “The Art of Agile Development” (from O’Reilly, by James Shore & Shane Warden) there’s been a whole load of great suggestions for development practices and not all of them are restricted to an “Agile Only kind of world. One of the major ones that’s stuck in my head (and is repeated quite a bit in the book) is the idea of being “done done” in your development.
The average PHP developer seems to say they’re “done” when the code works from their simple testing, usually just entering values to ensure that things work correctly. I hate to break it to them, but this shouldn’t be considered done. Getting the code working correctly is only the tip of the iceberg – there’s so much more to do to get everything ready to deploy. Besides the code being complete, “done done” also means:
- Having documentation, both in the code and about the code. If future generations of developers were to come around and need to update your code, good documentation is a must. One line comments aren’t going to cut it…at the very least use something like the formatting for phpDocumentor to provide some automated docs
- Making those unit tests pass every time is essential. (You do unit test, don’t you?) Writing tests for all the bits and pieces of your application may be a pain, but it can save you in the long run. Imagine being able to fire off a test suite and being confident that those changes you just made haven’t broken anything.
- The code has to work in the build for your project. Some projects are small enough to where they don’t really need a build, but if your project is much more than a simple site with a database backend, you could benefit from a build. Developers should be able to do local builds to check their work prior to a commit and push.
- I must fulfill what the customer wants in the update or new feature. Sometimes, it just happens – you get to writing your code and you think about “this one cool feature” or “that other fun thing” that PHP makes so easy. You wonder why the customer didn’t want that in the first place. Be very careful with thinking like this, it could lead to some pretty random stuff in the end. In the end, the customer needs to be happy with what you give them – be sure it’s what they asked for (user acceptance testing).
Being “done done” means that, if you handed over your code to the testers or even the end customer, you’d be confident that it works and is ready to be integrated. Sure, it’s about the code being tested and correct, but its also about making it behave as a part of the larger whole. Your code (code ownership is a whole new can of worms) shouldn’t be viewed as “this part that does this” but more of a piece to the larger puzzle of you/your team’s application.
 What’s a build? A build lets you automate several things you might currently do by hand to get your code ready for production. This can include things like: building out databases, minifying code, running unit tests and checking syntax on all files to be pushed.
1 comment » | Agile, Development, PHP
August 1st, 2009 — 4:53pm
Well, I wish I could say that this was going to be a guide to getting WebTests (an automated front-end testing tool that sits on top of Ant) but it seems as though I’m having a bit of a Java issue to content with myself.
Here’s what I’ve done so far:
This is where I hit the first snag…apparently since OS X’s Java install is just a bit different than some of the normal ones, a few of the files aren’t where they need to be. In my case, I was getting an error:
After poking around a bit on the web, I happily came across this that recommends copying a jar file over to the Java extensions directory. A simple “cp” later and the build made it past that point. Unfortunately, not much past it, though – another Java error popped up that seems a bit more difficult to find information on:
So far I haven’t been able to find much that’d help me solve this one, so if there’s anyone out there that’s seen it before, help would be appreciated. It seems like it actually runs the test just fine (according to the output reports) but it’s not very useful if the build always fails.
2 comments » | Deployment, Development, Testing
July 12th, 2009 — 3:35pm
Along with some of the fun new things I’ve been working on it regards to development and deployment, I’ve also been reading up on the agile development methods. I’m only getting started and I can already tell you – it’s not like anything you’re used to (well, unless you’ve already “gone agile”, of course).
Despite all of the hype right now around Scrum, I figured I’d get my feet wet with the agile concepts with Extreme Programming first. I’m assuming that most of the principles will be similar with varying implementations between the two. My “manual” of choice to get started with has been O’Reilly’s “The Art of Agile Programming” (James Shore, Shane Warden) and it’s been an eye opener.
See, I’ve come from a place where, I imagine, most developers out there are coming from and probably still will be in the future. You spend months gathering requirements, you estimate the times, you set the deadlines – all very structured and, depending on who you’re doing the work for, potentially wasteful. We’ve all experienced the frustration of changes to requirements set at the beginning of the project. Things tend to explode when someone changes “one small thing” and the entire development track is suddenly ripped into pieces and put at the complete mercy of what the customer wants.
In short, it sucks.
From what I’ve gathered so far, the whole concept behind agile programming is to prevent things like this. It makes it simpler to move around in the project and change things that might need changing. Work is done in sprints instead of one long development process and the client/business representative selects the things that will be headed into the next development session. Requirements are more fluid and testers don’t have to wait until everything’s done to find where things break.
I’m definitely still in the learning process, but so far, this agile process doesn’t seem half bad. I just wish it didn’t require such a large change in the processes of the surrounding company. I might be tempted to suggest it around my office…
4 comments » | Agile, Development