Efficient iOS Programming - Keep doing good things and turn them into habits

[[146148]]

Habits affect the way a person does things, and also directly affect efficiency. I often review myself after completing a project, what I did well and what I did poorly? Then I record some good processes and apply them back to programming. Those processes that I can stick to become my programming habits, and these good habits make me highly efficient in programming!

1. Light documents first

What is a light document? In fact, a light document does not require standard software engineering knowledge to write documents such as requirements analysis, architecture design, module design, flowcharts and timing diagrams. Instead, it uses a more free approach to clearly describe what you are going to do and the steps to do it. Such documents do not need to be restricted in format, and you can even write them by hand in your own notebook. As long as you can understand them, you can refer to them at any time during the development process.

1. Why write documentation?

When I first started working, I always started writing code as soon as I received a task. As a result, I encountered many problems, such as:

①. The requirement itself has problems, and it is discovered halfway through writing the code

②. Some requirements are not clearly expressed, and communication is only started when they are discovered. As a result, it is found that there is not enough time, or there is a conflict with the previous code.

③. When I was halfway through writing the code, I found that my thinking was wrong or unclear

***It is very likely to cause project delays.

If the requirements are broken down before development, the issues are communicated clearly, and the points to be done are listed one by one, these problems can be greatly avoided.

2. What to write in the document

①. Preparation

What do you need to prepare before you start? For example, to make an interface for sending messages, you need the following preparations:

a. Interface protocol

b. Test environment

c. Test account

Doing the preparation work in advance often speeds up efficiency. The reason why we need to record these contents is to enable quick retrieval during the development process. If we wait until the development starts to check the chat records or ask the relevant personnel, it will be too slow.

②. List the small functional points that need to be done

For example, when making an interface for sending messages, there are many small functional points:

a. Send interface

b. Data transmission interface

c. Word limit for text

If you think about it carefully, you may also have the following questions:

a. Do you need to log in? If not logged in, do you want to be prompted to log in?

b. What to do if the sending fails?

c. How to interact when the word count exceeds the limit?

d. If a user repeatedly sends the same text, should it be filtered?

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

After you have recorded these small functions and communicated them clearly with the product manager, you can make a preliminary assessment of your development cycle. At this time, you have also figured out how many small functions this requirement has, how to divide the modules, and how to build the internal processes.

For some functions with complex processes, you can draw a flowchart to assist understanding

③. Record the changes to this requirement

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

If this requirement will affect the previous code, you need to record the changes, because many bugs in the project are caused by changes. Listing the changes will make you more aware of the impact of the new function and reduce many low-level bugs.

For example, if a new function of sending pictures is added, this function will affect the display of the chat window and the keyboard, and these changes should be recorded. Firstly, it can help to think about whether there are any small functional points that have been missed, and secondly, it is necessary to cover the display of the chat window and the switching of the keyboard during self-testing.

④. List the self-test contents

After the coding is completed, you must conduct self-testing. The more careful the self-testing is, the more likely you are to find and fix bugs in advance. If the tester finds the bug and then submits it to you, your efficiency will often be low if you try to solve it at this time.

Taking sending messages as an example, there are also many self-test contents:

a. Send message normally

b. Click Send when not logged in

c. The word count exceeds the limit

d. Send when there is no network

e. Keep sending when the network is very poor

etc.......

2. Start coding

1. Rewrite or keep it the same?

Every time you make a new requirement, you may face such problems:

①. The previous module was so poorly written that I really want to rewrite it

②. I have similar requirements and used this method to achieve it before. This time I want to use another method to achieve it.

Considering the above questions proves that you are a person who wants to make continuous progress. However, before making a decision, it is best to consider the following factors:

①. Rewriting a module may affect the entire system. You need to think clearly about the possible impact of the change and the time required to solve these problems.

②. Use a new solution to meet the requirements. Has the new solution been carefully verified? If not, it may bring new problems

There are some advantages to staying the same:

①. You can do it faster than before because you are familiar with it

②. No new problems will arise

After considering it, I have basically figured out whether to rewrite or keep the status quo.

However, maintaining the status quo does not mean giving up your pursuit. You can use your spare time to prove your plan. When it is stable and feasible, you can rewrite it at any time.

2. Realize the needs, demo first

Using Demo to implement a requirement is the fastest, because it runs fast, can be modified at will, and has a small amount of code. If there is a problem in the implementation process, it is easy to locate the cause.

First create a Demo, then transplant the required resources, and after the functions are implemented, transplant them into the project, which can save a lot of development time

3. Use tools

①. Code Template (File Template)

When we create a view, a controller, or a model, there may be some fixed functions and properties that need to be defined or overridden. Using Xcode, we can create code templates and generate these codes with one click when creating class files to improve efficiency.

②. Code Snippet

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

a. Declare a property

b. Create a thread

For code like this, I will make it into a code snippet, and then use Xcode's Code Snippet auto-complete feature to quickly complete it. An example of a code snippet:

Write the picture description here

Just enter @OperateThread to directly complete the code for creating an operation queue, greatly reducing coding time.

③. Automatic annotation tool (VVDocumenter)

A tool that can create note templates in one click, reducing the time required to write notes

4. Add appropriate comments

If comments are added everywhere like the official API, the workload will be too heavy and require extra development time. If comments are only added to some semantically unclear or ambiguous codes, it will reduce development time.

For example, a property:

@property (nonatomic, assign) int64_t createTime;

At first glance, it is clear that it refers to the creation time, but is it a timestamp? If it is a timestamp, is the unit second or millisecond? If you have to print the data before you can draw a conclusion, it will be too time-consuming.

After adding the annotation, it becomes clear at a glance

/// Creation time (timestamp seconds)

@property (nonatomic, assign) int64_t createTime;

3. Self-test

1. Check first and then self-test

After completing a small function, check the code first, and then start self-testing, because the code can tell you a lot of information:

①. Are there any low-level errors?

②. Are there any vulnerabilities that are difficult to find?

③. Is there a problem with the process?

If you test yourself right after you finish coding, you may enter a passive state:

①. This interface is not displayed correctly

②. This data does not match expectations

③. Something appeared that shouldn’t have appeared

At this time, debugging the code and modifying it step by step will be very slow, because it takes time to compile and operate, and some conditions are not easy to simulate, which will take even more time.

2. Go through all the self-test points

You may find this annoying and a waste of programmer’s time, but bugs found during the self-testing process are the easiest to fix, because the code is most clearly remembered and the problem is easiest to find.

IV. Conclusion

I first use documents to clarify my thoughts, then start coding, and after coding is completed, I check the code and test it myself. This is my programming habit, and I still use it today.

In fact, knowing a trick does not improve efficiency. Only when you persist in using this trick and form a habit can you truly improve your efficiency.