Bitter Java Chinese Version

Author: (USA) Tate / Su Jinquan, etc.
Publisher:
Publish Date: 2006-02-01
Features: To be honest, few computer books can captivate me, but Tate's BitterJava is an exception. This book kept me hooked, and I couldn’t wait to turn the page after every chapter. If you ask for my advice? Simple: if you can’t put aside your tasks and can’t dedicate a full day to reading this book peacefully, then don’t start.
— Hays W. “Skip” McCormick III, co-author of AntiPatterns.
Most software projects fail, and this is a well-known fact. To learn important lessons from these failures is exactly what BitterJava aims to do. Simply reusing design patterns doesn’t guarantee success: patterns are like partial maps of dangerous terrain. They are helpful, but they can’t prevent you from getting lost. This book teaches readers how to realize when they’ve gone astray and how to get back on track. Through code examples, it illustrates common pitfalls in Java programming; it also provides refactoring solutions and explains why the new approach is safer. This book systematically documents common server-side Java programming errors, along with their causes and solutions. It covers anti-patterns related to basic Java and J2EE concepts, such as servlets, JSP, EJB, the enterprise connection model, and scalability.
If you are an intermediate-level Java programmer, analyst, or architect eager to avoid the pain others have experienced, this book is exactly what you need. By studying the anti-patterns introduced in this book—such as round-trip communication, magical servlets, missing caching, and tuning jitter—you can avoid repeating past mistakes and move forward more safely. This book systematically explores common server-side Java programming errors and their causes and solutions. It covers anti-patterns related to basic Java and J2EE concepts, such as servlets, JSP, EJB, the enterprise connection model, and scalability, through code examples that illustrate common pitfalls in Java programming and provide refactoring solutions, explaining why the new approach is safer. This book is suitable for intermediate-level Java programmers, analysts, or architects to read, and by studying the anti-patterns introduced, you can learn from others’ experiences and avoid detours in your work.
[Preface] In summer, the Texas River nearly dries up. To find rapids, rafters have to follow the footsteps of the storm. One summer day in 1996, my companion and I left Austin at 8 p.m. and plunged into the fierce storm, heading straight to the Cossatot River in Arkansas. When we arrived, the bad weather seemed to mock us cruelly by bypassing the river and moving on. Exhausted and disheartened, we had to camp on the riverbank. That night, we didn’t hear a single drop of rain. The next morning, I stumbled out of the tent, dizzy and almost fell into the river. Cossatot River has a notorious reputation for rising rapidly—just two hours of rain upstream caused the water level to surge by six feet. Now we could raft, but the water was too high. We decided to wait until the next morning to tackle the difficult section and raft upstream first. The originally slow Class I water had turned into3. The guidebook said this section would take “4 hours,” but we zipped down in just 20 minutes. The middle section was even worse: the rapids had reached Class 4, roaring fiercely. After careful reconnaissance, we took turns guarding from the shore while one person rafted, tied to a safety harness, with another watching from the bank. Then we left the kayaks at the camp and walked downstream to see what the lower section looked like. To our surprise, dozens of locals were lounging on the riverbank, watching the river like spectators. They had usually seen only Class 4 waterfalls, but now the river was completely dominated by terrifying whirlpools. Before, we rarely saw locals; they were there just to see who would show off or have an exciting incident. The scene left us stunned, so my companion and I also sat on large rocks and watched the spectacle.
Tracing back to 2000, though my position was already high and the compensation was generous, I left IBM to join a startup company called allmystuff. At the time, the economy was already in recession, but while other startups in Austin were collapsing, allmystuff had just secured funding. The company’s business didn’t rely on advertising revenue, so even as advertising income dwindled, it seemed to have little impact. Additionally, allmystuff had gathered many top talents. When I joined, the company had $10 million in bank funds, had stable clients, and possessed advanced technology—all signs that it could become a highly sought-after success. I had seen many friends leave IBM and join other companies, even though the new jobs offered less compensation and security but were full of adventure. I thought I could always go back if necessary, so I faced the impending darkness and plunged headfirst into the storm.
During the Austin news, it was common to hear about the downfall of once-famous startups. allmystuff was also struggling in the. We worked day and night, deploying solutions for only a few clients. Despite our top-notch quality and impressive track record, we were ultimately overwhelmed by the recession. The venture capitalists decided it was best to shut down and look for a new concept to rise again in this economic downturn. Although this was a painful experience, what I learned during that period was unmatched by any other time in my career. Like the locals on the Cossatot River, if an adventure story is real, happening around us, exciting, or even dangerous, most of us cannot resist its appeal. Whether it’s a classic Greek tragedy or a popular show like Survivor, our curiosity is endless. Programmers are no exception. We love to talk about recent adventures (which we call “merctalk”), for many reasons. Many of my vivid work memories were left behind at allmystuff’s ping-pong table. There, we discussed management philosophy; whether the codebase was already out of control; and whether XML with a dedicated browser was a simpler solution compared to increasingly complex JSP models. We also discussed how, as deadlines kept slipping, a graphic designer could map the user interface they designed into increasingly complex Java commands. These discussions ignited my passion, pushing me to leave my stable position and chase the dream of becoming a millionaire into a new job with lower pay and no security. These experiences made me a better programmer, manager, and architect. I don’t remember where, but former IBM Chairman John Akers once said, “Too many people just sit around drinking and chatting, doing nothing.” I remember we were all angry after hearing that. He didn’t know that what we heard (or drank) while sitting around—whether at a ping-pong table or over a cup of coffee—often determined the success or failure of a project (or even a company). Here, it’s necessary to hear some programmer stories, to be inspired, because these can shape a lifetime. I plan to include some of these stories in BitterJava.
Returning to earlier times, before joining allmystuff, I was preparing to give a talk at a conference. The topic was BitterJava. During the conference, I met a famous Java programmer, one of the creators of JSP. He told me he had participated in the run with the bulls in Pamplona (translator’s note: a classic event where people run desperately in front of bulls, who injure many with their hooves or horns, but the participants still enjoy it as a game for the brave) and had been gored. He enthusiastically explained his strategy during the event. I wasn’t impressed. In Pamplona, many people had already told me how to avoid being gored. I even consulted O.J. Simpson on the matter. Every year, tens of thousands of enthusiasts participate, but only a dozen are gored. However, gradually, I had an idea: if I were to participate in the run with the bulls, I would discuss it with him. I wanted to know how he planned it, how he implemented it, and where things went wrong. This information would be useful to me. Later, I found that the gored programmer was the vice president of the engineering department at allmystuff, who recruited me to help establish his service division.
Now, about my talk—I knew telling the Pamplona story might cost me the job at allmystuff, but I still decided to use it to start my speech. It perfectly embodies the concepts of BitterJava. To avoid a subtle trap or pitfall, a story about failure often outweighs ten stories about success. This story captivated the audience, and I got the job. Like many programmers, I love extreme sports. We’ve been in kayaks during dangerous situations, sometimes even facing life-threatening risks. William Neely once shared a famous rule in the rafting world: the longer you stare at a rapid, the more likely it is to swallow you. In other words, if a whirlpool looks big enough to eat you, it probably will. Rafters have their own ways to describe how to navigate a river. The guidebook will mark a route and point out dangers along the way and beyond. It might say, “Next, you’ll see a large rock in the middle; turn left. If you hit it on the right, the rapid will become a ‘terminator,’ letting you know you’re wrong in a brutal way.” I know that even if you don’t fully understand the power of a river, you still want to know where things might go wrong. I want to know if there are rocks under the water, if there are traps waiting for me. I want to know where I might encounter whirlpools and how to avoid large rocks at the bottom of waterfalls. I want to know if people have died on this river and what happened. Without enough knowledge, even with high-level skills, I often avoid going in, even if I follow the riverbank all the way down. Programmers (including me) are the same. I want to know where applications and projects will fail. I want to know if communication with an interface is too much and whether the technology can solve the problem. I need to understand where a technology might fail and whether it can be scaled. I firmly believe that failure is inevitable in software development, and we must learn from it. I haven’t seen any organization systematically learn from mistakes or analyze in a formal, systematic way why a problematic design pattern or process needs to be modified. I’ve seen a lot of code, but not all of it is good. I’ve come to appreciate the charm of “bitterJava” and hope you do too.