Kotlin em produção: ter cautela ou ir em frente?
Esta é uma tradução autorizada do artigo “Kotlin in Production: Should you stay or should you go?”, de Danny Preussler.
No mundo Android, Kotlin parece estar em todos os lugares. É difícil ir a uma conferência or mesmo ler um blog sobre Android sem que Kotlin seja mencionado. Lembro que na Droidcon Berlim do último ano, a maioria das pessoas com que conversei já iniciaram a usar Kotlin em produção (dois meses mais tarde, eu publiquei minha primeira atualização de app com Kotlin). De fato, Kotlin causou um impacto maior na comunidade Android do que na comunidade Java. Estou certo que mesmo a JetBrains ficou surpresa com isso. Mas faz sentido: desde o início do Android, nós desenvolvedores ficamos amarrados com uma versão de uma linguagem fora de moda, enquanto outras plataformas e linguagens evoluiram. Kotlin nos tornou competitivos novamente.
A placa de “PARE”
Porém, às vezes o entusiasmo dos desenvolvedores é controlado por stakeholders. Apesar de todas ótimas vantagens de Kotlin para sua base de código e velocidade de codificação, é bem provável que você conseguirá um NÃO para o uso de Kotlin. Alguns de seus argumentos podem ser facilmente descartados, outros trazem consigo alguma verdade.
Vejamos alguns deles:
Todos no time precisam aprender uma nova linguagem
Um argumento obviamente pertinente. Boas notícias: a curva de aprendizado de Kotlin é realmente baixa. A curva de aprendizado de RxJava, por exemplo, é muito mais íngreme do que a de Kotlin.
No começo, você escreverá Java com palavras-chave Kotlin, que acaba funcionando bem. Além disso, existe uma possível conversão diretamente de Java para Kotlin através do apoio da IDE (i.e., Android Studio).
Mas claro, você precisa encontrar um modo de todos comprarem essa ideia. E isso requer tempo. E tempo significa dinheiro para seus stakeholders.
Uma boa maneira de começar sem qualquer risco é através de testes. Testes estão em um ambiente seguro, tal qual seja possível o experimento de novas ferramentas. Inicie por migrar seus testes ou, no mínimo, escrever novos testes em Kotlin. Realmente, Kotlin traz ótimas features que irão melhorar seu código de teste. Após um período, todos terão uma ideia de como Kotlin funciona e, então, você pode dar o próximo passo.
A propósito: seu time aprendendo uma nova linguagem é uma boa ideia.
Difícil de encontrar desenvolvedores com experiência em Kotlin
Realmente, a maioria dos desenvolvedores estão ansiosos por novidades e, aqueles que não se encaixam nesse grupo, são aqueles que você deve dosar bem se vale a contratação ou não. Então, ofertando a bons candidatos a oportunidade do uso de Kotlin aumentará a chance de contratá-los. Nós estamos vendo isso com Swift; já é difícil encontrar alguém que curta trabalhar com Objective-C. E Swift tem só três anos de idade. O problema é real. Veja o mundo em que vivemos: um mundo onde precisamos de recrutadores para obter as melhores pessoas. Nós temos mais posições a serem preenchidas do que desenvolvedores que estejam dispostos a aplicar-se a essas posições. Desafiando candidatos com uma nova tecnologia é um bom modo para encontrar aqueles que se importam e que irão impulsionar seus produtos além.
Kotlin não é suportado pelo Google
Isso é verdade, mas Android depende de bytecodes. E os bytecodes de Kotlin e Java, ao final de um processo de compilação, são iguais. Nós somente estamos falando sobre a linguagem em que nós estamos escrevendo o código. Google dispensou o Jack toolchain e confirmou o suporte ao compilador javac para o suporte a Java 8. Logo, temos um futuro brilhante aqui.
O que você pode se questionar aqui é se JetBrains suporta Kotlin para Android. Felizmente, eles estão totalmente comprometidos. É uma história de grande sucesso e muito esforço. A última vez que um canary build do Android Studio quebrou algo com suporte a Kotlin, no dia seguinte, o conserto no plugin Kotlin já estava disponível.
Nota (do autor original): realmente, o Google já está usando Kotlin. Dê uma olhada no compilador de databinding para Android. Obrigado Ľuboš Mudrák pela sugestão.
É muito arriscado colocar Kotlin em um app em produção
Não há risco para o runtime do app com Kotlin. Como mencionado anteriormente, a linguagem encerra quando há a conversão para bytecode. Provavelmente, toda library que você usa traga um maior risco ao seu app do que adicionar Kotlin a ele, mesmo features como Null Safety fazem sua base de código mesmo mais segura com Kotlin.
Também, pode se dizer que Kotlin não é mais uma linguagem nova. Ela já está disponível há um bom tempo e já se encontra em uma versão estável.
Companhias com um número muito grande de funcionários já migraram parcialmente ou mesmo totalmente seus apps para Kotlin. Se elas assumiram esse “risco”, talvez valha a pena você assumir também.
É apenas outra linguagem JVM
Você já pode ter escrito apps Android em toda linguagem com suporte à JVM (Java Virtual Machine) antes, mas, de repente, ainda não escreveu. Por que nós deveriamos escrever agora?
Eu me recordo de pessoas que tentaram escrever apps em Scala para Android, mas era complicado, pois você precisava, também, entregar as runtime libraries.
Kotlin é projetado com Android em mente. O runtime é muito pequeno. A maioria das libraries que você usa são muito maiores. Isso é o que é diferente agora!
Nós não temos tempo para reescrever nosso app
Você não precisa! Kotlin e Java funcionam perfeitamente juntos. Você invoca Java de Kotlin, e vice-versa, naturalmente. Você decide para toda classe que você escreve qual linguagem funciona melhor para você.
Uma nova linguagem irá nos atrasar
Uncle Bob escreveu isso há um tempo atrás: cada nova linguagem nos lançava de volta no tempo, pois nossas ferramentas necessitavam ser reescritas do zero. Olhe para Swift, mesmo nos dias de hoje, o suporte não é tão bom ainda como o suporte que Objective-C tem no XCode. O lado bom é que Kotlin está sendo trazido de um fabricante de ferramentas (JetBrains). Kotlin está vindo através dos responsáveis que trouxeram-nos IntelliJ, a ferramenta base para o Android Studio. O suporte para IntelliJ é tão bom quanto para Java. Realmente, é tão bom que Gradleware iniciou a suportar Kotlin para scripts Gradle. A razão foi o suporte a ferramentas! Groovy, a atual linguagem de Gradle, através de muitos anos, nunca conseguiu tão bom suporte como Kotlin já tem agora.
Também, todas suas ferramentas de análise de código que funcionam com bytecodes funcionarão fora da caixa. O que falta podem ser ferramentas de análise estática que atuam sobre código-fonte diretamente. Esse é um pequeno passo para trás, mas será tratado muito brevemente pela comunidade. Nesse meio tempo, nós temos Klint como um alternativa para garantir que continuemos a entregar código de alta qualidade.
Então, por que nossos stakeholders hesitam?
Mobile tornou-se um negócio de fundamental interesse para a maioria das companhias. Seja lá qual for a área em que você esteja, as chances são altas que a maioria de seus clientes encontrem você através de um app. Porém, em suas atividades-núcleo você tende a ser cuidadoso com mudanças, o que é totalmente válido.
Mudança, a essência do mobile
Mas vamos também lembrar: o desenvolvimento mobile é definido por mudança contínua. Diferentemente do mundo de desenvolvimento backend, por exemplo, as coisas mudam rapidamente o tempo todo.
Nos poucos anos de existência do Android, nós tivemos, no mínimo, três interfaces de usuário completamente diferentes: Pre Holo, Holo e Material Design. Nós, também, tivemos três diferentes API’s para enviar notificações de push: XXX, GCM (Google Cloud Messaging) e Firebase. Há apenas alguns anos atrás, a arquitetura de apps mais difundida envolveria um Content Provider que esconderia as chamadas HTTP de você. Seu cliente REST (provavelmente baseado em Apache) sempre escreveria resultados em uma base de dados SQLite. Injeção de dependência foi um anti-pattern devido a razões de performance apenas há alguns anos atrás. Não havia ReactiveX e programação funcional permaneceu no backend, ou provavelmente somente em universidades.
Se nós, desenvolvedores mobile aprendemos uma coisa com o tempo, é que mudança é constante. Construir blocos não funciona, pois no momento em que você os escreve eles podem estar desatualizados. Um app que não foi tocado por três anos pode ser jogado fora. Isso foi e ainda é válido em Android. Tente contratar um desenvolvedor que gostaria de trabalhar em um app que ainda suporta Android 2.0 e/ou usa o ContentProvider pattern mencionado acima! Boa sorte com isso.
Não fique para trás
Kotlin é apenas outra dessas mudanças. Não ignore a mudança. Quem sabe, a base de código Java em que você está protegido agora, pode acabar com o que todos nós chamamos de sistema legado.
