SummaryBy Thomas E. Davis
Thomas Davis recommends four books that will provide you with what it takes to excel in Java development. The books extend beyond the basic syntax and semantics of Java to provide you with a comprehensive understanding of object-oriented programming. (1,200 words)
n this article, I present a treatise on the subjects that
separate the rookies from the pros in Java development and a reference to the
books that will help you cross that line. This is not a book review under the
guise of an article. This is your ticket to the next step in your career
development.
Java is a programming language. It is also a tool, and a tool in the wrong hands is useless, sometimes even dangerous. Knowing only the syntax and semantics of Java does not a programmer make. A programmer must also know and understand intimately the environmental paradigm, which in Java's case, is object-oriented design. It is not enough to understand what an object is, what an interface is, how objects implement interfaces, ad nauseam. A programmer needs to know the mystic ways in which those rules and relationships can be combined into flexible, reusable, and scalable systems. The books that I discuss here will give you those lessons and enhance your career as a Java developer. Ironically, none of them contain the word Java in their titles.
Note: URLs for all books discussed in this article can be found in Resources.
Design patterns
To paraphrase the
book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, John
Vlissides, and Grady Boocha (Addison-Wesley, 1995), a pattern describes
a recurring problem and proposes a reusable solution. Patterns simplify your job
by helping you avoid the pitfalls of memory limitations via object sharing --
with Flyweight, for example -- or create a swapable integration with third-party
libraries such as Facade. Design Patterns details those two patterns,
plus a score more, and provides code examples and easy-to-understand diagrams.
Although the code samples are all in C++, the syntax sufficiently resembles
Java; most programmers will thus have no problem grasping the concepts. There is
an imitation of this book available that uses Java for the examples -- Java
Design Patterns: A Tutorial by James William Cooper
(Addison-Wesley, 2000) -- but you won't find the same clarity and depth
that the Gang of Four (the authors' established nickname) conveys in Design
Patterns.
Once you are familiar with the patterns cataloged in Design Patterns, learn how some of them evolved. In Pattern Hatching: Design Patterns Applied (Software Patterns Series) (Addison-Wesley, 1998), John Vlissides -- one-fourth of The Gang -- recounts the debates and discussions over some of the more popular patterns and introduces some new patterns that didn't make the cut in Design Patterns.
Refactoring
To err is human. If that
is true, I've seen hundreds of programs that are more human than I. Projects go
wrong. Mistakes are made. Schedules slip, and quality is sacrificed. Those make
up the caveats of our profession. But where do you turn when things reach their
worst? Too many of my colleagues belong to the "throw-away-and-start-over" camp:
start over from scratch and hope that you've learned from your mistakes. That is
the most extreme solution, one that is sure to infuriate your boss. But don't
despair because there are alternatives.
Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series) by Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts (Addison-Wesley, 1999) offers developers various options to starting over. Refactoring is the process of improving performance by reorganizing a program's internal structure without altering external behavior. Refactoring could make a method run faster or provide more accurate results without changing the method's signature. The changes are invisible to the programs that call the method, so no code requires modification.
The book teaches the reader how to identify problematic code by associating it with a particular smell and relates each to a catalog of procedures for repair. For example, a smell might be Inappropriate Intimacy, which describes two or more classes so tightly integrated that a change to one requires a change to another. One of the handful of possible solutions that the book suggests is Move Method, which constitutes the relocation of the smelly method into a more appropriate class.
Antipatterns
Software design isn't
the only area prone to missteps and oversights. Management is equally
susceptible to the pitfalls of the chaotic development process and surreal
schedules. Most Internet shops have an alarming rate of employee turnover in
their development departments. As programmers come and go, the hierarchy of
responsibility becomes as convoluted as the source code structure. That is where
the book AntiPatterns: Refactoring Software, Architectures, and Projects in
Crisis by William J. Brown, Raphael C. Malveau, William H. Brown, Hays W.
McCormick III, and Thomas J. Mowbray (John Wiley & Sons, 1998) fits
into your overall career objectives. It catalogs common errors in planning and
mismanagement and postulates ways to dig yourself out of the abyss.
Does your project suffer from the Design by Committee antipattern, meaning that too many chefs are spoiling the soup? Or perhaps your code base has fallen into the Vendor Lock-In antipattern, leaving you dangerously dependent on a third-party product. AntiPatterns classifies a dozen of those issues and about two dozen more mini antipatterns, and guides you in avoiding them and in breaking free from the traps you happen to fall into.
Extreme programming
Extreme
programming (XP) is a fresh and somewhat controversial new development process
spearheaded by Kent Beck. XP strives to deliver good software on time without
the bureaucracy and paper trails of traditional development. In the hectic
environment of Internet startups, everybody focuses on time-to-market. In the
real world, projects that run over budget and past their deadlines get
cancelled, causing some companies to eventually fold. The reams of documentation
and diagrams produced at the beginning of the project rarely reflect the final
product. Thus, development teams need to be adaptive and responsive to frequent
changes in the project's requirements. That is where XP shines.
"Communication, simplicity, feedback, and courage" is the mantra of the XP devotee. Achieve communication by, for example, programming in pairs. One person codes while the partner performs a realtime peer review.
Simplicity argues for building only what you need when you need it. Don't waste time engineering extravagant solutions for problems that might arise in the future.
Feedback relates to the "release early, release often" rule of which so many open source fanatics are fond. By putting the product in front of the customer's face early in development, you are more likely to avoid drastic change requests later in the cycle.
Finally, courage urges the XP disciple to take chances and learn from the results. On rare occasions, you just might have to resort to the "throw-away-and-start-over" technique. That mantra along with how XP can help you are described in Extreme Programming Explained: Embrace Change by Kent Beck (Addison-Wesley, 1999).
Conclusion
I was recently awarded
the opportunity to start a company from scratch. My development teams live and
breathe by the teachings of those books, and the results have been phenomenal.
We've built extremely robust and scalable systems, on schedule, with no
overtime. Those books have changed my career for the better, and I believe they
can change yours as well. 
 |
About
the author Thomas E. Davis is a Sun-certified Java developer and the chief technology officer of his second successful Internet startup. Thomas currently resides in sunny south Florida and regrettably spends most of his time indoors in front of a computer. |
(c) Copyright 2000 ITworld.com, Inc., an IDG Communications company