开云体育

Hi, I have created an email discussion group for XP and put you guys in it. I hope you don't mind. Discussion of Extreme Programming practices and principles (English) Cheers, Robert C. Martin

Dave Thomas writes: Tracing is something I do to solve complex, primarily hundreds++ multi-user, problems. Maybe it could be said that if I wrote unit tests well enough, then I would not need to trace complex multi-user scenarios. I hope some day that is true! I can tell you though I am (1) either not smart enough to hold so many ideas in my head; or (2) not diligent enough to find out that I am smart enough; or (3) too embarrassed to ask my friends to help me find out. So I would expect to add tracing to a system as soon as one of these kinds of problems reared its ugly head. That said, I have not read much about how to apply XP to complex multi-user systems. Are functional tests where multi-user testing is to take place? Is there ever anything a functional test should include that a unit test does not? -- Patrick Logan patrickdlogan@...

This is a very nice way to put it and to me also explains why many people in the beginning tend to be fundamentalists about XP. I totally agree with you in general - we should demonstrate payoff. But that's not really the way things are, and I think that's an idealistic point of view. Especially when things hit larger scales they tend to be more technology-driven than business-driven - at least that's what I have witnessed. It is good to release early and release often, do small increments etc. But there comes a time (or rather, a scale) where you have to establish a standardization organization, define processes, frameworks, etc. And all of a sudden your whole release thinking breaks down. This is where many of the framework guys kick in and say: "Look, you can't let loose a bunch of programmers and expect order just to emerge." This is because they are technology-driven while your thinking is business-driven, simplifying matters a bit here. And this is about the whole or a big part of the chasm I perceive. If XPers were a bit less enthusiastic about the applicability of XP on any scale and the opponents a bit less contemptive of the style of "rolling up the sleeves and start working", I guess both sides could learn a lot from each other. My ideal world would contain a blend of business-/change-driven and technology/stability-driven thinking (please don't take the wording too literal here). Working out what the best mixture is would be a fantastically interesting thing to do. Would anybody be interested in that? HW -- Phone: +41-1-334 66 51 Fax: +41-1-334 50 60 Web: http://www.credit-suisse.ch

backwards

<brougham2@...> wrote in message news:g9tvOEuL+JwgdytR6VTasnqHZLeH@...... three can The advantage is that you need one third the resources, i.e. space, desks, computers, licenses, etc. each at the of his having everybody is If you are pair programming, and if your shifts overlap by 50%, then the communications overhead should be minimal. At shift change only one member of each pair changes. Thus, continuity can be preserved. Of course I've never tried this, or seen it tried, so its speculation on my part. -- Robert C. Martin | OO Mentoring | Training Courses: Object Mentor Inc. | rmartin@... | OOD, Patterns, C++, Java, PO Box 85 | Tel: (800) 338-6716 | Extreme Programming. Grayslake IL 60030 | Fax: (847) 548-6853 | http://www.objectmentor.com "One of the great commandments of science is: 'Mistrust arguments from authority.'" -- Carl Sagan

Bob Binder has a pattern called "Percolation" that describes how to do this. It's in his book "Testing O-O Software" which came out in October. It also appeared in C++ Report in the first half of 1999. The DbC pre/post conditions and invariants are just part of the formal spec though. They don't really include the unit-tests so its not quite similar to XP there. It is similar in that it tries to force you to think about the valid and invalid cases and boundary conditions before you code though. Another perhaps XP-like thing about Eiffel, it was made to read like an english prose formal spec so that the spec and code would be one and the same artifact (kind of like "the source code is the design" and preferring more readable code to additional comments :-) -- Brad Appleton <bradapp@...> http://www.enteract.com/~bradapp/ "And miles to go before I sleep." -- Robert Frost

Important safety tip, Egon, don't cross the streams. And don't Reply All to an extremeprogramming group email, in at least some mail systems. It sets up the "To" line thusly: extremeprogramming@..., <extremeprogramming@...> resulting in two copies of your stuff going to everyone. Any individuals also on the list will get three. If you send it to otug and extremeprogramming, they'll get four. One's enough. I think it's fair to assume that if Joe sent you something on the list, he'll be there to see your reply. It may be that an additional "courtesy" copy is one too many. Just one man's opinion - one man who is confused by four copies of this excellent material. Thanks, and if anyone asks you if you are a god, answer "yes". Ron Jeffries Extreme Programming Training and Consultation ronjeffries@... web pages: http://www.XProgramming.com, http://www.armaties.com pgp key: http://www.armaties.com/pgpkey.htm

"Michael C. Feathers" wrote: Michael, just curious: What's your most recent view on your (former) perception that MethodsShouldBePublic? Do you refactor? Or do you "mark" as private? I kind of HaveThisPattern more and more. Frank

Robert Martin writes: From my perspective, the OCP implies this sort of flexibility, but this sort of flexibility does not imply the OCP. I don't remember anything in what I've read of XP that said, "The source code of [an extensible] module is inviolate" (to quote from your 1996 paper, "The Open Closed Principle"). If anything, I'd say it values keeping all code open for modification, against the day when it becomes too simple to meet the new requirements. This may not be a philosophical difference between "Designing OO C++ Apps Using Booch" and XP -- the fundamental principle is to be ready for change -- but it does lead to a practical difference in what one does on any given day. Is your confidence in the ability of a designer to know when and where the design will need to change the same today as it was five years ago? I look forward to this. Tom -- Tom Kreitzberg | The Johns Hopkins University Tom.Kreitzberg@... | Applied Physics Laboratory

Hi, I'm new to this mailing list, and I don't know if this point was discussed before. I always get confused when I read terms like Collective Code Ownership and Collective Ownership. On www.extremeprogramming.org Collective Code Ownership is explained with Collective Ownership. But what does that mean? Should Collective Code Ownership really be extended to Collective Ownership? Does it include Collective Task Ownership? Does Ownership includes Responsibility? As long as I can oversee the means of collective ownership it should be limited to code ownership. It's IMO not useful to extend this to collective ownership for the whole process in the means of responsibility. Max

Tom Kreitzberg wrote: XP has made me look at OCP more as a metric or goal than a principle of day to day design. Sure it would be nice (ideal even) if extending a class always meant sub-classing it and adding new functionality to the sub class. In reality, however, we don't know everything we'll ever need to know about a class when we first write it. That seems to be a fundamental precept of XP. My strategy is to wait until I need to make a change and then see if OCP is applicable (changed requirements or clients often aren't new requirements or clients almost always do), and if it is I ensure that the class supports it before making the change. The result is that as classes mature they become more likely to support OCP for any given change. You can use OCP to measure the maturity of a class by keeping track of how often the class supports it in practice. I also use a modified form of OCP in practice: I don't get too bent out of shape if I learn that I need a new method to handle a new form of an existing request or to automate a commonly used sequence of requests. Technically that requires the class to change. But in practical terms it doesn't mean much risk of altering existing code or breaking existing tests. On a larger project with longer compile times, however, this might become a more serious issue. -- Phil Goodwin, Java Software, Sun Microsystems, 408-517-6951, or x66951

Notice that Once and Only Once tends to create the OCP in the right places. You write it once. When you modify it, you tend to separate the variable parts into separate objects. Then the original object no longer needs modification. Kent