Hi guys, I’m an iOS developer. Have a little development experience summed up, share out. Developers can’t control the PRD, which is the right program, they can only do their best to make it work correctly. Getting the program right is more important than getting the program running right, but we can only do our job… And then expect the program to be correct

First, modular development, the sparrow is small

1, how to calculate a module? According to the function division, the internal has a certain logic, the external has clear input and output

By function, for example: the item list in the item details page can be considered as a module. 1. It has a separate interface to facilitate Mock data, low coupling, and easy reuse. 2

2. How to start? Start with the Mock entry and the data

Mock entries and data can be tested quickly and save a lot of time

Some pages are deep, two, three, four levels are possible. If the run starts from the home page, channel page or search, details, fill in the form…… Think of countless times to repeat this process, the middle may encounter interface impassability is slow, service instability and other problems. Mock entries and data greatly improve development and debugging efficiency

3. Development sequence? Start from main body demand according to demand

Make the main stem before you fill in the leaves

There are many points of demand, find out the backbone to build the framework, and then continue to test, debug, improve the different branch conditions of the process according to the demand, simulate the corresponding data. More than one test entry can be added if necessary. The conditional branch can also be switched dynamically during the test run. More convenient implementation with LLDB, conditional breakpoints, Charles’s Map Local functionality, and more

4. End? Connect to the online interface and test the network failure

Mock data is convenient to test various situations, but the real world is too complex. There are all kinds of exceptions, network exceptions, interface data exceptions, memory warnings, circular references, machine adaptation, system version adaptation, rolling lag, and so on. Careful testing catches problems early.

Second, read the product requirements document carefully and try to make the program more flexible

I am more and more aware of the importance of reading comprehension. The same document some people will miss some requirements, until serious testing classmates put forward a bug, look back to see suddenly understand. Serious students often find some points that can be optimized or have problems, and actively communicate

Take all of these things, list them all, and then think, what are the clients? Which are provided by the interface? As far as possible, some control process variables, switches and so on in the interface. After the modification, you can use the interface to be compatible with the original version.

For example: the document says that the item is larger than 3 and shows more buttons. So this 3 should be on the server. For example, only the first three payment methods are displayed in document writing, and the later payment methods are collected and displayed more. In this case, you can put 3 in the interface, or you can add show and hide fields on the payment method. The specific way can be discussed with the students of products and interfaces.

{"alipay":"..."} {"alipay":"..." , "show": true }, { "bankpay":"..." , "show": false } }Copy the code

The purer the View and Model need to know, the better

If you have a Label on the left and a Label on the right, then the View just needs a Model like this

class Model
    NSAttributedString *left
    NSAttributedString *right
end
Copy the code

Do not write specific Value content such as Title and Price

conclusion

In the future, any View that has a Label on the left or right can use this View with Model 2 and NSAttributedString to make the line between View and Model less clear. Some of the styles displayed can be written in the Model. 3. Using RAC (note the circular reference problem) makes it easier to trigger changes in the state of the View and make it easier for the View to change through RAC to the Model

4. Data modification

In many cases, the data structure given by the interface is not suitable for direct use. Construct data methods can be added to modify the data. Such as adding attributes to record state, reassembling according to requirements, etc

Model can be a little bit more

For example, if you have a title field, you need to set font size color when you display it. It’s better to make it a property string than to put a font, size, color on the view. I think it makes sense to write it in Model

Define some error-proof parsing. For example, if some orders are written dead, you can add a field resolution. In case a change is needed

Five, error? Don’t panic, don’t ask, don’t blindly try

Read the error carefully. Analyze carefully. Good design provides detailed information when reporting errors. If you look closely at the Xcode console log, you’ll see that it’s very clear what’s wrong and if you don’t, you’ll comment out the code. Using the Git repository to roll back code is always a good idea

Six, according to the normal norms

Write code in rewrites to avoid weird problems.

For example, 1, do not modify the frame of the cell, do not make sure that this is true. 2, the cell should write the reuse ID according to the rules. Do not return the retain cell directly. What do you notice is missing when you say you got a memory warning? ! 3, To be continued…

The nuggets essay | 2020 years and I summarize the campaign is under way…