First, it is through practice in small that professionals gain the skills and confidence to practice in large. However, even in the auto industry, most of the work is not in production, but in maintenance - or the avoidance of it. In our search for others who attribute the house of God to detail, we find ourselves in the good company of 19th-century French author Gustave Flaubert.
These are not peripheral concerns, but concerns that lie squarely at the heart of Agile values. We become more fully human, more worthy of the divine, and closer to that greatness in detail. As we walked through and cleaned up the code in the case studies, we documented every reason for our actions as a.
This knowledge base is of limited value if you do not do the work to carefully read through the case studies in the second part of this book. It's not the heuristics themselves that are so valuable, it's the relationship between those heuristics and the discrete decisions we made while cleaning up the code in the case studies.
Acknowledgments
We tried to understand our reactions to the code we were reading and changing, and we worked hard to capture why we felt what we felt and did what we did. The result is a knowledge base that describes how we think when writing, reading, and cleaning code. In those case studies, we carefully annotated any changes we made with forward references to the heuristics.
To further assist you with those relationships, we have placed a cross-reference at the back of the book that shows the page number for each forward reference. If you read the first and third sections and get past the case studies, then you will have read another "feel good" book about writing good software. But if you take the time to work through the case studies, following every little step, every minute decision—if you put yourself in our shoes and force yourself to think along the same lines that we did, then you'll earn a much richer understanding of those principles, patterns, practices and heuristics.
They will have become a part of you in the same way that a bicycle becomes an extension of your will when you have mastered how to ride it.
Artwork
The client believes it is calling getAccounts() on a Bank object, but it is actually talking to the outside of an array of nested DECORATOR14 objects that extend the basic Bank POJO behavior. This type of architecture is so compelling that frameworks like Spring led to a complete revision of the EJB standard for version 3. However, because none of this information is outside the annotations, the code is clean, clear, and therefore lightweight to be tested, maintained, and so on.
Some or all of the persistence information in the annotations can be moved to XML deployment descriptors if desired, leaving a truly pure POJO. The pure Java approaches of Spring AOP and JBoss AOP are sufficient for 80 to 90 percent of the cases where aspects are most useful. If you can write the domain logic of your application using POJOs, decoupled from all code-level architecture issues, then it is possible to truly test your architecture.
In fact, BDUF is harmful because it hinders adaptation to change, because of the psychological resistance to rejecting previous efforts, and because of the way architectural choices influence subsequent design thinking. Construction architects must adopt BDUF because it is not feasible to make radical architectural changes to a large physical structure once construction is in full swing.19 Although software has its own physics,20 it is economically feasible to make radical changes, if the structure of the software separates concerns are effective. Some of the largest websites in the world have achieved very high availability and performance, using advanced data caching, security, virtualization, etc., all in an efficient and flexible way, because the minimally coupled designs fit at every level of abstraction and scope be simple.
Of course, this does not mean that we start a project without direction. We have some expectations of the overall scope, objectives, and schedule of the project, as well as the overall structure of the resulting system. A good API should be largely hidden from view most of the time, so the team spends most of its creative effort on the user stories being implemented. In a large enough system, be it a city or a software project, no one person can make all the decisions.
We often forget that it is also better to postpone decisions until the last possible moment. Building construction is a wonder to behold because of the pace at which new buildings are constructed (even in the dead of winter) and because of the incredible designs that are possible with today's technology. However, the standards creation process can sometimes take too long for the industry to wait, and some standards lose touch with the real needs of the adopters they are intended to serve.
