5 Coisas Que Eu Aprendi Com Desenvolvedores Autores Estrangeiros
(2854) (3)
CategoriasAndroid, Design, Protótipo
AutorVinÃcius Thiengo
VÃdeo aulas186
Tempo15 horas
ExercÃciosSim
CertificadoSim
CategoriaDesenvolvimento Web
Autor(es)Robert C. Martin
EditoraAlta Books
Edição1ª
Ano2023
Páginas416
Tudo bem?
Se você já acompanha o Blog e o canal Thiengo.com.br a algum tempo, então você deve saber que eu curto muito a leitura sobre desenvolvimento de software.
Mais precisamente tudo aquilo que é possível aplicar no dia a dia do desenvolvedor Android.
E quando falando em leitura técnica, com segurança eu afirmo a você: a maioria dos títulos são de estrangeiros.
Muitos autores são americanos atuando no mercado dev americano ou somente atuando como profissionais de desenvolvimento nos Estados Unidos.
Você possivelmente já ouviu falar de nomes como:
- Robert Martin (Uncle Bob);
- Martin Fowler;
- Kent Beck;
- e Gilmore (e a galera do PHP faz um "Aeee").
Mas acredite: a gama de estrangeiros que são excelentes profissionais de desenvolvimento e também são autores de livros, essa gama é imensa.
Alguns nomes não muito "bangs!", porém que têm títulos excepcionais, são:
- Pete Goodliffe;
- Dustin Boswell;
- Trevor Foucher;
- Joshua Kerievsky (melhor livro de refatoração que eu já li);
- e Max Kanat.
E lendo livros de autores estrangeiros, aos poucos você entende que ao menos no mercado americano (vou parar de utilizar estrangeiro a partir deste ponto)…
ao menos neste mercado há algumas coisas, conselhos, que são comuns também no Brasil e outras que não são nem mesmo comentadas aqui.
E de todos esses pontos, eu vim aqui listar cinco que acredito que serão úteis a ti principalmente se você estiver almejando alguma vaga de desenvolvimento Android (home office, por exemplo) para receber em dólar americano.
Pode ser que você se surpreenda ou não.
De qualquer forma, lhe convido a ir até o fim. Pois coloquei também os nomes de algumas ferramentas que seria prudente, como developer Android, começar a utilizar o quanto antes.
Note que dou ênfase no "mercado americano". Pois ao menos no desenvolvimento de apps Android, digo, ao menos no desenvolvimento mobile... é este o mercado que "dá as cartas".
Bom, é isso.
Vamos aos cincos pontos que praticamente todos os autores do american development market sempre estão apontando em seus títulos sobre desenvolvimento.
- Testes;
- Fase de projeto (antes de codificar);
- Domine o ambiente de desenvolvimento;
- Eles erram tanto quanto nós;
- Tenha um hobby;
- Assim podemos concluir que….
Testes
Sim, os testes.
Ao menos testes unitários você tem que saber construir. Isso é algo que os autores tratam como base de um profissional de programação de software.
E quando falo como base de programação é a base mesmo.
Ou seja, em uma entrevista para uma oportunidade de Engenheiro Kotlin Android, mesmo sendo uma vaga para júnior.
Nessa entrevista ninguém vai lhe perguntar se você sabe declarar variáveis mutáveis ou não mutáveis em Kotlin, certo?
Sobre o conhecimento e domínio dos testes unitários, o comportamento do recrutador será exatamente o mesmo. Ele vai tratar o assunto “testes unitários” como algo óbvio, que você sabe fazer.
É possível perceber pelos textos dos autores que eles nem mesmo citam softwares nos quais eles chegaram a trabalhar e não continham ao menos uma carga de testes unitários.
E saiba você que o principal motivo dos testes é: manter o software em evolução saudável.
Não sei se você já leu isso em alguns dos meus textos, mas a maioria dos aplicativos (até mesmo os apps Web), se tornam lucrativos no longo prazo.
E longo prazo imediatamente nos faz lembrar de… software legado.
Os testes ajudam a evitar esse problema: software legado e consequentemente péssimo para manter a evolução.
Não é incomum nós desenvolvedores termos que começar do zero em um novo projeto, pois o engenheiro líder definiu que não era mais possível atualizar a versão atual do software.
Para finalizar este tópico importante, uma informação que acredito que será um incentivo a você caso ainda não utilize testes:
Aprender testes unitários é extremamente fácil.
Testes unitários não são nada complexos e qualquer semaninha que você resolver investir o seu tempo nisso…
certamente essa única semana já lhe dará segurança para falar em entrevistas que sim: que você sabe utilizar de maneira consistente testes unitários em Kotlin, por exemplo.
Um detalhe, se você sabe que o software não será mantido. Como exemplos temos os hot apps e hotsites.
Neste caso não tem porque trabalhar com testes se não for somente testes de interface com o usuário. O popular: rodar no emulador e navegar pelo app.
Caso contrário você tem grandes chances de jogar tempo fora, pois os testes (não incluindo os testes de interface) foram feitos principalmente para projetos de software com perspectivas de longo prazo.
Fase de projeto (antes de codificar)
Segundo os autores, algo que o mercado americano trata como fundamental para o sucesso de qualquer projeto de software é toda a fase de:
- Coleta de requisitos;
- Análise de projeto;
- Definição de projeto.
E tudo aquilo mais que deve vir antes de começar a codificação.
Com um bom investimento de tempo e qualidade na fase de projeto, então é muito provável que o aplicativo seja entregue, no mínimo, suprindo todas as expectativas.
Recentemente aqui no Blog eu liberei a resenha completa de um livro que eu julgo ser o livro mais importante que ao menos aquele que se diz desenvolvedor Android deve ler.
Sim, é o livro As Leis Fundamentais Do Projeto De Software. Não deixe de investir tempo ao menos na leitura desta resenha.
Em resumo, este título vai literalmente também lhe mostrar o porquê de investir na fase de projeto. Mesmo em projetos solo.
Uma fase de projeto muito bem feita faz com que a programação seja apenas um detalhe.
Sim, eu sei que pode ter soado ofensivo.
Eu também sou desenvolvedor e não acho prudente alguém me falar que a parte de codificar é um detalhe.
Digo, falar de maneira que soe como sinônimo de: codificar é a parte fácil de todo o projeto.
Mas a verdade que o mercado nos mostra, e não somente o americano, é que a tarefa “programar" é a tarefa fácil de todo um projeto bem planejado.
Ok, Thiengo. Mas como o mercado nos mostra isso?
Simples: o comum é que os desenvolvedores tenham os menores salários dentro de toda a equipe de projeto… e que eles também sejam maioria.
Em resumo, para este tópico, é isso:
Invista na fase de projeto. Mesmo que seja um projeto solo. Assim são grandes as chances de entregar ao menos o que já era esperado.
Domine o ambiente de desenvolvimento
Quando digo Ambiente de Desenvolvimento estou principalmente falando sobre o IDE e o sistema de controle de versões (SCV) que você utiliza.
O "tom" que os autores utilizam nos livros é resumidamente o seguinte:
Antes de querer aprender técnicas de refatoração, padrões de projeto e técnicas de código limpo. Antes disso, domine o seu ambiente de desenvolvimento.
Se você está no mundo Kotlin Android, investir tempo para ficar confortável com:
- Android Studio IDE;
- Git e GitHub (incluindo o trabalho em branches);
- e Bitrise - software de entrega contínua normalmente utilizado em projetos Android de médio e grande porte.
Investir tempo ao menos nestas ferramentas será um baita investimento em sua carreira como desenvolvedor de aplicativos "nativos" Kotlin Android.
Se você tiver em mãos o meu novo livro Mapas Android de Alta Qualidade, então você entende o porquê de eu ter colocado "nativos" entre aspas.
Enfim…
uma curiosidade em relação ao "domínio do Android Studio"…
existem desenvolvedores Android que ou utilizam somente a classe Log para depurar o código ou utilizam somente a ferramenta de Debug.
Acredite: utilizar ambos tende a ser a escolha mais inteligente.
Em casos de exceção, o aplicativo parou de funcionar. Nesses casos utilizar a classe Log, ao menos para mim, é mais produtivo.
Em casos de erros de lógica, ou seja, o aplicativo funciona, mas a saída não é a esperada. Nesses casos, a ferramenta de Debug tende a ser bem mais produtiva do que alguns Log.i() espalhados pelo código-fonte.
Por fim, para este tópico:
Dê uma atenção especial ao trabalho com branches no Git.
Pois quando trabalhando em time não é incomum, por exemplo, mais de um desenvolvedor estar agindo no mesmo trecho do projeto.
Se o SCV for o Git (e provavelmente vai ser), conhecer o trabalho com branches vai ser de grande utilidade.
Eles erram tanto quanto nós
Todos os títulos (que eu li), absolutamente todos os títulos dos autores que estão no mercado americano…
todos têm cases de problemas que eles enfrentaram que, sinceramente, beira o absurdo.
São histórias do tipo:
Aqui ninguém utiliza sistema de controle de versões, porque dá muito trabalho.
Cada um tem que enviar o e-mail no dia correto para o engenheiro líder de projeto. Neste e-mail contém as atualizações do software.
Então o engenheiro líder decide o que passa e o que não passa como atualização válida.
Assim funciona que é uma beleza!
No livro Como ser um programador melhor de Pete Goodliffe tem um case "incrível" atrás do outro.
Em um deles ele fala sobre projetos onde os desenvolvedores veem a equipe de QA (Quality Assurance - Garantia - ou Controle - de Qualidade) como inimigos. Que um deve tentar combater o outro.
Este tópico para mim é um dos mais importantes aqui, principalmente se você está iniciando na área de desenvolvimento de aplicativos.
Isso, pois quando eu estava iniciando eu ainda tinha um platô na minha empolgação. E o platô girava em torno do seguinte mindset:
Todos os desenvolvedores americanos são muito melhores do que nós. Certamente não vale a pena querer investir tanto em mim na área de desenvolvimento.
Isto é, e com segurança eu seguro essa bandeira: bullshit!
E você mesmo pode confirmar isso…
provavelmente você conhece mais de um desenvolvedor do Brasil e no Brasil que foi exportado para as gringas. Com destaque para Irlanda e Canadá (Quebec principalmente).
Então sim, se houver esforço e dedicação, você não somente vai ficar no nível de qualquer americano que é destaque em desenvolvimento de aplicativos como você provavelmente também será tão bem sucedido quanto eles.
Tenha um hobby
Parece clichê, certo?
“Você precisa espairecer a cabeça e blá, blá, blá…”
Não são todos os autores, mas principalmente os mais famosos, como Robert Martin.
Esses autores indicam que é inteligente ter algum hobby distante da área de desenvolvimento.
No livro O Codificador Limpo de Robert Martin, este que é um dos livros mais aclamados dele.
Neste título o autor, em vários trechos, lhe incentiva a investir na leitura de novelas e romances.
É sério, ninguém me falou isso. Eu li no livro.
Pete Goodliffe é outro que fala sobre a importância de ter um hobby.
E sim, isso é importante.
No livro "Maestria" de Robert Greene (leia, se você tiver tempo, pois é um baita livro) o autor mostra de maneira explícita, que os grandes gênios (e isso é em comum acordo) têm as grandes ideias quando estão longe do problema que têm de resolver no dia a dia.
Ou seja, quando estão “de boa”. Longe do ofício.
Obviamente que não estou lhe incentivando a chegar no seu superior e falar:
Das minhas oito horas diárias de trabalho, preciso de ao menos três para me tornar o Michelangelo do departamento de desenvolvimento.
Você certamente vai ser no mínimo motivo de risadas.
Mas em seu tempo livre, segundo os autores, é prudente também dedicar parte dele a algum hobby… qualquer um.
Fazer bolo de copo, por exemplo. Tem que ser algo fora da área de ofício e que você faça principalmente por prazer.
Eu particularmente gosto de correr, na parte da noite.
Assim podemos concluir que…
em termos humanos, conhecimento técnico. O mercado americano não está tão distante do nosso. Aliás nem mesmo perto disso.
Conheço empresas no Brasil, que ao menos para vaga de desenvolvedor Android pleno, elas vão assumir que você já tem conhecimento e prática com:
- Controle de versão;
- Testes unitários;
- e Integração contínua.
Mas confesso que não me lembro de algum desses autores, nem mesmo ao menos um deles, dando importância para ter o conhecimento de metodologias ágeis de gerência de equipe.
Metodologias como: Scrum e Kanban, por exemplo.
Acredito que isso acontece porque em termos de gerência de projeto os desenvolvedores não terão de investir muito tempo para entender a metodologia ágil em uso.
Bom, se você pretende aplicar para alguma oportunidade no exterior. Assumindo que o seu inglês está "tinindo".
Então o conteúdo deste artigo será ao menos um norte para você… espero que seja ao menos isso.
Mas me diga, se você tem experiência com livros, entrevistas ou até mesmo com trabalho no exterior… comente abaixo algo que você acredita ser justo adicionar a este conteúdo.
É isso.
E… não se esqueça de se inscrever na lista de e-mails do Blog 📩 (que é gratuita) e assim receber também os conteúdos exclusivos que eu libero somente por lá.
Abraço.
Comentários Facebook