Comment by Pewpewarrows
15 years ago
This is a very excellent list, and reads almost exactly how I've documented my personal standards and best practices. There are a few things that I feel are left out, and should definitely be just as important:
1. Testing. Having automated tests that your developers are ideally writing first makes a world of difference. Throw it into your continuous integration system, and nurture a culture around it. If your tools and language allow it, having a lint or style checker as part of your build process is also very handy.
2. Development / Debug Mode. There should be a switch that you can flip when working from localhost, development, and staging to immediately obtain tons of data to aid you in debugging your application. Django-Debug-Toolbar is the holy grail when it comes to using an out of the box solution. Seeing breakdowns of queries called, time spent doing various functions, quick log lookups, etc is essential.
3. Production Error Tracking. If you're still relying on grep'ing logs or being sent 5xx error emails as your only form of error control you're in the stone ages. Go use a tool or service like Sentry to turn this into a centralized system.
4. Issue Tracking. Along the same lines as version control, this should be a no-brainer. A centralized resource for keeping track of any formalized bugs, errors, or planning future features.
5. Analytics and Statistics. Can you tell me right now the delta of 4xx and 5xx errors in your application between your two most recent deploys? How healthy is your app over time? How many sign-ups, returning users, login failures, and purchases have been made? Tracking key business metrics and actionable events will really give you fantastic insight into your product. It's also a great way to catch critical system errors before they take down your site for hours on end, via tracked spikes in latency, cache misses, queue size, etc.
Issue trackers are mixed blessings. We deliberately chose not to work out of one at my current workplace for various reasons. Instead, if we encounter a bug or a user reports one, we deal with it on the spot or we add a task for it in Scrumy, which we use with weekly sprints. If something's not high priority enough to go in there, we just drop it instead of amassing a backlog that's kept out of sight. It's not a problem if we forget about a low priority bug since it's probably not worth fixing if we're not often reminded of its presence by reencountering. Of course, this doesn't work equally well for all teams and products. But I wouldn't call an issue tracker an absolute no-brainer.
It sounds like Scrumy is your issue tracker.
It is only insofar as issues are recorded as tasks to be completed that week. Adding a task to Scrumy means that we're making a commitment to work on it within that week. Some things carry over into the next week, but we don't allow it to become a rolling backlog. So I think it's unfair to call it an issue tracker.
Production Error Tracking
Concur. It is an immensely useful tool, simple as it may be to set up. There are services that do it for you (getexceptional), but it literally takes only a few hours to throw your own together.
Issue tracking is probably moving too much into management territory for this list, which is why I think they left it out.
It's probably for the same reasons that they don't touch upon server management/configuration, but I have personally found puppet (or other similar tool) very useful. It's basically source control for your server configuration - once you start using it, it seems reckless to not have.