Desenvolvedor(a) Android: Um guia prático para se tornar — Parte 2
Na última semana publiquei a parte 1 deste artigo (se não viu, clique aqui) onde abordei o conhecimento essencial que qualquer desenvolvedor Android deveria conhecer: Lógica, Lifecycle, Kotlin, viewGroups e Jetpack Components.
E obviamente, dentro de cada um dos tópicos citados acima, existe uma infinidade de conteúdo para se aprofundar, o que pode te levar a meses de estudos. Mas vamos considerar que você já conseguiu uma boa bagagem utilizando LiveData, viewModel, entendeu a diferença das etapas de um ciclo de vida, e sabe estruturar um ConstraintLayout facilmente. E agora?
Agora chegou a hora de nos aprofundarmos um pouco mais e começar a explorar um mundo que pode te destacar durante uma entrevista.
Consumo de APIs
Sei que para quem nunca programou e está iniciando na área, esse termo "consumo de APIs" pode não significar absolutamente nada. Termos como response, payload e JSON pode assustar muita gente. Mas afinal, o que é uma API?
API é um conjunto de rotinas e padrões de programação para acesso a um aplicativo de software ou plataforma baseado na Web. A sigla API refere-se ao termo em inglês “Application Programming Interface” que significa em tradução para o português “Interface de Programação de Aplicativos”. — CanalTech
Traduzindo a termos menos técnicos: uma API é uma interface responsável tanto por nos fornecer informações de um servidor, quanto executar alguma ação neste mesmo servidor.
E saber conectar seu aplicativo com essas APIs é de extrema importância. E existem diversas formas de fazer isso. Atualmente, por exemplo, eu utilizo RxJava. Mas considerando-se a complexidade em sua manipulação, e supondo que vocês estejam estudando com Kotlin, recomendo fortemente que estudem Coroutines.
Material: Existem centenas de materiais incríveis na internet para aprender sobre Coroutines, mas eu gosto muito dos artigos do Android DevBr (inclusive, siga-os no medium para ficar por dentro das novidades do mundo Android): Veja o artigo aqui.
Bônus: Entra aqui também, um estudo extremamente importante que é sobre threads. Saber o que deve ser executado em MainThread, o que deve ser assíncrono, etc. podem lhe dar uma enorme vantagem na construção de um aplicativo.
Arquitetura & Padrões de Projeto
É fato que qualquer aplicativo que preze por qualidade precisa ter uma arquitetura bem definida. Entender algumas das opções de padrões de projeto mais utilizadas é de extrema importância para conseguir separar responsabilidades, construir um aplicativo robusto, escalável e mais do que isso: ser capaz de se encontrar em um projeto, por mais distintos que possam ser os contextos.
Mas não se desespere! Esse é um assunto complexo, e muito extenso. Você não irá dominar arquitetura e padrões de projetos lendo alguns posts. O ideal é que busque estudar constantemente sobre.
Alguns materiais de estudos que recomendo:
- Documentação Android
- Medium do Android devBr
- Meu próprio artigo sobre MVVM x MVP
- Livro "Clean Architecture" do Robert C. Martin
Bônus: Tratando-se de arquitetura e padrões de projeto, um estudo de extrema importância é SOLID. Trata-se de um acrônimo que nos trazem boas práticas de desenvolvimento de software, visando construir aplicações cada vez mais independentes, com alto poder de escalabilidade e testável.
Eu escrevi uma série de artigos explicando cada um dos princípios de forma mais simplificada, que você pode conferir aqui: Parte 1 | Parte 2 | Parte 3 | Parte 4 | Parte 5.
Modularização
Já entrevistei alguns candidatos que nunca haviam ouvido falar sobre modularização. E os poucos que já tinham ouvido falar, se limitavam a citar o benefício da "organização" ao modularizar um aplicativo. A questão é que modularizar vai muito além de organizar seu código.
Modularizar é sobre reutilização de código/feature e principalmente: sobre melhorar o tempo de build. Justamente por esses motivos, essa tem sido uma técnica cada vez mais utilizada no mercado, e portanto, algo extremamente útil para estudar.
Materiais recomendados:
Testes
Esse é o terror de muitos desenvolvedores. Muitos consideram, erroneamente, que testar é de única e exclusiva responsabilidade do QA (quality assurance). A questão é que a qualidade deve ser responsabilidade de todos. Afinal, quanto mais pessoas testarem, maior a probabilidade de um aplicativo coeso e estável.
Os testes automatizados devem se tornar parte do desenvolvimento. Ou seja, uma feature não deveria ser considerada pronta se não houver testes.
Saber a diferença entre testes unitários e testes instrumentados, qual a responsabilidade de cada um deles, como implementar, etc. é extremamente importante.
Alguns nomes para te ajudar a estudar: MockK (teste unitário) e Espresso (teste instrumentado).
Material recomendado:
- Artigo do Natan Ximenes super completo sobre testes instrumentados para o Android DevBr aqui.
- Documentação do MockK
- Features do MockK
- Bônus: Dublês nos testes
Bônus: Versionamento de Código e Metodologia Ágil
Quando trabalhamos sozinhos é fácil manter a organização de um código. Afinal, só você mexe nele. Mas agora pensa em um time como o que atuo, com mais de 70 desenvolvedores Android codando ao mesmo tempo. A probabilidade de virar uma confusão é bem grande. E para isso, é extremamente importante saber utilizar git , saber o que é uma branch, fazer um commit, etc. Afinal, não importa qual ferramenta você vai usar: GitHub, Gitlab, Sourcetree, ou tantos outros que existem no mercado: a utilização e conceitos do git são os mesmos.
Aprenda também a usar o git por linha de comando. Isso pode agilizar seu tempo em muitos cenários.
E aproveita o embalo nos estudos sobre git, e leia sobre Code Review. É uma prática muito utilizada no mercado e que é capaz de transmitir muito conhecimento (tanto para quem faz, quanto para quem recebe).
E claro, não poderia deixar de lado a metodologia ágil. É fato que muitas empresas ainda utilizam o método Cascata para desenvolvimento. Mas o ágil vem tomando mercado pouco a pouco e é difícil você pegar um grande projeto que não utilize um Scrum ou Kanban (ou quem sabe os dois, como no meu caso). Portanto, é muito válido você estudar os rituais do movimento ágil, os papéis e suas devidas responsabilidades, assim como os termos mais usados no dia-a-dia como sprint, backlog, review, etc.
Só nesses pontos acima já te dei insight de estudos para o restinho do ano. Mas é claro que a área de programação é extensa, e na parte 3, quero trazer pontos ainda mais complexos como por exemplo: processo de build, custom view, design pattern, ofuscação de código, firebase, CI/CD, etc.
Me siga no LinkedIn para ficar por dentro da parte 3 deste artigo.
Perdeu a parte 1? Veja aqui.
Code Like a Girl 👧
