1.3. The Guidelines Explored

 <  Day Day Up  >  

Our goal as developers is to make understandable, readable, and maintainable code. The guidelines in this book are designed to help you reach this goal. The guidelines presented in this book do not represent best practices. "Best" can be determined only in the context in which you are currently developing a system. However, the guidelines do represent suggestions for creating good practices appropriate to your context.

EXCEPTIONAL GUIDELINE

There are exceptions to every guideline, except this one.


Many of the guidelines are different manifestations of the same basic principles. The underlying principles have tradeoffs in their application, which also appear in the derived guidelines. For example, applying the principle of separation of concerns usually creates more classes and more methods . Consistency, even though it might increase the amount of code, also makes systems that do similar things have the same structure, thus decreasing learning. A concentration on interfaces and delegation increases the number of delegating methods.

1.3.1. Context Is Everything

One rule exists: nothing works everywhere, and hence, you must be the judge if a particular practice is appropriate for your application. You need to apply principles in context . The decision whether to use a particular principle or practice depends on the situation in which it is employed. When you try to apply the same principle or style to everything, you can create waste or confusion. To require vast documentation on a program that is to be used only as a transition to another program is wasteful . Failure to document fully the program in a cardiac pacemaker might be fatal. Similarly, some programs, such as pacemakers and avionics , need to deal with lots of error handling. Other programs can have simpler error processing, such as a browser that needs to display an error message only if it does not get a reply from the server.

The number of people involved in a system affects how you develop the system. I spend much less time worrying about prefactoring on simple scripts that only I use. If someone else is going to run the scripts, I spend more time dealing with issues such as input validation and meaningful error messages.

If a system involves architecture or technology that is new to you, an initial exploration of the solution space is valuable . You can create an end-to-end model of the system to try out all the technologies involved. This model can yield clues as to how these guidelines can be adapted to the new environment.

This book outlines abstract guidelines and examples of guidelines in action. Sometimes recognizing the situations in which a guideline is appropriate and applying the guideline appropriately is the biggest issue. Experience and discussion with others can help determine the appropriate use of a particular guideline.

BACKPACKING CONTEXT

I have to plan more before I embark on a weeklong backpacking trip than I do before I go out for a one-hour stroll. For a daylong event, I will probably put on hiking boots and take along a few items, such as snacks and water. For a one- hour stroll, I might wear just the shoes that I have on. The context of the hike influences my approach to it.


1.3.2. Adapt to Your Own Style

No one has the perfect way of creating software. It is still an art. Does one style fit all? What kind of car do you drive? Are other people wrong to drive a car that is different from yours? They have different needs, desires, value systems, and budgets . Their car might meet their values. In my opinion, only one car on the road is pretty close to being absolutely wrong: the Hummer.

The guidelines and themes presented in this book are suggestions. Treat them as starting points for examining your own software development process. By analyzing your approaches to different problems, you can create your own set of prefactoring guidelines that are applicable to your own experiences within your problem space.

1.3.3. Retrospect on Your Experiences

The guidelines in this book come from experience . You have experience in program development. You might have created a design from scratch or borrowed one from a previous system, or from an article or book. The design might have worked well or might have had serious flaws if it did not fit well with the problem it was intended to solve.

At the end of a project, you might have had a retrospective (read Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth [Dorset House, 2001]). In a retrospective, the project team evaluates the development process and preserves the lessons learned from its successes and failures. While many retrospectives concentrate on interpersonal issues, you should also examine the technical solution. "If you do not appreciate history, then you are doomed to repeat it" (George Santayana).

In a technical retrospective, you evaluate the design of the system you just finished building. How well did the architecture suit the problem space? What would you have done differently? What questions should you have asked in the beginning? What requirement changes forced you to alter the design dramatically? What prewritten components would you look for the next time?

You might have encountered a bug in your program. Instead of just solving the immediate bug, you might have analyzed it to determine why the bug occurred. For example, it might have been caused by failure to validate the input. Therefore, you add input validation to the list of guidelines to use when creating future code.

Experience of others is also applicable to your project. Much of what is being created today was accomplished in some way in the past. The books on patterns (such as Design Patterns , discussed in brief in the Preface) are an accumulation of that experience. What you develop today will be somewhat different from the past solution (or else you would simply use the past solution). Therefore, it is a matter of deciding what past practices to apply to the work you do today. However, if you impose a pattern that is not applicable to the circumstances of your project, you might create an antipattern.

The retrospective process need not occur just at the end of a project. Continual retrospectives can aid in refining the development process.

WHAT SAIL AND BOARD TO USE TODAY

I am standing on the shore with a few other windsurfers. No one has been out so far today. We are discussing the size of sail to rig and the size of board to sail. They are important decisions. If the sail is too big, you will be overpowered; the wind will pull you over. If it is too small, you will just plod along. If the board is too big, the waves will batter you. If it is too small, you will sink.

You guess and try to reach a common consensus with the other sailors. Local experience helps you to make the right decision. You see whitecaps, but the locals know that ones from a Northeast wind form in much less speed than those created by a wind from the Southeast.

Without any experience, you might often choose the wrong sail and board. The more experience you have, especially in terms of local conditions, the more often you will be right.


 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net