“Our application is like a TARDIS: inside is bigger than it seems outside” - Avito on mobile development



    You can’t argue that Avito pays attention to mobile development: they started using Kotlin long before it became fashionable, and speakers from this company regularly speak at our Mobius conference . And on the eve of Moscow Mobius, we asked two Avito employees: Dmitry divor Voronin told us just about the experience of using Kotlin, and Yegor YourDestiny Tolstoy about mobile development in general.

    Dmitry Voronin


    - Earlier you had a report on Kotlin and Rx, based on the experience of Avito - and what exactly do you do in the company?

    - At the moment I am developing the infrastructure for self-testing as part of a special team organized to shorten the release cycle of applications.

    - Now in the Android world, everyone loves Kotlin, but Avito started using it much earlier - and from what moment?

    - The first class at Kotlin in Avito appeared in the region of December 2014. Later, in 2015, we decided to write all new Android application code in Kotlin. It turns out that we have been using Kotlin since the beta versions.

    - What originally prompted him to use? Avito is actively using Square’s mobile developments, where Kotlin enthusiast Jake Wharton worked - did it somehow affect?

    - In 2014, it seemed that Java 6 would be with us until the end. Google did not disclose any plans at that time. After writing dozens of classes in Kotlin in an existing project, a look at the Java + Guava bundle instantly provoked despondency. More readable code, plus more strongly typed code, plus interop with existing code — it looked like a win-win situation.

    Jake and the other evangelists certainly had a big impact pushing this decision. It was very interesting to re-read his iconic post .

    - How much has changed in Kotlin development during the time that you use the language? How much more convenient it became, and did you have to “relearn” regularly?

    - Yes, a lot has changed, it has become noticeably more comfortable to work with Kotlin. We started when there was no incremental compilation for Gradle projects, the code formatting settings were from several checkboxes, we had to disable inspections, which slowed the IDE. Now all this is in the past.

    We try to use the new features of the language as they appear, however, we have not yet included coroutines and immutable collections in the project, but I think that this will come soon. Such changes are not rolled out at once to the entire project, but gradually penetrate the code base. Everyone has time to get used to and discuss the feasibility and pitfalls.

    You have to relearn mainly when you open the source in Java: every time I forget to put a semicolon at the end of the line;)

    - Can you highlight the “pitfall” of Kotlin, which I would like to draw the attention of those who are only thinking about using the language?

    - I’ll clarify that we are talking about Android. There are several of them:

    1. Annotation processing (kapt) is an extremely unreliable part of Kotlin, to such an extent that in some modules we consciously abandoned all the tools working through code generation. Until recently, it was generally possible to use it only at your own peril and risk, but the situation is improving. The bundle of Dagger 2 modules and factories of components written in Java + annotationProcessor from the Android plugin for Gradle still works more efficiently in our project than kapt.
    2. The tooling around Kotlin still lags behind Java in many key aspects. The absence of static analyzers is most painful (Android Lint will only learn to look at Kotlin source files in the next version), and the Lint support built into Android Studio opens up new challenges for launching in CI and has a number of unpleasant bugs.
    3. Performance: The Kotlin plugin on large projects is poor. Issues on this topic close every new release, but Java is still a long way off.

    Arthur Dremov has an excellent overview of these and other shortcomings.

    - How did official Google support affect Kotlin’s use - what did you see in the community before Google I / O, and what after?

    - We organized a meeting of Android developers with the participation of Dmitry Zhemerov in 2016, and it was clear that people wanted to try a new language in their projects, but the uncertainty stopped many. I think Google support has paved the way for many.

    A certain foundation of confidence has emerged. If there was no doubt in JetBrains anyway, then the fork from Intellij IDEA called Android Studio was increasingly stepping aside (a bit of instant run magic here, a bit of hardcode in the classpath here ...) and, it seemed, Kotlin support would not keep up behind it. Now you can exhale.

    - Android Studio 3.0 with Kotlin support “out of the box” and other innovations is now out - but does this release change anything for you or not?

    “I honestly didn't notice anything.” It looks as if they have added the Kotlin IDE plugin, deprecated for a couple of version releases, to the predefined list.

    Major changes await us in version 3.1 with the first Android Lint support for Kotlin files.

    - Recently there was a forecastthat at the end of 2018, Android applications will begin to write more often in Kotlin than in Java - how much do you believe in such a forecast, and what do you expect from Kotlin in the future?

    - The forecast is quite realistic, I do not see any obstacles. There will be more Kotlin support in popular libraries (nullability annotations in the android support library are a great example).

    It is already known that in Kotlin versions 1.2 and 1.3, developers focused on compiler performance and development tools, there are few changes in the language. For me, this is a good sign: problem areas are tightening.

    I look with interest at Kotlin / Native, however, in my realities I doubt that we will be the first to shuffle the code between platforms. We look forward to success stories from fellow hipsters!

    Egor Tolstoy


    - What do you do at Avito?

    - Over the past year, I was responsible for all the mobile development at Avito - building an engineering culture, developing and implementing a team development strategy, responsibility for the stability of our applications and the continuity of their releases. At some point, I began to use one simple metaphor, so as not to go into lengthy explanations. If you imagine that mobile development is an excavator, then my role was to ensure that it worked properly, that it could dig without failures and that the fuel in the tank did not end.

    More recently, the situation has changed. Now, in my area of ​​responsibility are the teams responsible for the technical development of all the platforms on which Avito works - Web, Mobile Web, iOS and Android. We are responsible for the release cycle of these platforms, the development of their architecture, the creation of useful tools for developers and a number of other projects. If we return to the metaphor with an excavator, then, in addition to its service, I now also act as its driver.

    - You simultaneously conduct two telegram channels with links to texts: Android Good Reads and iOS Good Reads . There is no refraining from a semi-serious question: does your head not tear open to actively monitor two worlds at once? How do you live with it?

    - Yes, it’s not very difficult, I’m used to save all interesting links in Pocket and periodically read them. Well, put in the channels the most interesting for long. Although, of course, I look through many things diagonally, and if what I see seems to be potentially useful to subscribers, I also publish it.

    - And for a mobile development in Avito as a whole, a situation is typical when a person is simultaneously monitoring different worlds, or is there a more typical division?

    - Everything is cool with us. Many developers do not focus only on their platform and language, and help their colleagues if they wish or need. It happens that a mobile developer writes a backend for his task, it happens and vice versa.

    We strongly believe in the importance of T-shaped skills and that for really cool developers changing the language and frameworks is not a problem.

    - In addition to telegram channels, do you participate in the submarine podcast, acted as a speaker on Mobius, now participate in its program committee - is it all “just for yourself”, or do you feel that it has a beneficial effect on your work?

    - Basically for myself - I'm really interested in doing this, it's a hobby that brings buzz. Everything else rather comes with a cool extra bonus.
    The importance of all this for their professional development cannot be denied. Particularly noteworthy is participation in the podcast, thanks to which I get to know someone every week who is somehow much cooler than me, and learn from him some of the knowledge and skills.

    - You gave a talk about code review, but how does this process look specifically in Avito?

    - Work on Avito takes place in parallel in several dozen teams, each of which is responsible for a certain part of the product’s functionality or the satisfaction of some user needs. Each of the teams is as independent as possible and fully responsible for the quality and timing of the implementation of its features. To exclude dependence on other people at the stage of code review, we try to close this process within the framework of one team.

    This is one side of code review. The other is that we are nevertheless sawing one product, which is why there are often situations when guys from one team must make changes to the code for which another is responsible. To prevent chaos, we are actively developing a system for automatically detecting code owners and the ability to subscribe to changes in certain files, modules, or folders. Thanks to this, those who need to know about the changes that have occurred will not miss them.

    - From the outside it may seem that Avito requires a simple application (roughly speaking, “take the catalog and display”), but if you delve into it, there are immediately nuances: for example, you wrote and opened your own media player Paparazzo. Can you give more examples of unobvious tasks?

    - I love these stories about "simple applications." Uber generally has one screen, and more than a hundred mobile developers are working on it. Avito application like TARDIS: inside much more than it seems at first glance outside.

    We love to talk about interesting tasks we face in our work. A few examples:


    Our two teams, Mobile Architecture and Mobile Speed, are closely involved in the technical development of mobile development. Here they have almost every day get up nontrivial challenges - modular architecture, component tests, release automation, compilation acceleration, and much more. And we will talk about all this soon too.

    - You are a member of the Mobius program committee, and have already seen reports at rehearsals - do you want to draw the attention of the conference participants to a specific report that should not be missed?

    - It’s clear that I first recommend going to the reportMax Sokolov from Avito. He shares a very cool experience in creating a mobile messenger that can be useful to developers in other products. Look at Gleb Novik too. Not because he also hosts our podcast, but precisely because of his report . The implementation of the service layer in operations is a bomb, I used this approach very actively and received a lot of profit.

    Anyway, all the reports we have are very cool. The selection was as tough as possible, and what was left in the program was really the best of the best. I initially strongly believed in the story of the holding in Moscow, Mobius, and the current composition of the speakers and their reports confirm the future success.

    - Thank you! We will be waiting for you at Moscow Mobius , but for now we will remind readers of your report on code review from St. Petersburg:


    Also popular now: