Other
Considerations
As I mentioned earlier, we need to do just
enough architecture and design to get us going. Although we did a
reasonable amount of architecture and design in this chapter, there
are a lot of things we haven't discussed yet but will in later
chapters, such as the following:
-
Application
security
This will be covered in Chapters 7, "The Spring Web
MVC Framerwork" and 10, "Beyond the Basics."
-
Transaction
management
This will be covered in Chapter 5. We will see
how to programmatically implement transaction management using
Hibernate.
-
Exception
handling
In Chapter 10 we will look at handled and unhandled
exceptions and provide some guidance on when to use one versus the
other.
-
Other features
Features required for Time Expression such as scheduling jobs and
sending emails will be covered in Chapter 10. Other topics also
discussed in later chapters include logging, tag libraries, and
more.
Big Design Up Front Versus Refactoring
According to Martin Fowler (refactoring.com),
refactoring "is a disciplined technique for restructuring an
existing body of code, altering its internal structure without
changing its external behavior." Many developers have been
refactoring code for
years
, but Martin Fowler gave it a formal
name
(and I'm glad he did).
As you begin to code an application, you will
invariably find better ways to do things than you might have
originally thought of (before coding
began
). For example, this
could include removal of redundant code or cleaning up of code.
Hence, I am a big believer that refactoring should always be an
open
option, not just for code but also for database design,
architecture, documentation, build/integration scripts, and more.
It also alleviates the
burden
of figuring out the entire design and
process of an application up front.
For example, I recently came across a portion in
an
essay
on the agiledata.org website, which helps summarize how I
feel about this subject; this portion states that "Agile developers
iterate back and forth between
tasks
such as data modeling, object
modeling, refactoring, mapping, implementing, and performance
tuning."
Take this book, for example. This is
essentially
a project for me as I'm developing a sample application from
scratch and a book
alongside
it. Although I have done some upfront
planning, I don't have 100% of the answers figured out, but I am
not worried because I can refactor the architecture, design, code,
or process used for Time Expression in later chapters because I
want to make progress now instead of spending too much time trying
to think of every possible scenario that could go wrong.
In short, you should definitely do some initial
architecture and design, but keep in mind that if there is a way to
improve something that adds value, such as simpler or cleaner code,
and if it is not too late in the process (for example, the day of
acceptance tests or deployment), you should go ahead and
refactor!
|
