System Assembly


After the individual components were tested by the owning developers, the core components were brought together to complete the system. The constant developer testing of the individual components paved the way for the final build and testing of the system. The individual chat interface, whose functionality is to maintain a chat session between two or more participants, was built with the possibility of being a stand-alone application. The integration of the chat center with the individual chat user interface (UI) was implemented seamlessly. However, this has not been the case with all projects TSC has completed.

Once the integration of these two components was shown to be functional, a code review was instigated.

Code Review

Code reviews are part of TSC's software-development life cycle. This phase starts a code review and code-rewrite session before the final build testing is applied. Since the current system is functional, a code review is beneficial at this point, to clean up, optimize, and document the current code. TSC has found it unwise to test before this phase because another testing process must also follow the rewriting of the code. This can become a very intense piece in the final delivery of the system. TSC realizes that this code rewrite will produce challenges that must be quickly overcome before the final build testing is conducted. As you have been aware, TSC made sure the system was functional beforehand to ensure that if there is a problem, it will be mostly due to the rewrite and not to any bugs that may have existed. The code review consists of a number of facets. TSC uses both its junior and senior developers when reviewing code.

The junior developer's tasks consisted mostly of reviewing the code regarding comments and documentation, code indentation, and variable naming. The developer adhered to versioning control and/or backup procedures, as it must be possible to roll back to previous code versions after modifications. The documentation and indentation issues were modified immediately; however, the variable-naming issues were recorded and then later discussed with the other team members. Other aspects the junior developer was encouraged to report on were hard-coded variables, logic, locking, exception handling, and user-interface formatting. This level of code review may also introduce a new employee (either junior or senior) to the standards that TSC requires from its developers.

The senior developer's role concentrated more on the coding techniques and the technologies used within the system. She attempted to identify hard-coded variables that were related to anything from URLs, remote data storage, and local data storage to referenced objects. These were issues she could occasionally resolve on the spot with a rewrite. Other issues such as code logic and conditional statements could either be rewritten straight away or be discussed with the other team members before attempting to adjust the code. If a code block is encountered and identified as a possible bottleneck, code is rewritten to be efficient. Data types and related operations such as retrieving, passing, storing, locking, and returning were issues that needed to be discussed as a group. If a recommendation was agreed upon, then large chunks of code may have needed to be rewritten. Exception handling is also taken very seriously, and the senior developer also tried to flag areas in which the exceptions are not to be handled.

TSC must balance the positive and negatives aspects when deciding whether to rewrite code. If there are constraints (such as time), then it may be better to allow the code to exist in its original state. In reality, the average client is not too concerned with aspects of the code unless it affects the system's outward performance. However, the continued development and iteration of a project does require that all aspects of the code can be read and understood. As you know, some code you wrote six months ago can seem foreign if you haven't adequately used comments, naming, storage variables, and other tools to assist in code readability.

After the initial code review was conducted and the system had been left unaffected, an email was circulated to organize a development-team meeting. This was to discuss the issues that arose from the code-review stage. The meeting was facilitated by the senior developer, with most of the development team in attendance.

The agenda included discussion of:

  • trace() function in ActionScript code

  • Method naming

  • Case-sensitive programming in both CFC and ActionScript

  • trace() function usage

  • Hard-coding paths for CFCs and remote shared objects

  • FSCommand discussion on setting variables in the individual chat UI

  • fps() method discussion

They also planned to Informally discuss and apply the test plan to the system as it stands.

The meeting was conducted and the issues were discussed. This is a regular occurrence for every TSC project, and constructive discussion has always been the tone of the meeting.

graphics/04fig15a.gif

graphics/04fig15b.gif



Reality Macromedia ColdFusion MX. Macromedia Flash MX Integration
Reality Macromedia ColdFusion MX: Macromedia Flash MX Integration
ISBN: 0321125150
EAN: 2147483647
Year: 2002
Pages: 114

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net