We ll take a look at all the code in a moment. It looks rather good for a few hours work. It s not entirely robust, however. A wise programmer might enclose the file operations in try/catch to handle unexpected exceptions like running out of storage or other unexpected problems. And I would like to have more tests. In particular, we don t have a customer test for Save, which could leave a problem undetected later. However, I tested Save manually, and it works. Other refinements are also possible. The customer didn t ask for it, but there s probably a need for a dialog popping up with a save warning when the program terminates. I would make it clear to the customer that we did not plan to do it, and didn t do it, and let them schedule it when they want it.

We got in a little trouble by deferring a test. You d think that I would learn my lesson about that: whenever I skimp on tests, I wind up with defects, or confusion, or both. I hope that you are smarter than I am and that you rely on tests more consistently.

And another force is acting on me. As I started working on this, my editor was pressuring me to get everything about the XML Notepad done by a particular deadline. My estimates showed that the deadline was unlikely , and I replied reasonably ”as appears elsewhere in the book ”that I would provide estimates for the work and would track my estimates and that our management challenge was to find the right balance between new features and revision of old chapters. I pointed out that we might decide that the date was wrong, so as to have the book be good enough, or that we might reduce scope to make the date.

Nonetheless, even after pointing out that I m working as effectively as I know how and that the management mission is to manage scope for an ideal product by the desired date, I ve been feeling pressure to go fast all day. The effects are subtle. Under too much pressure, I ll start making mistakes and getting into trouble. That didn t happen today. What did happen, I believe, is that this story and the code supporting it are not as refined as they would usually be. They re good enough to get by, but they don t feel sufficiently polished. Take a look at what we have wrought and see what you think. Then decide your own proper response to pressure.

Extreme Programming Adventures in C#
Javaв„ў EE 5 Tutorial, The (3rd Edition)
ISBN: 735619492
EAN: 2147483647
Year: 2006
Pages: 291 © 2008-2017.
If you may any questions please contact us: