La Teoría del Reconocimiento de Axel Honneth

The coding phase is still more critical if developers work in a distributed team.

Adhering to coding standards in order to increase code readability, defining standard rules like conventions on classes names, methods or variables and formatting rules,

5.3 Standardize Processes 129

it’s therefore very important, because it improves the legibility and, consequently, the maintainability of the code. But these rules should simply emerge from a common requirement to improve the productivity.

Even if a well written code should be self explanatory, code documentation is important too: every class or method should be commented in order to immediately understand its functionality.

Simple design is an essential practice to avoid duplicate code, have a relatively minimal set of classes and methods, and be easily comprehensible. In the experiences here reported we have demonstrated that the software quality increases adopting a simple design. Also in Jakarta project (see Section 3.1.1) we saw that developers adopt an effective design, very simple.

Code reviews are an important technique for producing quality software, and is a standard practice for many software development teams. There are many problems with conducting effective code reviews in a distributed team. One of some barriers for conducting code reviews for distributed teams, however, is the frequent logistical impracticality of convening both authors and reviewers to conduct a code review in the first place.

Code authors must assemble all the files for review, highlight all the code that they have added, removed, or changed from previous versions, and package them for reviewers. For wide-ranging or complex code changes, some guide or rationale for the changes must also be provided to help reviewers understand the changes in context.

All of this requires no small amount of time and effort for preparation, documenta-tion, assembly and distribution. Code reviews are typically conducted in a meeting room where all reviewers and authors can gather to discuss the changes. All parties are expected to have reviewed and familiarized themselves with the changes before-hand. Differences of opinion and discussion of the merits of different approaches can often lead reviews astray and spawn additional meetings to resolve differences. For

5.3 Standardize Processes 130

highly distributed teams, code reviews may mean that some team members make radical adjustments to their work hours so that they can make an early morning or late night conference call. Frequently, Web meetings must be scheduled in addition to conference calls so that all parties can walk through the code simultaneously.

Some examples of coding standard you can find in the Sun’s site², also if it con-cerns only Java, but some common standards can be adaptable according to need.

An other good practice improving the code is that each class and each method should be commented in order to provide easily a knowledge of functionality.

But if the code is not robust, all the rules described are not so useful: a such system could be not maintainable and it could be too expensive in terms of resources and time to be extended. To avoid the previous problem, it seems important to ap-ply refactoring, a practice which can guarantee a code evolution with a behavior preservation, in order to improve the design of the code, making it more reusable and flexible to changes.

The continuous integration allows the incremental development of the soft-ware and makes easier for developers to integrate changes of the project. The basic idea is that the code created by all the developers on the team is regularly compiled and tested to make sure that all the code changes are compatible.

Continuous integration should be performed automatically, to build the project con-tinuously: to update sources, to compile them, to run tests. When the build has finished, we obtain a precise indication on the result: failed or performed correctly.

The automated, continuous integration provide an easy-to-use build system that in-creases productivity. This practice has been adopted with success both in the MAD project (Sec. 4.1) and in the DART project (Sec. 4.2.2). Continuous integration in XP is supported by the practices of Pair Programming, refactoring, collective

2URL: http://java.sun.com/docs/codeconv/

5.3 Standardize Processes 131

ownership, testing and coding standards. In order to automate such activity it is possible to use some scripts (for example ANT ³), that allow to specify a series of operations in a systematic way.

Using a tool like CVS ⁴ makes continuous integration easy. CVS merges your local changes into the repository version, updating your local copy, but leaving the repository unchanged. You can work confidently knowing that you are always work-ing against the most recent version of the system.

The build should be working at all times. If someone breaks the build, they are responsible for fixing the problem immediately. Run the build often, preferably after every check-in to the code repository.

By definition, Pair Programming requires programmers to work on the same computer. But the trend towards distributed development needs programmers on the same team work at different sites, even on different continents. Recent researches find that pair programmers produce code with higher quality without sacrifice of pro-ductivity and have more job satisfaction [19]. Moreover as shown in FlossAr case study (see Section 4.2.2), when the development phase (phase 3) is characterized by strong pressure for releasing new features and by a minimal adoption of pair programming, we observed a growth both in the coupling metrics and in the local metrics, indicating that in this phase the quality has been sacrificed.

To enjoy the benefit of Pair Programming, distributed team members need to work as if they were sitting next to each other. During the second phase of the MAD project (Section 4.1) we used some techniques to support distributed pair program-ming and these guaranteed a good communication level. In appendix A we propose some tools to support the distributed pair programming (see also Section 5.4.3).

These tools provide functionalities such as application sharing and/or synchronous

3URL: http://ant.apache.org

4URL: http://www.cvshome.org/

5.3 Standardize Processes 132

communication (textual and vocal chat). These tools have been tested during MAPS project and other our experiences. Finally in a OS project this practice is not appli-cable in its strict form but those same goals are achieved in other way. In Jakarta project (see Section 3.1.1) the code is frequently reviewed because the code is public and all of the contributors can suggest improvements and detect potential bugs or report bad smells in code. Knowledge transfer is less immediate, because only the mailing lists are used to communicate. Then with a virtual collaboration environ-ment distributed developers can work as if they were setting together, using the same input devices and looking at the same monitor.

5.3.3 Testing

The Testing practice is useful to verify and to certify the correctness of a class.

Unit and functionality tests help in measuring the correctness and the robustness of the developed software. Functional testing (also known as black-box testing) is the process of verifying the behavior of a system, having no knowledge of the internal functionality/structure of the system. Unit tests, or white box test, allows instead to test every class or parts of the system, because they focuses specifically on using internal knowledge of the system.

In XP approach you write a test before you write the code you are testing.

This is the test-driven development practice that follows this philosophy: “test first, test often.” The focus is on building automated unit tests which can be executed repeatedly against the code. By creating tests before code, developers establish a baseline of expected functionality. As long as the code passes the tests, they can be reasonably assured that the system meets the expected requirements. Many studies have been conducted in order to investigate the benefits of TDD in terms of code quality and team productivity. These studies have been reported in section 3.3.

In our simulation experiment (we reported the results in section 3.3.3) we found that defect density decreased by 40 % in the case of TDD application. Also in

5.3 Standardize Processes 133

FlossAr project (see section 4.2.2) we found that when the development phase is characterized by a minimal adoption of testing and refactoring the code quality is compromised.

Automated tests help make sure code works. This is the best way to make sure your team creates quality code, moreover they help support refactoring of code, providing a means of ensuring that bugs are not inadvertently introduced. There are cppUnit, perlUnit, JUnit, and so on, collectively know as xUnit. The port getting most of the attention is jUnit, which is the port for the Java programming language.