Integrate Early and Often

From WikiContent

Revision as of 09:21, 17 August 2009 by Kevlin (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

When you are working as part of a software development team, the software you write will invariably need to interact with software written by other team members. There may be a temptation for everyone to agree on the interfaces between your components and then go off and code independently for weeks or even months before integrating your code shortly before it is time to test the functionality. Resist this temptation! Integrate your code with the other parts of the system as early as possible — or maybe even earlier! Then integrate your changes to it as frequently as possible.

Why is early and frequent integration so important? Code that is written in isolation is full of assumptions about the other software with which it will be integrated. Remember the old adage, "Don't ASSUME anything because you'll make an ASS out of U and ME!" Each assumption is a potential issue that will only be discovered when the software is integrated. Leaving integration to the last minute means you'll have very little time to change how you do things if it turns out your assumptions are wrong. It's like leaving studying until the night before the final exam. Sure, you can cram, but you likely won't do a very good job.

You can integrate your code with components that don't exist yet by using a Test Double such as a Test Stub, a Fake Object, or a Mock Object. When the real object becomes available, integrate with it and add a few more tests with the real McCoy. Another benefit of frequent integration is that your change set is much smaller. This means that when you start integration of your changes the chances of having changed the same method or function as someone else is much smaller. This means you won't have to reapply your changes on top of someone else's just because they beat you to the check-in. And it reduces the likelihood of anyone's changes being lost.

High-performing development teams practice continuous integration. They break their work into small tasks — as small as a couple of hours — and integrate their code as soon as the task is done. How do they know it's done? They write automated unit tests before they write their code so they know what done looks like. When all the tests pass, they check in their changes (including the tests). Then, while they have a green bar (all tests passing) they refactor their code to make it as clean and simple as possible. When they are happy with the code, and all the tests pass, they check it in again. That's two integrations in one paragraph!

There are many tools available to support Continuous Integration (or CI, as it is also known). These tools automatically grab the latest version of the code after every check-in, rebuild the system to make sure it compiles, and run all the automated tests to make sure it still works. If anything goes wrong, the whole team is informed so they can stop working on their individual task and fix the broken build. In practice, it doesn't get broken very often because everyone can run all the tests before they check in. Just another benefit of integrating early and often.

by Gerard Meszaros

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools