Before the development of the proposal to write a document, um, good idea

First, light document advance

What is a light document? In fact, light document refers to the need to follow the standard software engineering knowledge to write requirements analysis, architecture design, module design, flowchart diagram and other documents, but the use of a more liberal way, the things you want to do, and the steps to do things to describe clear documents. This kind of document does not need to restrict the format, even you can hand-written in your own notebook, as long as you can understand, in the development process can be consulted at any time.

1. Why write a document

When I first started working, I always started to write code as soon as I got the task, so I encountered many problems, such as:

①. There is a problem with the demand itself, and the code is written half to discover

②. Some of the requirements are not expressed clearly, when found to communicate, the results found that time is not enough, or with the previous code to create a conflict

③. When the code is written in half, it finds itself wrong or unclear.

Finally, the project may be postponed.

If the requirements are broken down before development, the problem is communicated clearly, and the points to be done are listed, which can greatly avoid these problems.

2. What to write in the document

①. Preparatory work

What do you need to prepare before you start? For example, to send a message to the interface, you need to have the following preparation:

A. Interface protocol

B. Test environment

C. Test Account

Preparation works well in advance, often speeding up efficiency. Why is this content recorded so that it can be retrieved quickly during the development process? If you wait until the start of development to check the chat record, or to ask the relevant personnel, it is slow.

②. List of small function points to be done

For example, to send a message to the interface, there are many small function points:

A. Send interface

B. The data interface sent

C. Text Word limit

If you think about it, the following issues may also occur:

A. Do I need to sign in? If you are not logged in, do you want to boot

B. How do I handle a failed send?

C. How do I interact when the number of words exceeds the limit?

D. The user repeats the same text, do you want to filter?

E. How to handle the error code of the data interface?

When you record these small functions and communicate clearly with the product manager, your development cycle is ready for initial evaluation, and this time you have figured out how many small functions the requirement has, how to divide the modules, and how to build internal processes.

For some of the complex functions of the process, you can draw a flowchart to help understand

③. Record the change point of this requirement

If this is a new requirement and has nothing to do with the previous version, you can ignore this part

If this requirement will affect the previous code, you will need to record the changes, because there are a lot of bugs in the project is changed, the list of changes will make yourself clearer about the impact of new features, reduce a lot of low-level bugs

For example, add a feature to send pictures, this function will affect the display of the Chat window, will affect the keyboard, these change points to be recorded. As a result, you can help to think about the small function points that have been missed, and the need to overwrite the display of the Chat window and the keyboard switch when self-testing.

④. List self-test content

After the code is complete, be sure to self-test, the more careful from the test, the more you can detect the bug and repair. If the tester has found a bug and then submitted it to you, you will be more efficient at this time.

As an example of sending a message, there are many self-test content:

A. Send messages normally

B. Click send when not logged in

C. The number of words exceeds the limit

D. No network point-in-time delivery

E. When the network is poor, keep sending it.

Wait a minute.......

Second, start coding

1. Whether to rewrite or stay the same

Every new requirement is likely to be confronted with a problem like this:

①. The previous module was too lame to write again.

②. Similar needs, previously implemented in such a way, this time want to change a way to achieve

Consider the above questions and prove that you are a person who wants to keep improving, but consider the following factors before making a decision:

①. Rewrite the module, it is likely to be reaching, to understand the possible impact of the change, and the time required to resolve these issues

②. Using the new scenario to implement the requirements, whether the new scenario has been carefully validated, and if not, it may introduce new problems

In fact, there are some advantages to remain the same:

①. Can do faster than before, because you are familiar with

②. No new problems arise

After consideration, it is to rewrite or maintain the status quo, the basic already has the answer

But keeping the status quo doesn't mean giving up on the quest, you can use your spare time to prove your plan, and when it's stabilized and workable, you can always rewrite it.

2. Realize the demand, Demo first

Using Demo to achieve a demand is the fastest, because it runs fast, can be arbitrarily modified, and the code is small, if the implementation process problems, it is easy to locate the cause.

First set up a Demo, and then the need to transplant the resources, the implementation of the function, and then transplanted into the project, which can save a lot of development time

3. With tools

①. Code templates (File template)

We create a view, a controller, or a Model, there may be some fixed functions, properties need to be defined or rewritten, using Xcode to create code templates, when creating the class file, a key to generate the code, improve efficiency.

②. Snippet (Code Snippet)

Generally reusable code, we encapsulate it into classes or functions for use elsewhere, but some code is not suitable for encapsulation, for example:

A. Declaring a property

B. Creating a thread

Like this kind of code, I'm going to make code snippets, and then use Xcode's code Snippet Auto-Refill feature to do it quickly, a snippet example:

Write a picture description here

Simply enter the @OperateThread to complete the code to create an operation queue, significantly reducing the encoding time.

③. Automatic annotation tool (Vvdocumenter)

A tool that can create a comment template with one click, reducing the time required to write comments

4. Add comments as appropriate

If you add comments to all places, like the official API, it's too much work, requires additional development time, and if you just add comments to some semantically ambiguous code, it will reduce development time.

For example, a property:

@property (nonatomic, assign) int64_t createtime;

You know when you see the creation time, but is it really a timestamp? If it is a timestamp, is the unit seconds or milliseconds? If you want to print the data, you will be too time-consuming to draw conclusions.

When you add a note, it's a glance.

Creation time (timestamp seconds)

@property (nonatomic, assign) int64_t createtime;

Third, self-test

1. Check the post test first

After you complete a small function, check the code before starting the self-test, because the code can tell you a lot of information:

①. Are there any low-level errors

②. Are there any vulnerabilities that are hard to spot

③. Is there a problem with the process

If you do a self-test immediately after the code is complete, you may get into a passive state:

①. This interface shows no

②. This data is not in the expectation.

③. Something that shouldn't have come up.

This time again to debug the code, step by step change, will be very slow, because you compile and operation will take time, and some conditions are not easy to simulate, the situation is much longer

2. Self-test point to go through all over again

You may find this annoying and wasteful of the programmer's time, but the self-test process finds that bugs are the easiest to fix because the code remembers the clearest and easiest to find the problem.

Iv. Summary

First use the document to clarify the idea, and then start coding, the code after the completion of the check and self-test. This is my programming habits, has been used so far.

Actually know a skill, will not improve efficiency, only adhere to the use of this technique, and form a habit, will really improve efficiency.

Before the development of the proposal to write a document, um, good idea