【文章內(nèi)容簡(jiǎn)介】 cedural languages, it is mendable that a team will want to proceed carefully and understand every minute detail before moving to design and implementation. Certainly, when creating a Database Management System (DBMS), it pays to understand a customer’s needs thoroughly. But a DBMS is in a class of problems that is very wellposed and wellunderstood。 in many such programs, the database structure is the problem to be tackled. The class of programming problem discussed in this chapter is of the “wildcard” (my term) variety, in which the solution isn’t simply reforming a wellknown solution, but instead involves one or more “wildcard factors”—elements for which there is no wellunderstood previous solution, and for which research is to thoroughly analyze a wildcard problem before moving into design and implementation results in analysis paralysis because you don’t have enough information to solve this kind 英文翻譯 原文 第 12 頁(yè) (共 21 頁(yè) ) of problem during the analysis phase. Solving such a problem requires iteration through the whole cycle, and that requires risktaking behavior (which makes sense, because you’re trying to do something new and the potential rewards are higher). It may seem like the risk is pounded by “rushing” into a preliminary implementation, but it can instead reduce the risk in a wildcard project because you’re finding out early whether a particular approach to the problem is viable. Product development is risk management. It’s often proposed that you “build one to throw away.” With OOP, you may still throw part of it away, but because code is encapsulated into classes, during the first pass you will inevitably produce some useful class designs and develop some worthwhile ideas about the system design that do not need to be thrown away. Thus, the first rapid pass at a problem not only produces critical information for the next analysis, design, and implementation pass, it also creates a code foundation. That said, if you’re looking at a methodology that contains tremendous detail and suggests many steps and documents, it’s still difficult to know when to stop. Keep in mind what you’re trying to discover: What are the objects? (How do you partition your project into its ponent parts?) What are their interfaces? (What messages do you need to send to each object?) If you e up with nothing more than the objects and their interfaces, then you can write a program. For various reasons you might need more descriptions and documents than this, but you can’t get away with any less. The process can be undertaken in five phases, and a Phase 0 that is just the initial mitment to using some kind of structure. Phase 0: Make a plan You must first decide what steps you’re going to have in your process. It sounds simple (in fact, all of this sounds simple), and yet people often don’t make this decision before they start coding. If your plan is “l(fā)et’s jump in and start coding,” fine. (Sometimes that’s appropriate when you have a wellunderstood problem.) At least agree that this is the plan. 英文翻譯 原文 第 13 頁(yè) (共 21 頁(yè) ) You might also decide at this phase that some additional process structure is necessary, but not the whole nine yards. Understandably, some programmers like to work in “vacation mode,” in which no structure is imposed on the process of developing their work。 “It will be done when it’s done.” This can be appealing for a while, but I’ve found that having a few milestones along the way helps to focus and galvanize your efforts around those milestones instead of being stuck with the single goal of “finish the project.” In addition, it divides the project into more bitesized pieces and makes it seem less threatening (plus the milestones offer more opportunities for celebration). When I began to study story structure (so that I will someday write a novel) I was initially resistant to the idea of structure, feeling that I wrote best when I simply let it flow onto the page. But I later realized that when I write about puters the structure is clear enough to me that I don’t have to think about it very much. I still structure my work, albeit only semiconsciously in my head. Even if you think that your plan is to just start coding, you still somehow go through the subsequent phases while asking and answering certain questions. The mission statement Any system you build, no matter how plicated, has a fundamental purpose—the business that it’s in, the basic need that it satisfies. If you can look past the user interface, the hardware or systemspecific details, the coding algorithms and the efficiency problems, you will eventually find the core of its being—simple and straightforward. Like the socalled high concept from a Hollywood movie, you can describe it in one or two sentences. This pure description is the starting point. The high concept is quite important because it sets the tone for your project。 it’s a mission statement. You won’t necessarily get it right the first time (you may be in a later phase of the project before it bees pletely clear), but keep trying until it feels right. For example, in an airtraffic control system you may start out with a high concept focused on the system that you’re building: “The tower program keeps track of the aircraft.” But consider what happens when you shrink the system to a very small airfield。 perhaps there’s only a human controller, or none at all. A more useful model won’t concern the solution 英文翻譯 原文 第 14 頁(yè) (共 21 頁(yè) ) you’re creating as much as it describes the problem: “Aircraft arrive, unload, service and reload, then depart.” Phase 1: What are we making? In the previous generation of program design (called procedural design), this is called “creating the requirements analysis and system specification.” These, of course, were places to get lost。 documents