Programming practices: Learned from experience

When to check in code?
Check in code daily. As long as the code compiles, check it in. If you don’t have a daily build: check the code in.
Even if it doesn’t compile still try to check it in. The reason for this, you might be tempted to check out code/update without realising you haven’t checked in the code. Overwriting your changes. Sure it’ll give you a warning, but you are one yes/no dialog away from disaster if you haven’t checked your code in for a week.

Make sure you/your programmers get lots of sleep.
If you can’t think properly, because you are tired, you can’t solve problems in a timely manner or ever. Code either works or it doesn’t. Life is very black and white to software developers. 1 or 0, yes or no, compiles or doesn’t etc. So when the code doesn’t work and the programmer doesn’t know why, that’s it. They are no longer a programmer unless they can fix the problem or know the reason why it doesn’t work. When you have a tired programmer and he’s meeting with the customer very bad things can happen.

Code, compile, test.
Make sure you test each function/method as you write it. If you are writing a class with many smaller methods, make sure to test them all when you complete the class.
Write unit tests if your code interacts with any external interface (api, wsdl/soap, libraries, html forms, dlls or other team members code) that might change, so you can know the second something breaks so you can fix it on your side and then gloat (ok maybe not this).

Staging servers.
Run staging servers when you have a live service. After deploying to a live server you should setup a staging/test servers. That way you can test changes before putting them out to customers. Larger/experience companies will often setup staging servers before getting to live servers. You can have your daily builds deploy to a staging server, then setup the same build to deploy to a live server. Copying directly from the staging server is also done and can save cpu/time if a build takes a very long time. Make sure to tag all builds placed on a staging server.

Anyways that’s it for now.
I’ve written about some of these subjects before but I figured out would reiterate them here.

One thought on “Programming practices: Learned from experience

Leave a Reply

Your email address will not be published. Required fields are marked *