05 design practices

Design Practice 1. Iteration

? When you loop through the alternative design scheme and try different practices, you will examine the problem from different perspectives at the top and bottom layers at the same time. The wide range of channels you get from the high-level perspective will help you consider the relevant low-level details. The details you get from the lower-layer perspective will also lay the foundation for your high-level decision-making. The interaction between high and low layers is considered as a benign motive force. The structure created by the interaction is far more stable than the structure created from top to bottom or from the bottom up.

? Don't stop when you first try a design that looks good enough! The second attempt will almost certainly be better than the first one, and you will also get something from each attempt, which will help improve the overall design.

2. Divide and conquer

? No one's mind can hold all the details of a complex program, which is equally effective for design. Break down the program into different regions of interest and process each region separately. If you encounter a dead end in a certain area, it will fall.

? Incremental improvement is a powerful tool for managing complexity. As polyA suggested in solving mathematical problems-understanding the problem, forming a plan, executing a plan, and then review your practices.

3. top-down and bottom-up design methods

? A top-down design starts with a very high level of abstraction. You define the base class or other design elements that are not very special. In the process of developing this design, you gradually increase the level of details to find out the derived classes, cooperative classes, and other design elements with more details. The bottom-up design begins with details and extends to general. This design usually starts from looking for a specific object, and finally generating the object and base class from the details.

• Top-down arguments

  ? The principle of understanding behind top-down methods is as follows:The human brain can only focus on a certain amount of details at the same time. If you start from a general class and break them down into more specific classes step by step, your brain will not be forced to process too many details at the same time..

  ? This divide and conquer process is also iterative in some sense. First, it is iterative, Because you usually do not stop after a layer of decomposition. You will continue to break down several layers. Secondly, it is iterative because you are generally not satisfied with your first attempt. You can use a method to break down the program. In different stages of the decomposition process, you need to choose the method to break down the subsystem, give the inheritance relationship tree, and form a combination of objects. You make a choice and then see what the result is. Next, you can use another method to start the decomposition again to see if the method works better. After a few attempts, you will find out which methods will work and why they will work.

  ? How can we determine the degree of decomposition? Continue to break down until it looks easier to directly encode the next layer than to break down. It is obvious and very easy to design your ideas, so you are tired of continuing to break down. At that time, you completed the decomposition work. If the design logic is unclear, please do more. If the current solution is tricky for you, you will surely feel a lot of burden when others face it again in the future.

• Bottom-up arguments

  ? Sometimes top-down methods are too abstract to start. If you prefer to use a more practical method, you can try the bottom-up method. Ask yourself, "What do I know about the system ?" You can answer this question without any doubt. You may find some underlying responsibilities that can be assigned to a specific class. For example, you know that a system needs to format the report, calculate data for the report, center the title, display the Report on the screen, and print the report. Once you find out some of the underlying responsibilities, you usually feel comfortable watching the system from the top.

  ? In other cases, some of the main attributes of the design problem are determined by the underlying layer. You may need to deal with hardware devices. Their interface requirements determine a large part of your design.

  ? The following are some factors you need to consider when performing bottom-up synthesis:
  (1) ask yourself what you know about the system.
  (2) identify the specific objects and responsibilities based on the above problems.
  (3) identify common objects and organize them in the appropriate way-subsystem, package, object combination, or integration-to see which method is suitable.
  (4) continue to work at the top layer, or go back to the top layer and try to design down.

• In fact, there is no dispute

  ? The most important difference between a top-down policy and a bottom-up policy is that the former is a decomposition policy while the latter is a synthesis policy. The former resolves a general problem into a controllable part. The latter constructs a general solution from the controllable part. Both methods have their own strengths and weaknesses. If you want to use them in design, you need to consider them.

  ? The top-down design strength is that it is very simple, because people are very good at breaking down some big things into small components, while programmers are more refined here.

  ? Another strength of top-down design is that you can postpone building details. Software systems are often harassed by changes in Building Details (such as changes in file results or report formats). Therefore, you should know as early as possible that these details should be hidden in the underlying classes of the inheritance system, is very beneficial.

  ? One of the strengths of bottom-up design is that it is usually able to identify the required functions earlier, resulting in a compact, reasonable structure of the design. If similar systems have already been used, the bottom-up design allows you to examine existing systems and propose "what can I reuse ?" First, the design of the new system is started.

  ? A weakness of bottom-up design is that it is difficult to use it independently. Most people are good at breaking down big concepts into small ones, rather than coming up with big ones. This is like assembling toys on my own: I think I have already completed the Assembly, but why are there parts in the box? Fortunately, it is not necessary to apply only the bottom-up design method.

  ? Another weakness of bottom-up design is that sometimes you find that you cannot use the existing parts on hand to construct the entire system. You cannot use bricks to build planes. You may need to first design a high level to know what parts are needed at the bottom layer.

  ? All in all, top-down design is usually easier to use, but sometimes it will be affected by the complexity of the underlying layer. This impact may even make things more complex than the actual situation. The bottom-up design is complicated at the beginning, but early identification of the complexity of the system helps to design a better High-level class. Of course, the premise is that the complexity does not destroy the entire system.

  ? Finally, top-down and bottom-up designs are not mutually exclusive-you will benefit from mutual collaboration between them. There is a heuristic (testing) process during design, which means that er has no solutions to ensure that nothing is lost. The design process is full of repeated tests. Please try more design methods to find the best one.

4. Establish experimental principles

? Sometimes, it is difficult to determine whether a design method works unless you have a better understanding of implementation details. For example, before you know that it can meet performance requirements, it is difficult to determine whether the organizational structure of a database is applicable. Before selecting the GUI program used by the system, you may not be able to determine whether the design of a specific stator system is in place. These are examples of essential "sinister" in software design-unless you partially solve a design problem, you cannot completely define the design problem.

? There is a technology that can solve this problem at a low cost, that is, building an experimental prototype. "Build a prototypeThe term "has different meanings for different people. Here, the prototype refers to"Write the code that is used to answer specific design questions with the least amount and can be discarded at any time".

? If developers do not grasp the principle of using the least code to answer graph questions, the prototype method may be ineffective. Let us assume that the design question is "Can the selected database framework support the required transaction volume ?" You do not need to write any product code for this issue, and you do not need to understand the database details. You only need to know the minimum information that can estimate the scope of the problem-how many tables are there, how many records are there in the table, and so on. Next, you can use the names Table1, Table2, column1, and column2 to write the simplest prototype code, enter some data in the table at will, and then perform the performance test you need.

? The prototype also fails when the design issues are not special enough. Such as "can such a database framework work ?" The design question does not provide much guidance for the suggested prototype. For example, "Can this database framework support 1000 transactions per second on the premise of X, Y, and Z ?" Such problems can provide a more solid foundation for prototyping.

? The last possible risk to the prototype is that developers do not regard the prototype code as a code that can be discarded. I found that if a developer believes that a piece of code will be used in the final product, it is impossible for the developer to write a minimum amount of code. In this case, we are actually implementing the entire system, rather than developing a prototype. On the contrary, if you have established such a concept, that is, once you have answered the question, this code can be thrown away, and you can minimize the above risks. One way to avoid this problem is to use different technologies of product code to develop prototypes. You can use python to design a prototype for Java, or use office PPT to simulate the user interface. If you must use the same technology to develop a prototype, you can add a prototype prefix before the class or package name in the prototype. This should at least ensure that programmers can think twice before trying to expand the prototype code.

? Once applied in accordance with the above principles, the prototype will become a powerful tool used by the designer to warehouse the sinister design problems. If the above principles are not followed, the prototype will pose a lot of risks to the design.

5. Cooperative Design

? In the design process, the three stinks are topped by a Zhuge Liang, regardless of whether the organization is formal or not. Cooperation can be expanded in any of the following ways.

• You walked to a colleague's desk and asked him for some ideas.

• You and your colleagues sat in the meeting room and drew an optional design scheme on the whiteboard.

• You and your colleagues sit in front of the keyboard and use your programming language for detailed design. In other words, you can adopt Pair programming.

• You have a meeting with one or more colleagues to share your design ideas with them.

• You are not able to check your work, so when you finish some initial work, put them all in the drawer and come back for a week. At this time, you will forget everything you forget, and you can perform a good check for yourself.

• Ask someone outside the company for help: Ask for help in a specific forum or newsgroup.

6. How much design is required?

? Sometimes, only a minimum outline of the system architecture is developed before coding. in other cases, the development team will make the design very detailed, namely coding becomes a kind of almost mechanical work.

? If the problem at the design level is left to individual programmers to solve, then when the design level falls to the level of a task you have completed, or when you simply modify or expand a task like this, you are likely to stop designing and start coding immediately.

? If I still cannot determine the depth of the design before coding, I would rather do a more detailed design.The biggest design mistake is that I mistakenly believe that I have done a lot of work, but I still find that I have not done enough, and I have not found some other design challenges.. In other words, the biggest design problem is usually not from areas where I think it is very difficult and that do not have a bad design, but from those that I think are very simple, without any design. I have almost never encountered a project that is damaged by too many designs.

? On the other hand, I occasionally see some projects that fail because they are too focused on documenting the design. The Gresham rule says, "programmatic activities are easy to drive out non-procedural activities ". The premature de-polishing design scheme is an example described by this law.I would rather see 80% of the design effort for creating and exploring a large number of alternative designs, and 20% of the energy for creating less sophisticated documents, I don't want to see that 20% of the energy is spent on creating mediocre design solutions, and 80% of the energy is used to polish and Polish no two designs..

7. Record your design results

? The traditional method of recording design results is to write it into formal design documents. However, you can use many methods to record this result, these methods work well for small, informal projects or projects that only require lightweight recording of design results.

• Insert the design document into the code

  Specify Key design decisions in code comments, which are usually placed at the beginning of a file or class. If your colleague uses a problem Extraction Tool similar to javadoc, this method ensures that the design document is optional for programmers who develop this part of the code, it also helps programmers maintain a good synchronization between code and design documents.

• Use wiki to record design discussions and decisions

  Write our design discussion to the project wiki. Although text input is a little complicated, it will automatically record your design discussions and design decisions. If you use wiki, you can use images to make up for text discussions and connect websites, white papers, and other materials that support the design decisions. If your development team is geographically distributed, this technology will be very helpful.

• Write a summary email

  After talking about the design, please take this approach, that is, assign someone to write the outline just discussed-especially those decided-and then send it to the entire project team. Keep a backup in the Project Group's public email folder.

• Use a digital camera

  You can take photos of the charts drawn on the whiteboard and embed them into the traditional documents. This can produce twice the result with half the effort, because it only requires you to use a drawing tool to design 1% of the charts, the benefit is that it can save 80% of the design chart.

• Retain design wall chart

• Use CRC (class, responsibility, partner) cards

• Create a UML diagram at the appropriate detail Layer

  A popular design drawing method is the Unified Modeling Language (UML) defined by the object management organization ). UML provides a rich set of formal representations for designing entities and their relationships. You can use informal UML diagrams to discuss and discover design details. Because UML is standardized, we can understand it when talking about design concepts. At the same time, it can speed up the team to discuss various design solutions.

8. Evaluation of popular design methods

? How can you determine how many designs are required? This is a subjective judgment, and no one can answer it perfectly. However, when you do not have enough confidence to determine the optimal design volume, remember that there are two possible situations: All design details and no design. These two practices advocated by the extremism at both ends of their positions prove that the only two are always wrong practices.

? As P. J. plauger said, "The more you use a design method, the less practical problems you can solve ". Consider design as a sinister, messy, and heuristic process. Instead of looking for cooperation, exploring conciseness, making prototypes, iterations, and further iterations as needed, you should stay at the first solution you have come up. You will be satisfied with your design results.

05 design practices