I’ve done most of my coding on smaller projects for myself and classes, and this summer ended up working on a fairly large project.
For reference, I’m working on a web app using Zend Framework, and I’m working with one other person.
I started working on it in May – at the time, there was a lot of code already written (pretty sloppily) that I didn’t have much control over. When I started, not knowing any better, I was just either editing files directly on the server with vim or using eclipse and ftp-ing the files up. Over the course of working on this, I’ve started using eclipse for editing, and SVN for source control and to deploy the files to the server.
My question is what are other good ways to both help my productivity with this, and also with managing the deployment better, as it gets closer to real people using it?
Edit: Realized two related things I left out.
One is that I’ve been eradicating bad/dangerous code as I end up touching on something that uses it. Is it generally better to devote time specifically to that, or is the way I’m doing it generally efficient enough?
Also, given that I have relatively limited time, is unit testing worth the effort or even appropriate?
Edit #2: I was reminded I left out the project management part. I’ve been having problems deciding what to hit first. I feel like some days I spend as much time keeping tabs on what still needs to be done than actually doing it. Is this common, how do others deal with it?
Changes I’m going to make: The big one I decided was to actually keep track of everything that needs to be done. I have a well-written spec of what’s going to be there in the end, but a lot of times I’d lose little things and say over and over they need to be done. Now I’ll keep track of them. Also, going to look more into a testing and deploying system.
Dangerous Code, I’d suggest should be eradicated if there is a reasonable chance that danger will bite you in the arse it will be worth the time to track it down and fix it.
Sloppy Code, Fix it as you find it (as it sounds like you need to focus on producing a product to a deadline right now), if any of this turns out to be dangerous code then treat it as above.
Unit Testing, depends, if you’ve a lot of experience with it you could likely be productive with it. If not it could be a drag on your time. Only you can decide if the trade off is worth it based on your schedule. I’d suggest some simple automated testing might be worth the investment, just to check that the absolute basics of you application work. This can be achieved at a pretty high level of abstraction, you could use selenium or something similar. This just avoids any really embarrassing mistakes being released when the pressure is on.
If you’re going to have automated tests it’d be good to have an automated build process to run them, ie a continuous integration server. If you’ve other steps in your build such as compilation etc this can make sure these things are working too. Again though, your schedule might determine if you set this up now, or later. I had a large bunch of very basic tests running from my IDE when I remembered, sometime later we got the time to setup Hudson for our continuous builds and haven’t looked back.
Prioritising Work, It’s ok to not always know which is the important task to hit next. You need a list of everything outstanding, where I work it all goes in bugzilla. After this you need broad priorities on those things, If you’re working towards a v1 of you product I’d suggest you make the prirorties v1, v1.1 and Road Map. After this you need to decide the next one or few things to work on. Depending on how often you want to return to the list it’ll be one thing, or a bunch. This may mean sitting down with your partner and going over the list and working out what to do and how to do it. One problem I notice sometimes when I don’t know what to do next is that I actually don’t know how I’m going to do any of the next jobs, realising that often makes it pretty clear what is important next and that I just need to figure out how the hell to do it.
Managing work, If you’ve got a single place for new enhancements etc to go, ie bugzilla or user voice, make sure people use it and don’t expect you to put things in there for them. Make a point of weekly (or whatever frequency works) checking over new entries and giving them a priority. The point being you can process these in batch freeing you up from the interruptions of dealing with them as they come in.
Better Deployment, You say you’re using svn for deployment. I presume you just do a checkout straight to your production system. You don’t say if you’re using tags or branches at the moment. When you do deploy I’d suggest branching at that point, ie if it’s v1 of your product create a v1_maintenance branch. Any bug fixes etc go on that branch and are merged (regularly and frequently, believe me it can get painful otherwise) into the trunk. This allows you to carry on full steam on the trunk whilst still being able to support the released version. You may want to look at ant or similar one day for deployment, but again if you’ve got something that works right now your effort is probably better spent elsewhere