CSC/ECE 517 Fall 2007/wiki3 9 sm: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 1: Line 1:
== Collective Ownership ==
== Collective Ownership ==


[[Image:Collective_ownership.GIF|frame|Collective Ownership Workflow including Continuous Integration|thumb]]
[[Image:Collective_ownership.GIF|right|500px]]


In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are several requirements to make Collective ownership work well:
In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are several requirements to make Collective ownership work well:

Revision as of 20:33, 29 November 2007

Collective Ownership

In a software project, collective ownership of the code implies that any code written does not belong to any particular engineer. This means that anyone working on the project can modify any piece of code that has been previously written. According to Cunningham & Cunningham, Inc., a consulting firm specialized in object-oriented programming, there are several requirements to make Collective ownership work well:

  • All engineers use the same coding standards
  • The project use code management tools to detect and resolve conflicts
  • A comprehensive suite of unit tests exists
  • Powerful browsing and refactoring tools to find references to old methods and replace them with the new
  • Continuous Integration, so that conflicts are rare


The advantages of collective ownership are that no one on the project has to depend on another engineer to implement a set of changes; they can simply make those changes themselves. Additionally, becuase all engineers work on all sections of the code, the loss of a single engineer should not hinder development as much.

Collective ownership also has some disadvantages. Because all engineers can modify code, people can become upset when someone modifies code that they have written. Additionally, Collective ownership can run into problems with larger teams; if fifty engineers can modify any file in the project, tracking changes can become problematic.

Continuous Integration

Continuous Integration refers to the idea that instead of engineers modifying a set of code over a long period of time and then attempting to merge that back into to main project code, code should be held for only a brief period of time and then integrated back into the main branch as soon as possible. In this system, each engineer integrates their code at least daily, preferably every few hours. This means that there are several integrations per day. Extensive automated testing is usually required for this system to function properly.

Among the advantages of continuous integration are that greatly reduced integration issues on any given project. This is because engineers do not modify code for long periods of time. It is therefore less likely that changes made by one engineer will greatly conflict with changes made by another engineer. This leads to faster integration of code and less man hours spent fixing conflicts.

The disadvantage of continuous integration is that it requires an extensive testing suite to ensure that the small constant changes do not break existing functionality.

References

[1] http://martinfowler.com/articles/continuousIntegration.html

[2] http://confluence.public.thoughtworks.org/display/CCNET/What+is+Continuous+Integration

[3] http://c2.com/cgi/wiki?CollectiveCodeOwnership

[4] http://www.extremeprogramming.org/rules/collective.html