Scaling iOS apps: How did Rambler do it?

    Today our interlocutor is Yegor Tolstoy , the head of the iOS development department at Rambler & Co, the organizer and permanent speaker of the almost-once-two-month meeting Rambler.iOS. In addition to working on applications such as Rambler. Mail, Rambler. News and LiveJournal, he devotes a lot of time to open source projects, in particular Typhoon - for about a year he has been an active member of the community and one of the main contributors. In general, we again have something to talk about. - Good afternoon. Tell us briefly about yourself.





    - Hi. My name is Egor, recently I became the head of the iOS department at Rambler & Co. Graduate of the Faculty of Radio Electronics of the Moscow Aviation Institute. While still in his third year, he took up mobile development, so after graduating from the university he decided not to go on the path of information protection and continued to develop for iOS.

    He joined Rambler & Co two years ago, before that he worked in a small outsourcing company. In addition to the main work, I devote a lot of time to participating in community life - articles, speeches at conferences, open source projects. I organize a once-in-two-month meeting of Rambler.iOS, and I try to constantly speak there myself. By the way, at the end of the post there will be a video of the last time I cried about how difficult it is to do normal pagination in mobile applications. Still having my little blog.

    - You are doing iOS development at Rambler & Co. When you arrived, what were your goals?

    - When I came here two years ago, we had a small department for mobile development, four iOS nicknames and a couple of Android developers. At that time, everyone was sitting together, we had one head of mobile development, and basically all we did was support the legacy code of old mobile applications. They were really old, the code was written in some bearded years and there was a complete horror. A little later, in Rambler, a separate structural unit was formed under the name Rambler Digital Solutions, which included all the techies. It has a matrix structure, that is, everything is divided into several departments. And since then everything has become much better.

    At that moment, my former leader German Saprykin came to us, with whom we once started working on the Rambler project. Mail. It was with him that everything started to get better and we began to establish development processes. A rather vague definition, which includes a bunch of all kinds of different things: development standards, team interaction, code review, continuous integration, continuous delivery, knowledge sharing - and so on. In particular, we introduced the practice of unit testing, and moreover, on some projects we adapted TDD, mainly when developing the service layer. And the department began to grow like an avalanche.

    At that moment, we stopped supporting old projects. All efforts were aimed at writing new products. I was then engaged in Rambler. Mail, the first release was a year ago. It just turned out to be an indicator of how well and quality we began to manage to make mobile applications. It would seem that the mail program, a complex product, a lot of logic, but at the start we had crash-free in the region of 99.9%. This is a very good result.

    Now we are in a state of constant development, we are establishing various work processes, including Continuous Delivery. We are still actively working on the Project Status Dashboard. A large plasma will hang in the department, on which statistics for all projects will be displayed: how many unit-tests, how many crash-free and all that stuff.

    One of the important milestones in the development of the team was the adoption of common architectural standards for all developed applications. Firstly, this is the use of n-tier architecture, most often consisting of two layers: presentation - everything related to the display of specific screens, and business logic - an independent business logic, which includes working with a network, data caching, synchronization mechanisms.

    Digging a little deeper. Instead of the standard MVC at the Presentation level, we use the VIPER architectural approach, which allows us to achieve maximum modularity, testability and reuse of screen components. VIPER, by the way, is generally a topic almost dear to us. During its use, we wrote a bunch of articles and components to work with it. Well and, of course, conferences spammed. As my colleague Sergey Krapivensky aptly remarked, we look like Tender May - we are also speaking on the same topic in different parts of Russia (and, by the way, his speech at CodeFest ). To build a layer of business logic, we use the SOA model, dividing it into independent services that work with one business entity.

    Now we have 25 people in the department. In addition to working projects, we devote a lot of time to various Open source things. For example, we have such a popular code generator that we wrote for ourselves, then we decided to open source and it seems like it entered the people. In addition, we often participate in various conferences. Just a year ago, they began to hold their meetings, and after that they began to invite us to larger conferences (such as, in fact, Mobius ). We continue to recruit new employees, we have new projects and new tasks.

    Well, of course, while working at Rambler & Co, I managed to participate in several interesting projects: Rambler. Mail, Rambler. News and not yet released LiveJournal production. There were, of course, sad moments - for example, the development of a peer-to-peer geolocation chat that never saw the light, which I still remember and cry about - put my whole heart into it.

    - Typhoon Framework. Tell us a little about him? What role do you play in its development?

    - Typhoon is the most popular and frequently used DI container for Objective-C. The first version came out three years ago. It is a cement that ties together all the components of our applications. Typhoon is built into our application and it allows you to take the configuration of all the dependencies, create all the objects, initialize the dependency graph somewhere to a higher level. This allows us to decompose our application modules. All components become as independent as possible, do not know anything about each other and implement the DI principle.

    I joined the Typhoon contributor team last year. It all started when I talked about Typhoon at a local rally, why it is good and why it should be used. After that I wrote a series of articles on Habréwhat Typhoon is and how it works. And at the same time, I myself found some problems in Typhoon, I ruled them myself, sent requests. And then they called me to the main team.

    Among the interesting features that I have implemented, we can single out support for working with several stpryboards, advanced mechanisms for activating the container, and processing the logic for using configs. Now I am finishing a major task - adding special TyphoonStoryboardDefinition, which will allow working with controllers created from storyboard in the same way as with any other objects. For example, it will be possible to manage their life cycle.

    Now we are actively preparing for the release of version 4.0 with support for a new cool syntax and a separate project for working with swift. Typhoon’s syntax is currently very complex and cumbersome, and things should get simpler and more native. The entry threshold will decrease.

    Working with Typhoon gave a strong impetus to my development as a specialist - this is a very large project, which brings together a huge number of interesting and unusual technical solutions. In addition, a team of strong developers is working closely on it - our compatriot Alexei Garbarev, a programmer with n-year-old experience of Jasper Blues and German Saprykin I already mentioned. The guys not only helped me understand the logic of the framework, but also simply connected to various technical and architectural discussions, which in many respects influenced my views on the development.

    I appeal to colleagues from the world of iOS development - devote at least a few hours a week to work on an open source project. This benefits not only the community, but also you. And Typhoon is perfect for the kind of such a project, now we have about 30 Issues open.

    - Tell us about the features of the Typhoon Framework (auto-injection, etc.)

    - Firstly, Typhoon is cool in that the main team that develops it started to make it to fit your needs. Most of the time they are engaged in fairly large projects for various customers. And they understand what they really need, and they initially did the framework for themselves.

    That is why Typhoon in fact is not just a primitive DI container, it allows the user to work with many different chips. For example, these are Typhoon configs. You can enter data into configs, and they can be injected into our objects in the same way as any other dependencies. This may be useful for constructor applications. We have it, for example, Rambler. Cash.

    For example, in regions it is not convenient to use the entire Rambler application. Cashier and they can order a branded application for themselves. We have a common container application, from which we automatically collect branded versions on the fly, changing configs, where color schemes, API data, and stuff like that are declared.

    Typhoon also has a lot of interesting things for organizing testing.

    Actually, the cycle of my articles on Habré about working with Typhoon will best tell me for me - starting from a general acquaintance and ending with just listing its interesting features.

    - Let's talk about scaling iOS-applications for, in fact, Rambler applications. How did you implement this?

    - If we talk about scaling development, then everything is interesting. As I said, we have a team of 25 people. At other companies, programmers are broken down by product team. You come to work, for example, not in the mail.ru, but in the mail.ru search team. You work in a small department and you can never see other iOS nicknames. Maximum total chat. Accordingly, each team has its own technology stack, its own processes, its own development approaches. And team experience circulates only within the framework of this team.

    Everything is different with us. We all sit together and work in the same department and we have a wide rotation between projects. It is clear that the side of the business is, of course, a problem. He has his own team that makes the project, and they understand that changing a developer can lead to mistakes and loss of time. We were faced with the task of using universal tasks and universal approaches so that the transition between projects did not affect anything. A major role in this was played by a unified approach to application architecture. We agreed that the application is divided into several layers and described the general approaches to the architecture of each layer. Due to the fact that all our applications are quite similar, this helps a new person to easily join the process. In addition, we are actively conducting detailed technical documentation of all projects.

    - Why are you using Typhoon, and not “reinventing your bike”?

    - I will have a separate slide on this subject in my presentation . There is a section in which I tell legends and myths about Typhoon. One of the myths is that you can write your own framework. What can I say to that? Typhoon greatly reduces the amount and complexity of the code responsible for creating graphs of objects and passing dependencies when navigating between screens. He gives us centralized dependency management without the flaws of his bike. Your “bike” is almost always some kind of service locator. Their problems are known and a lot of articles have been written about them. Typhoon integration into the project is very simple and it implements everything that may be needed and even more.

    We do not see anything problematic or dangerous in using third-party components, especially those that have been tested by the community and time. The time that we could spend writing our bike is better spent on something really useful. Say, the organization of the next Rambler.iOS or the implementation of a new feature in Generalamba.

    - What will be your report on Mobius on June 4 as a result?

    - About a year ago I already talked about Typhoon. After that, I and other guys from our team mentioned him in their speeches. Unfortunately, this entailed a small local hype - many of our guests began to embed it in their projects, not fully understanding what specific benefit it could bring them. For some, this caused disappointment in the spirit of “I can write the same thing with my hands in five lines”, for someone it was chaos in the code.
    This time I want to tell you a little about something else - my presentation does not revolve around the Typhoon device and its syntax, but around specific user cases in which it helps in one way or another. Something like a set of small stories like “problem-> solution-> Typhoon”. I hope that through the prism of these examples they will see their real tasks and be able to make an informed choice - do they need Typhoon or not.

    ___________

    Useful links:
    - The promised video on the correct pagination ;
    - Report of Egor at Mobius 2016 (St. Petersburg, June 4);
    - All Mobius development reports for iOS.


    Also popular now: