Design Process - Development
Programming Guidelines
We have worked on many projects over the
years and seen some very talented programmers whose work was almost
unmaintainable by the rest of the development team. Their code was
brilliant but completely un-readable. Nobody had a clue how it worked.
We've also seen the opposite case where a junior programmer doesn't
follow basic coding conventions, properly handle exceptions or comment
their code.
Having a formal Programming Guidelines
document is meant to address these two extremes. A formal set of
guidelines is essential in having the developers follow a consistent
design when coding their use cases. These guidelines should include the
best practices for implementation of common tasks, such as exceptions
handling, database access, unit testing and logging.
The scope of the document should reflect the
current high level design and requirements within the project and may
be amended to include new requirements. These guidelines act as a great
introduction to new developers on the team and will form the foundation
for the code reviews which will be performed after the development of
the use cases are complete.
The key for the document is to enforce
consistent coding and programming patterns. This may be difficult to
enforce particularly with senior developers who may want to show how
smart they are by implementing their own special routines for handling
common tasks. However, enforcing programming guidelines will not only
make the code easier to understand but also ensure that it is
maintainable for future programmers that will be supporting the code
base.
Coding
This is the actual coding phase. Based on
the previous design steps, a developer should have sufficient
information and confidence to proceed with development. Developers
should be reviewing the use cases often in order to ensure that all of
the requirements are properly met. We suggest that developers make use
of a good IDE for coding as well as a code management (CM) tool for
version control.
Developers should also practise sandbox
development. Every developer has their own sandbox to play in without
disturbing other developers. This isolates developers from the effect
of their work until they are ready. Sandbox development should apply to
all resources: source code, web services and database instances. We
once worked on a project where a team of 30 developers all shared the
same database instance. You can imagine how fun it was to do any
testing with everyone writing to the same database instance. Also,
forget about writing any sort of repeatable unit test cases since any
changes you do will impact all other developers. It may be a bit of
work to setup each developer with their own sandbox but its well worth
the effort.
Code Reviews
The one common thread that appears in large
development systems is that all coding efforts run a high risk for
defects or standards-compliance violation. These defects could cost
millions in re engineering efforts if they make their way into
production software. Add to this the liability costs associated with
defective software in critical systems such as banking or health care
applications.
Formalized code reviews can uncover these
shortcomings before the code achieves production status. The goals of
code reviews are as diverse as the environments in which they're
created. However, almost all code reviews have the following objectives
in common:
Developer code reviews are performed to
ensure that each developer adheres to the Programming Guidelines and
focuses on low level details such as coding style, variable naming,
transaction handling, exception handling, system logging, etc... This
review is normally done at the developer's workstation using a
predefined checklist.
Developer code reviews should be performed
once a use case is nearing completion. The code review should be done
between the developer and the Lead developer. The code review results
are published in the Wiki and follow up work is tracked trough a bug
tracking tool. It should be the Lead Developer's responsibility to
ensure that the developer has applied to necessary changes to their use
case.
Junior developers will usually welcome a
code review because they are looking for any feedback and guidance on
their work. Senior developers and consultants will usually hate the
review because they don't like having someone looking over their
shoulder and criticize their work. However, even senior developers can
overlook something in their code and having a second pair of eyes to
verify the work will almost always improve the quality of the code.
Return to Design Process
|
