Before you code

Many developers define themselves as programmers and feel that they are specialized in code writing. They are not interested in code that is a little farther away.

In the previous article "The Future of Software Development", I have explained the technical timeliness and fast update.

If we keep our eyes on code rather than the comprehensive ability to analyze and solve problems, we will sooner or later fall into the middle-age crisis and be eliminated by the surging technology trend.

In this article, I want to talk about the basic routine for analyzing and solving problems. This is a habit I have summarized over the years and hope to help you.

　　Definitely not writing code right away

Some people love code and immediately think of code implementation after receiving a task.

The problem has not been clarified, and the working principle has not been thoroughly analyzed, so I began to organize several classes and then think about how to use these classes.

Look for someone to discuss and view the Code directly.

This is the rhythm of preparing to die 1000 times.

　　Pen: design document

Some new people have a sense of responsibility and will contact me to discuss problems. However, it is impossible to go deeper, implement the effects of all kinds of rework and improvement, consider the disadvantages of weeks, not productization, and make a lot of detours.

The problem is that you are not good at writing. Purpose:

1. Outcome:

   Every thought, every discussion, and one step of understanding are fixed. Step 1, step by step to achieve the goal.

   If you do not record it, you will be anxious, and you will think twice at a low level.

   Most people have limited brain memory, and they must exchange files for smooth operation.

2. The document is an alpha-version program.

   The brain is the computer that runs the document.

   Read the document once so that the entire system can run it in the brain before running it.

   You can run the command once to check whether an exception is thrown. These exceptions are corrected in the document. Run the command again to find the exception.

   It is not only running in your own brain, but also running in others' brains through design reviews. If there are multiple solutions, you need to evaluate the best one.

   It is impossible to make a good design at a time. Only repeated operations and multiple operations can minimize the possibility of an error.

   Therefore, it is critical to clarify whether the document is simple.

I recommend that you use slide for the design document because a page describes a problem. Large title configuration section, more concise.

The following sections are the main content of this slide document.

Of course, if you don't have a problem, you may not write design documents if you have confidence in your brain memory and expression capabilities. The risk is borne by myself. In fact, designing documents is not time-consuming.

　　Problem presentation

A problem is also a requirement.

The problem should not be too technical. It is more stated from the user's perspective.

The problem should be identified by common users.

You need to describe various scenarios. Do not miss the scenario, otherwise there will be deviations from our subsequent designs.

After the final design is complete, we need to verify that these problems and requirements have been met.

These requirements and problems also need to be prioritized. Because we finally need to develop a plan throughout the design process, and we need to be able to submit a minimum workable version as soon as possible. In this way, agility can be achieved.

It is necessary to clarify the scope of the system.

For a multi-user system, you need to list the involved user roles and the desired functions of each user.

　　Working principle diagram

A picture is worth a thousand words. Especially for design documents used for communication, the fewer words, the better. The most expressive content in a graph.

Working principle diagram is a statement of a solution. You can have one or more. This is the center of the entire design.

Working principle diagram, usually including the Direct Interaction Relationship between the system and the external, and the internal structure of the system.

These two graphs are composed of a box and a line. A box represents a module and a line represents an interface. The names of each interface and module and the main sequence of interface calls must be marked.

Drawing a schematic diagram is not just a painting, but a real design. There is a lot of speculation in it, and we need to clarify various concepts.

Module and interface naming is a reflection of speculation. Invalid name.

It is necessary to describe the modules and interfaces around this schematic diagram, which constitutes the so-called design body.

　　User UI design

If you need to participate, you need to design the user UI. Of course, if it is a backend application, you need to define the interface.

The user UI often needs to be clear early, because the user UI can be refined, and the outline design also echoes and confirms each other.

The reason why user UI design is important is that it is more important to think about problems from the user's perspective. Therefore, it is better to fully express the system, clarify the correct direction, and facilitate thinking into depth.

Of course, how to design it will also consider the previously convenient implementation. This is the art of the two.

　　Development Plan

That is, todo.

A design is a process in which demand and ideas are constantly expanding. Simple things are often complicated.

How to Develop a plan. At this time, the main point of thinking is that the ideal is great, but how can we quickly make a workable minimum version.

This is also true of bold assumptions. In fact, many of the content we designed may be wrong.

The design is permanent and will not end with a design document, nor will it end with a review or several revisions. The design is truly in-depth in the development process. At this time, we will constantly find problems with the previous design.

Make a minimal workable version. At this time, evaluate the design and find many problems.

Therefore, the design should be done as early as possible, because every review, we basically have new ideas. The earliest design, the latest hands-on, is a reliable method. It leaves us more time to digest and improve our design.

　　Add content based on questions

After preliminary design is completed, various problems and omissions will be discovered.

Record the problem accurately, and then think about the solution.

In fact, if we can accurately express the problem, the solution is always coming.

　　Update Reference Document

In fact, the long-term retention value of design documents is not great because:

• The document is too simple, and subsequent product documents should contain the content of the design document.
• The document is easily outdated. After the code is officially started, the design is still changing. At this time, the design document is usually not updated.

Therefore, the design documents are usually headers and tails.

Once the design is determined, the designer must first update the reference document and maintain this document for a long time.

The reference document is a reference manual, including the API manual, system maintenance manual, and so on.

These documents are provided to other users and must be kept permanently.

Many people always feel that they do not have time to maintain these documents. It is important to maintain this document during the design phase.

This document is actually a detailed design document. Before coding, we can further design the system from the user's perspective and find out the design problems again.

If you think the API is strange or the operation manual is difficult to write, there may be problems with the design.

　　Section

It's not a hassle to analyze and solve problems.

However, these are things that can be used in all aspects of life and work. They belong to the "Tao" level, if encoding is "skill.

We all want to be a reliable person. Even in areas you are not familiar with, we can use resources to do one thing well. The above analysis method may be worth learning.