Identify opportunities for reuse
Identify existing code or other implementation elements that can be reused in the portion of the implementation being
created or changed.
A comprehensive understanding of the overal design is helpful as reuse opportunities are best leveraged when there is
an overall understanding of the solution being proposed.
|
Transform design into implementation
Realize a portion of the system's design by implementing application code as specified in the design. The result of
this step is code that implements the structure of the system as described in the design.
The design is transformed into source code by examining the design and applying reusable code, generating code
automatically from model elements (transformation), or writing the code by hand.
Apply reusable code to design elements by using code templates or looking for similar implementations in the system.
Simply copying code is generally not a good practice. Perform Refactoring on code copied from other areas of the system.
|
Complete the implementation
There is usually substantial effort required to complete the implementation after the design has been transformed into
code. Complete the implementation by leveraging code reuse at every opportunity. Look to the following topics to
identify areas where code still needs to be written:
-
Requirements. Some requirements information doesn't translate directly into design. Examine the requirements to
assure they are fully realized in the implementation.
-
Refactoring.
-
Tuning the results of the existing implementation by improving performance, user interface, security, and other
non-functional areas.
-
Adding missing details, such as:
-
-
Completing operations described in the design - choosing algorithms and writing the code.
-
Adding additional supporting classes, operations, and data structures.
-
Handling boundary conditions.
-
Dealing with unusual circumstances or error states.
-
Restricting behavior (preventing users from executing illegal flows, scenarios, or combinations of options).
-
Adding critical sections for multi-threaded or re-entrant code.
|
Evaluate the implementation
Verify the implementation is fit for its purpose.
Examine the code for its suitability to perform its intended function. This is a quality \step performed in addition to
testing, which is described in other tasks. Consider these evaluations:
-
Read through the code for common mistakes. Consider keeping a checklist of common mistakes that you personally make
as a reference.
-
Use tools to check for implementation errors and inappropriate code. For example, use a static code rule checker or
set the compiler to the most detailed warning level.
-
Use tools that can visualize the code. Code visualization such as the UML visualizations in the Eclipse IDE
help developers identify issues such as excessive coupling or circular dependencies.
-
Perform informal, targeted code inspections. Ask colleagues to review small critical sections of code and code
with significant churn. Avoid reviewing large sections of code.
Improve the implementation based on the results of the evaluations.
Other techniques such as pair programming and refactoring can be used to evaluate code quality prior to completing the
implementation.
|
Communicate significant decisions
Communicate the impact of unexpected changes to Design and Requirements.
The issues and constraints that are uncovered when the system is implemented must be communicated back to the team. The
impact of issues discovered during implementation must be incorporated into future decisions. Update the requirements
to reflect ambiguities identified and resolved in the implementation so they can be tested and the stakeholder
expectations can be managed appropriately. Update the design to reflect new constraints and issues uncovered during
implementation so they are communicated to other developers.
Generally, there is no need for a change request if the required change is small and the same individual is designing
and implementing the class. The individual can make the design change directly. If the required change has a broad
impact, such as a change in a public operation, it may be necessary to communicate that change to the other team
members through a change request.
|
|