background
With the continuous development of business and the adjustment of organizational structure, App decoupling needs become more and more urgent for teams with vertical business division.
For example 🌰 : after vertical business division, one team is responsible for “home page” + “search” + “product details”; Another team took care of “mine”;
The two teams are respectively responsible for different codes. There is no overlapping code, and the end developers will take their seats accordingly. In principle, there will be no overlapping resources.
The difference between this and the previous common development method is that the students before the end of development is equivalent to a pool, there is a need to come over, this version of what needs to do, we broke up the average evenly distributed to all students, according to the plan for development.
Now there are two pools, and the two pools are not connected to each other, and each pool has a fixed part of the code to correspond to, so there is no need to cross the pool. In terms of code, the code of an App can be split into two parts. Students in the two pools develop their own codes and merge them in the final version.
The separation
Why split the code into two parts? The reason is that iOS is being developed at the same time by new and old students in a team of about 10 people. The number of redundant codes and iterations of business codes and technical codes only increases and does not decrease. Gradually, it will be found that the code dependence of the whole project is extremely complex and the compilation speed is extremely slow.
How slow? It’s frustrating. The code you’ve already conceived in your head gets overwhelmed by frustration, and you have to do something else while you’re compiling and building it, and then when you finally get to the point where you can verify it, you realize that the whole idea has gone wrong.
So there is a cost to separating the code, but it feels worth it to expect to see less frustration.
Multiple shared code
If only one App is maintained by two development teams, separating the operation into two parts is the most cost-effective approach.
However, if functional modules in one App need to be reused in another App, such as product details, there may be teams that maintain both apps, which may need to share this part of the code.
At this point, it is very necessary to separate part of the code that was originally split into two parts again so that the code can be reused and decoupled enough.
methods
There are many ways to decouple code. The most direct way is to use Cocoapods to decouple code. However, there is a pit, which I’ll explain in more detail later, that makes it less meaningful and valuable, and how to avoid and improve it.
At the same time, it will also introduce what methods can be optimized and improved to achieve the ideal solution.
One of the best practices and containerization solutions for iOS development