As part of this process they decided to try to deliver the majority of their system via a Web front end to their internal user community, who were all using Internet Explorer 5.5+ as their Web browser.
A range of components
Over time, these functions, components and scripts were packaged up into a set of common items, with names such as common.js or common.css, and moved from project to project, system to system. As the reuse increased, some instances of the functions were enhanced, bugs were fixed etc, and we were faced with the problem of pushing this change out to all copies of the specific function within our complex infrastructure.
At this point, the development architecture team began to look at the best way of leveraging and managing the use and growth of these items within the organization. After much discussion, we were able to divide the code into four distinct groupings:
2. Application Global
3. Component / Subsystem Global
4. Page specific
A downloadable version of this article is available in PDF form from the TechRepublic Download Center.
It was decided that all corporate elements should reside on a single central server to ease management. To support ease of management across all systems, the directory structure shown in Figure A was introduced for the first two groups.
Additional white paper resources
For each folder in each tier a custodian was appointed to be responsible for the management of the items in the specific folder. This role included being the key contact for the items as well as being the lead contact when they were updated whether it was for a bug fix, routine update or functionality enhancement. They are also responsible for ensuring that adequate documentation existed both within the code and separately and for the management of those items—for example backup and storage in a source code control system.
This level of enhanced symbiosis of the code between systems forced a greater level of documentation and quality control upon the developers and the custodians of the content of each tier to ensure that any work done on an existing function—such as adding a parameter—or any new functionality added, did not cause major problems for other systems that also used the same function.
Reducing lines of code
With this rationing of the way the development team worked—the segregation of individual code elements, CSS Class, images etc., and the use of custodians—we have been able to significantly reduce the number of lines of code that are written for each application. Also, the increased use of packaged functionality means that less time is required for testing, QA and documentation as the functionality has already been proven to work.
This efficiency saving has been reflected in the work estimates that we have been able to give to our end users. In this case, a fair amount of effort up front has resulted in major cost, resource, and time saving for the organization and the rewards are being reaped by subsequent projects.