“Our application as a TARDIS: more inside than it seems from the outside” - Avito about mobile development

You don’t argue that Avito is paying 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's Mobius, we asked two Avito employees: Dmitry divor Voronin told us 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 Avito's experience - what exactly do you do in the company?

- At the moment I am developing an infrastructure for auto-testing as part of a special team organized to shorten the release cycle of applications.
')
- Now in the Android world, everyone fell in love with Kotlin, but Avito started using it much earlier - and from what moment?

- The first class at Kotlin in Avito appeared in the area of ​​December 2014. Later, in 2015, we decided to write all new Android application code on Kotlin. So, we have been using Kotlin since the beta days.

- What initially prompted him to use? Avito is actively using the mobile development of Square, where the big Kotlin enthusiast Jake Wharton worked - did it have any impact?

- In 2014, it seemed that Java 6 would be with us to the end. At that time, Google did not disclose any plans. After writing a dozen classes on Kotlin in an existing project, a glance at a bunch of Java + Guava instantly caused dismay. More readable code, plus code with more strict typing, plus interop with the existing code - it looked like a win-win situation.

Jake and other evangelicals certainly had a great influence in pushing for this decision. It was very interesting to re-read his landmark post .

- How much has changed in the Kotlin-development for the time that you use the language? How much more comfortable it became, and did you regularly “re-learn”?

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

We are trying to use new language features as they become available, however, we haven’t yet incorporated coroutines and immutable collections into the project, but I think it will soon appear. Such changes are not rolled out at once to the whole project, but gradually penetrate the code base. All have time to get used to and discuss the feasibility and pitfalls.

I have to retrain mostly when you open the Java source: every time I forget to put a semicolon at the end of the line;)

- And can you single out the "underwater stone" of Kotlin, to which you want to draw the attention of those who are just thinking about using the language?

- I will clarify that we are talking about Android. There are several:

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, they could only be used at their own peril and risk, but the situation is improving. The Dagger bundle of 2 modules and component factories written in Java + annotationProcessor from Android plugin for Gradle, still works in our project more productively than kapt.
2. Tooling around Kotlin is still lagging behind Java in many key aspects. The most painful is the lack of static analyzers (Android Lint only in the next version will learn to look at Kotlin source files), and Lint’s built-in support for Lint opens up new challenges for launching into CI and has a number of unpleasant bugs.
3. Performance: Kotlin plugin on large projects leaves much to be desired. Issues on this topic close every new release, but Java is still far away.

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

- How did official Google support affect the use of Kotlin - 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 the 2016th, and it was evident that people want to try a new language in their projects, but the uncertainty stopped many. I think Google support has opened this way for many.

There was a certain foundation of confidence. If JetBrains didn’t have any doubts, the fork from Intellij IDEA called Android Studio was going away (a little bit of instant run magic here, a bit of hardcode in the classpath here ...) and it seemed that Kotlin support would not keep up behind it. Now you can exhale.

- Now Android Studio 3.0 has come out of the box with Kotlin support and other innovations - does this release significantly change for you or not?

- I honestly did not notice anything. It looks as if they added the Kotlin IDE plugin, which is outdated for a couple of releases of the version, to the list of pre-installed ones.

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

- Recently there was a forecast that at the end of 2018, Android applications would be more likely to write on Kotlin than on 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. More Kotlin support will appear 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 have focused on compiler performance and development tools, there are few changes in the language. For me, this is a good sign: problem areas are catching up.

I look at Kotlin / Native with interest, however, in our realities I doubt that we will be the first to seize code between platforms. Waiting for success stories from fellow hipsters!

Yegor Tolstoy

- What do you do in Avito?

“Over the past year, I was responsible for Avito’s entire mobile development - building engineering culture, developing and implementing a team development strategy, responsible for the stability of our applications and the continuity of their releases. At some point I began to use one simple metaphor in order not to indulge in long explanations. If we imagine that mobile development is an excavator, then my role was to ensure that it worked properly, could dig without failures, and the fuel in the tank did not end.

More recently, the situation has changed. Now the responsibility for the technical development of all the platforms on which Avito - Web, Mobile Web, iOS and Android - is in my area of ​​responsibility. 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 maintenance, I now speak in the role of its driver.

- You are simultaneously conducting two telegram channels with links to texts: Android Good Reads and iOS Good Reads . There is no stopping a half serious question: is the head not torn to actively follow the two worlds at once? How do you live with it?

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

- And for Avito mobile development as a whole, is a typical situation when a person simultaneously follows different worlds, or does a more typical separation reign?

- We have it all right cool. Many developers do not get hung up only on their platform and language, and if they wish or need help their colleagues. It happens that the mobile developer himself writes the backend for his task, it happens and vice versa.

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

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

- Basically for myself - I am really interested in doing this, this is a hobby that brings high. Everything else is more likely to go with a cool bonus.
It is impossible to deny the importance of all this for their professional development. Particularly distinguished is the participation in the podcast, thanks to which I get acquainted every week with someone who is a lot steeper than me, and learn from him some of the knowledge and skills.

- You spoke about code review, and how does this process look specifically in Avito?

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

This is one side of code review. The other is that after all we are sawing one product, which is why there are often situations when guys from one team have to make changes to the code for which the other 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 should be aware of the changes that have taken place will not miss them.

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

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

We like to talk about interesting tasks that we encounter in our work. A few examples:

• Lesha Shpirko, backend driven UI
• Timur Yusipov, working with diplinks
• Artem Razinov and Inessa Voronina, mobile design system

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 to nontrivial chellendzhi - modular architecture, component tests, release automation, compilation acceleration and much more. And about all of this, we too will soon tell.

- You are on the Mobius Program Committee, and have already seen the reports at the rehearsals - would you like to draw the attention of the conference participants to a specific report that should not be missed?

- It is clear that I first recommend going to the report of Max Sokolov from Avito. He shares a very cool experience creating a mobile messenger, which can be useful to developers in other products. To Gleb Novik, also look. Not because he also runs our podcast, but because of his report . The implementation of the service layer on operations is a bomb, I used this approach very actively and got a lot of profit.

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

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