The development of IOS large-scale project

Crespoxiao authorized this site reproduced.

The headline's scary. Please don't be afraid, but this is really not a literacy sticker and requires a certain foundation for iOS development. In my years of farming career most of the time is to do a small project, the larger may be the millions of lines of code, and windows tens of millions of lines of the source of the system is nothing. However, an iOS project with millions of lines of source code is pretty big. I want to say that people will always grow up, will take greater responsibility to accept the greater challenge, one day the organization will have important tasks to you. However, software development is not overnight, nor how vigorous, more is insipid in the countless details of processing. Doing large-scale projects does not necessarily require how advanced technology, perhaps the details of the scientific treatment and normative management.

First of all, what is the choice of programming language, objecive-c or Swift? I haven't used Swift in my project yet, because I can't convince myself to use it, where its advantages are, and you can't force teammates to learn swift. Of course, no, no, no, no, a person who develops meaningless products with Swift does not qualify to wear tinted glasses to despise the swift peers. Do you know how many pits there are in objecive-c and Swift? Did you know that Swift also shared a runtime environment with OBJECIVE-C? Do you know that using Swift will make the IPA package larger than 10 m? Swift stands for the future, and Objecive-c is now. Swift can do the objective-c can do, such as closure fully usable blocks to replace, the tuple can be completely replaced by the structure. Production environment with OBJECTIVE-C, amateur watching Swift, this is my attitude. Raywenderlich has a lot of swift tutorials, in the use of cutting-edge technology in the domestic always slow a beat, to a large extent, the wall hinders the development of domestic it practitioners, wall developers (including my Information Security engineering teacher) will one day be judged by history.

Again, the application architecture, it is also MVC, failure is also MVC. If the children of the team are allowed to develop according to the MVC they understand, the common consequence is the high coupling between classes, the controller is too fat to be toolbox ... Every version of the iteration will be painful, if the function is not much can barely maintain the function is bound to collapse, such as the Expo Garden China Pavilion Bar, and then the proportion of more than 5 layers to try, hehe. In the end developers really can not stand the choice of refactoring or run, the latter is more realistic we all understand, especially business for the king of the Enterprise, code quality is a fart as long as work, but good programmers are dignified, deadline or shoot the head of the political task will usually let the programmer tired to cope with, It's time to get tired of it. Anyway, since MVC looks bloated, it's a thin body. Usually the thin-behind MVC is called Mvcs or MVVM in the iOS world, and these 2 are certainly not the same thing, whether the project chooses Mvcs or MVVM still depends on your business features. is Mvcs and MVVM that perfect? Of course, Mvcs should pay attention to the abuse of Service/store, whether the data will be contaminated by different modules. MVVM is not good enough to increase the difficulty of maintenance of the project, I said the view and viewmodel between the loose binding relationship, in the development of iOS mentioned MVVM people think of Reactivecocoa, in fact, there is no reactivecocoa can ah, Just a lot of reactivecocoa benefits, such as code convergence does not have to write everywhere, other benefits to dig it yourself.

About the structure of the project document, many people are controllers/views/models/vender ... This classification, in fact, there is a problem, such as you want to find Controllera TableView use of CELLB class, you also want to go to the views inside one after another, too painful, even if search is still bitter after all can not see is the income. I usually divide by module, each module contains CONTROLLERS/VIEWS/MODELS/STORES/API such classification, API is the request of each interface package, for store call, The data is parsed into the model and passed to the controller by block to refresh the view, is it very round? The racsignal created in the Rac,controller subscription store can do the same, U can make a try. There are helper and utility, business-agnostic, object-capable code that provides support for the helper, such as creating a custom object encapsulation. If it's just a function or algorithm, not an object and can be used in many places, put it in utility, such as a sort/encrypt algorithm.

Project Document organization structure

On the design of the network communication module, I personally think that each HTTP request should be independent of each other, that is, your encapsulated Post/get method creates a temporary object, and long connections generally only maintain one instance object in a singleton way. I will create an API object for each HTTP interface request, in which the data is requested, of course, in order to avoid the repeated writing of the request code can establish a base API class, the subclass calls the parent class request method is OK, the difference is just the interface and parameters. This is the idea, and later there is time to talk about the design of the API class.

With regard to multithreading, the most used in iOS development is GCD and nsoperation, and in most cases gcd is enough. But Nsoperation also has its advantages, such as can set the number of concurrent, you can set dependencies between threads, can pause and resume, more flexible, multi-threaded download often use it. Interview also often ask GCD and nsoperation difference, this oneself to check, the data is relatively rich, there is also a reference link to nsoperation. GCD although strong, but still have a lot of people blind use, really for their worry, casually say a few points:

1. Misuse of Dispatch_after to do timer causes crash! I don't know if there's another thing called Dispatch_source_set_timer?

Countdown

2. Do not use Dispatch_sync easily, thread synchronization method So many why you have to love it should not love it! Especially do not in dispatch_async inside with Dispatch_sync, do not ask why, Baidu inside Google a bit!

3.dispatch_once also create a singleton when used, do not use blind. Dispatch_once is performed only once during the entire app life cycle, not only once in the object life cycle, brother!

4. What! You don't know. Create a serial thread with GCD with parallel threads!

Serial

Parallel

With regard to multi-team collaboration, Cocoapods is undoubtedly a very good tool if the project is developed in a sub-modular way. The relatively independent module as far as possible to play a private pod, so that the public platform to the entire project framework, the other business units only need to build a private pod, the use of public platform to play with those private pods to develop debugging independently, and do not have to submit code to the main project, so it will be very troublesome, For example, code merge conflict, certificate conflict, will be crazy. When the module development is completed and then submitted to the main project is good. Of course the private pod is a lot of trouble, private pod relies on more private pods when adding files to target will be very painful, xcode default is target all selected, want to feedback with Apple hope they will solve.

On data persistence, the most important thing is to keep the data source consistent. Another important thing is the app after the upgrade of the forward compatibility, the kind of your upgrade app startup crash problem, most of the new version of the data structure changes, does not support the old version of the data or settings generated. I have always preferred SQLite, the most used is Fmdb, no love for CoreData. To know Apple's own app news is Fmdb Ah, I remember someone asked the Facebook engineer "Why your app is slow", "because we use core data!". There is an open source library Magicrecord, the depth of the CoreData package, I have used, in fact, is also good.

Also, is unit testing really necessary? Unit tests can make logic clearer, and when you just read the unit test code, you'll find that they're written as if they were pseudo-code in a programming textbook. This is especially useful when TDD. By writing unit tests, you can quickly sort out the logic and then implement it in code. Unit tests can reduce the coupling of the code. We know that high-coupling code is hard to do unit testing, and conversely, if you have to do unit testing, you're not going to write code with high coupling. Unit tests let you know if your changes to the code affect the original functionality, but this is what all regression tests can do. Unit testing is characterized by the fact that it tests things small enough to be reused after code refactoring. Unit testing is the only test that can reach 100% coverage. Unit testing begins to be difficult, and it is easier to keep doing it, because the difficulty is mainly due to the construction of the environment and the absence of the pile function. Unit tests can easily locate bugs, which seem to hit countless breakpoints in your program. Unit tests are time-consuming, but they are more time-consuming to fix bugs.

Talk so much, and finally talk about the need. I think in the needs of the review should try to throw out the details of the PM, they do not know the technology, if the demand is not sure blindly develop, and then change the demand halfway, which is very hurt morale, especially when it comes to the modification of the structure, which reminds me of the PM to change the needs of the programmer to block the diagram, Hey! Demand is not stable, do not work, rather soy sauce Read blog. Well, long winded, how many people will see here? I hope I can come back later to add some content.

The development of IOS large-scale project