View this PageEdit this PageUploads to this PageVersions of this PageHomeRecent ChangesSearchHelp Guide

Development strategy

Some information about the development strategy followed for the reimplementation of the Versions Browser.

One of the challenges in refactoring the VersionsBrowser and its support class is that it was dependent on a number of fundamental infrastructure classes. Making changes to these classes could cause the entire system to break. Our solution was to develop a separate set of classes parallel to the existing ones. This was also advantageous because the existing source code management classes were poorly documented, difficult to understand, and brittle because they had lots of unexpected dependencies. Our new design was easy to decouple from the active source code system. The new design is easier to test because one can attach it to a separate set of (fake) sources that is not part of the running system.

Furthermore, the VersionsBrowser, as it was, was a vital tool in developing the new version of itself. To ensure that it was always available during development, we did all of the early development of the refactored design in a new class, NewVersionsBrowser. Only at the end, did we remove the old VersionsBrowser class, and replace it with the new version.

One of the problems of the VersionsBrowser was that it was a subclass of ChangeList. However, this was for more for implementation inheritance, as opposed to behavioral inheritance. A VersionsBrowser is not a ChangeList, so this inheritance structure is not appropriate. In the new design we move VersionsBrowser to descend from CodeHolder instead. This move was easy, because the new VersionsBrowser shares no implementation with ChangeList. Furthermore, moving VersionsBrowser from under ChangeList ended up being a good way to root out the previous versions hidden dependencies, and eliminate a bunch of dead code.

Link to this Page