Deixe-me compartilhar algo com você. Eu gosto da ideia de desenvolvimento multiplataforma. A capacidade de usar um conjunto de ferramentas para todas as minhas tarefas é um sonho. Quem não gostaria de usar apenas uma ferramenta para concluir com êxito suas tarefas? Escreva uma vez, corra em todo lugar? Eu quero!
Eu também gosto da idéia de uma sociedade utópica. Uma sociedade em que todos respeitam as crenças dos outros, têm argumentos significativos / lógicos / razoáveis e define a tarefa de se tornar melhor do que eram ontem. No entanto, o mundo real raramente é tão perfeito.
Quero admitir, há muito que quero discutir a disputa entre o desenvolvimento de aplicativos nativos, multiplataforma e híbridos. Não por falta de motivação, mas pela esperança ou desejo de que um dia um conjunto combinado de ferramentas apareça, abra as portas e forneça o melhor valor para a criação de aplicativos móveis. Ainda estou esperando esse dia, e este artigo deve ajudar a explicar meu apego ao desenvolvimento nativo.
Nativo, multiplataforma, híbrido? O que?
Eu poderia elaborar as diferenças de cada tipo de desenvolvimento, mas como as comparações entre elas podem ser feitas por um período muito longo, tentarei resumir essa parte.
Desenvolvimento nativo
No desenvolvimento nativo, usamos ferramentas especializadas para criar aplicativos para iOS ou Android. Ou seja, existe uma base de código para cada plataforma. Os kits de ferramentas normalmente incluem Swift / Objective-C + Xcode / AppCode para iOS e Kotlin / Java + Android Studio para Android.
Desenvolvimento multiplataforma
Usamos uma plataforma / ferramenta que traduz / compila / executa seu código como se fossem componentes nativos. O processo difere dependendo de quais ferramentas você usa, mas o resultado final é que o mesmo código é executado e funciona quase da mesma maneira nas plataformas Android e iOS.
Alguns exemplos de ferramentas: Xamarin, React Native, Flutter
Desenvolvimento híbrido
No desenvolvimento híbrido, usamos uma plataforma / ferramenta que lança um WebView, que hospeda seu aplicativo. Essencialmente, isso significa que seu aplicativo é um site que é executado a partir de seu próprio aplicativo. Uma plataforma / ferramenta geralmente também fornece acesso a suas próprias funções, como uma câmera, através de plugins.
Exemplos de instrumentos: Cordova e Ionic
Recursos Principais x Essenciais
Para entender corretamente minha escolha, preciso explicar dois tipos diferentes de características da ferramenta.
Por muitos anos, houve um debate sobre por que uma ferramenta é melhor que outra. A maioria dos artigos discute recursos óbvios da ferramenta, como o tamanho da base de código, o tempo de desenvolvimento, o número de plataformas para as quais você pode desenvolver aplicativos e assim por diante. Essas comparações, gosto de chamar de "principais características" de cada caixa de ferramentas. As principais características da ferramenta são as mais diretas para compará-las com outras ferramentas, pois geralmente você pode ver empiricamente as diferenças (ou seja, velocidades de desenvolvimento, tempo de construção, etc.). Essas características geralmente são motivo de preocupação para a maioria das pessoas, mas não revelam a essência.
Para entender completamente as conseqüências da escolha de uma ferramenta, você deve considerar as "características inerentes". Essas características são geralmente mais sutis e seu impacto é mais difícil de avaliar do que as principais características. Infelizmente, o entendimento da influência dessas características geralmente ocorre somente depois que uma ferramenta é selecionada e grandes fundos são investidos nela. Essas características são a integridade e a clareza da documentação, a disponibilidade de ferramentas convenientes etc.
Tomar a decisão certa sobre uma ferramenta de desenvolvimento requer uma compreensão de suas características inerentes.
Por que escolho o desenvolvimento nativo
Ao longo dos anos de desenvolvimento de software, tive a oportunidade de usar várias ferramentas para diferentes projetos. Normalmente, a escolha das ferramentas de desenvolvimento foi feita por mim por um engenheiro gerencial ou técnico. Assim que mudei para freelancer, decidi decidir sobre a pilha tecnológica.
No final, minha decisão final se resumiu a considerar não apenas os fatores das ferramentas, mas também como as características inerentes afetarão cada um dos meus projetos em diferentes situações ao longo do tempo e aqui estão minhas conclusões.
1. popularidade constante
Quando comecei a programar em 2013, havia muitos vocais como Cordova e Appcelerator. Alguns anos depois, o Hype mudou para o Xamarin. Alguns anos depois, já era o React Native. Agora? Flutter está ganhando popularidade.
Descobri que a popularidade da ferramenta também representa o apoio que recebe. Se a ferramenta pertencer a uma empresa privada, a popularidade será igualada às vendas, o que leva a um aumento nos custos de suporte. Se a ferramenta é de código aberto, a popularidade depende de quantos desenvolvedores ativos melhoram a base de código. A popularidade pode ir e vir e influenciar todo o ecossistema de desenvolvimento em torno dessa ferramenta.
Dê uma olhada neste gráfico do Google Trends, que mostra várias ferramentas de plataforma cruzada ao longo do tempo.
O gráfico do Google Trends exibe aproximadamente os resultados do número de consultas de pesquisa para várias tecnologias móveis entre plataformas.
Embora esse gráfico seja uma estimativa aproximada da popularidade (uma vez que representa apenas os resultados do número de pesquisas), ele fornece algumas dicas sobre o que experimentei como desenvolvedor. Empresas e indivíduos tendem a usar o que é novo. Isso não significa necessariamente que a ferramenta seja melhor ou pior (já que muitos artigos argumentam a favor / contra, independentemente da data de lançamento), mas as pessoas sempre mudam para algo mais novo.
Quando uma ferramenta é lançada, geralmente é promovida pela comunidade de desenvolvimento e é vista como um "futuro". Isso pode fazer com que ferramentas mais antigas tenham menos suporte e se atrofiem lentamente ao longo do tempo.
Compare isso com o desenvolvimento nativo, que é garantido para receber suporte. Enquanto a Apple suporta iOS e o Google com Android, o desenvolvimento nativo sempre será relevante. É por isso que o desenvolvimento nativo tem o maior ecossistema de desenvolvedores; durou apenas mais tempo e foi consistente em sua popularidade.
Outra consideração a ser feita é a transferência do projeto. A probabilidade de o próximo desenvolvedor ter pelo menos alguma experiência no campo do desenvolvimento nativo é bastante alta. Mesmo que eles não funcionem principalmente com ferramentas nativas, a maioria dos desenvolvedores se relaciona com essas ferramentas, o que é muito menos provável com soluções de plataforma cruzada.
2. Valores / Visão do Negócio
Eu raramente ouço muitas pessoas discutirem o valor comercial ao comparar ferramentas de desenvolvimento. Perguntei a vários desenvolvedores e até proprietários da área técnica sobre isso, e na maioria das vezes o que recebi em troca foi uma aparência vazia. É importante entender como o valor comercial está correlacionado com uma ferramenta específica e como ele pode fornecer esse valor.
Por exemplo, tome Xamarin. Em fevereiro de 2016, a Microsoft comprou o Xamarin por cerca de US $ 400 a 500 milhões. Naquela época, a visão da Microsoft estava principalmente relacionada ao desenvolvimento de aplicativos móveis. Eles fizeram um progresso significativo com essa ferramenta e até a incluíram como um suplemento pronto para uso para o Visual Studio e o Visual Studio para Mac. Avanço rápido de alguns anos, e a visão da Microsoft mudou para a inteligência artificial.
Durante essa mudança de visão, trabalhei em um projeto com o Xamarin. Durante esse período, familiarizei-me com uma plataforma com a qual tive que mudar de um conjunto estável de ferramentas para um lentamente degradante. Cada atualização da ferramenta parecia uma tentativa, pelo menos para não quebrar nada. Na melhor das hipóteses, tudo funcionou como deveria. Na pior das hipóteses, você passou horas ou até um dia ou dois revertendo as atualizações e tentando recuperar o ambiente em bom estado.
Essa degradação lenta não está documentada na página inicial do Xamarin (o que é compreensível), mas se você procurar informações nos fóruns, poderá sentir que algo mudou ao longo do tempo. As mensagens sobre o que costumava funcionar imediatamente agora não funcionam ou sobre como a experiência do desenvolvedor com essa ferramenta mudou. Tudo isso afeta diretamente o custo de desenvolvimento, não apenas por causa das horas brutas, mas também por causa da qualidade do código.
A lapidação durante a transição para uma nova ferramenta leva a um aumento nos custos indiretos e na perda de lucro
Admito que o desenvolvimento nativo também tenha seus problemas aqui. Por exemplo, a Apple geralmente tenta fazer com que os desenvolvedores desenvolvam de uma certa maneira (por exemplo, usando o Storybords ou o modelo MVC). O kit de ferramentas também nem sempre é perfeito, então eu realmente uso o AppCode na maior parte do meu desenvolvimento iOS. No entanto, tanto a Apple quanto o Google gastam uma quantidade enorme de tempo e dinheiro para garantir que os desenvolvedores se sintam confortáveis em desenvolver soluções nativas. Basta olhar para o Android Jetpack, SwiftUI ou até atualizar para Kotlin e Swift.
Por fim, o Google ou a Apple não tem a melhor visão do mundo, mas é consistente. Há uma probabilidade mínima de que as empresas durante a noite se recusem a apoiar suas ferramentas.
3. Economizando tempo
Ah, sim, economizando tempo. O Santo Graal da eficácia no desenvolvimento. Este tópico muito debatido sobre QUALQUER ferramenta de desenvolvimento pode criar ou destruir um negócio. Este tópico está na vanguarda de qualquer projeto, pois afeta diretamente o custo. Mas vamos dar um passo atrás e nos fazer uma pergunta.
O que podemos fazer para economizar tempo?
Eu vou explicar Como no software comercial, geralmente existem várias maneiras de resolver um problema. A decisão vem principalmente da situação de uma pessoa ou empresa em particular. Isso significa que a abordagem “uma solução serve para todos” é perigosa; também se aproxima muito da mentalidade "sempre fizemos". Infelizmente, quando se trata de desenvolvimento móvel, uma abordagem comum para economizar tempo é escolher uma ferramenta de plataforma cruzada. Mas isso é tão bom? Podemos dizer, por exemplo, outro método para resolver o problema? Nos negócios, existe um ditado "As pessoas estão acima dos processos, acima das ferramentas".
Pessoas acima de processos, acima de ferramentas
É exatamente isso que deve ser considerado ao tomar uma decisão. Como o tempo de desenvolvimento entre a escolha de uma ferramenta e a criação de processos / procedimentos ou mesmo a criação de uma abordagem diferente para o desenvolvimento?
Uma ferramenta capaz de resolver uma mentalidade ruim durante o desenvolvimento?
A ferramenta agiliza o processo de desenvolvimento?
Um processo ou mentalidade ligeiramente modificada pode levar a melhores resultados para economizar tempo?
Podemos usar a infraestrutura para resolver nossos problemas?
Todas essas são perguntas corretas que também mostram a complexidade da solução. Não é tão simples quanto escolher a próxima estrutura de plataforma cruzada em vez do desenvolvimento nativo. O que é certo para você ou sua empresa? Somente você pode fazer essa escolha.
Como o desenvolvimento nativo produzirá um produto de maior qualidade por padrão e será suportado quase ad infinitum, escolherei esse conjunto de ferramentas. Meus valores pessoais determinam essa escolha (busque a excelência). O desenvolvimento próprio realmente leva mais tempo (quanto mais varia). Existe uma maneira de economizar tempo? Devo economizar tempo? Devo procurar projetos onde o orçamento não é um problema?
Uma maneira de resolver o problema de economizar tempo é criar um código que possa ser reutilizado. Crie código reutilizável de alta qualidade que possa ser rapidamente integrado e implantado em vários projetos. Como escolhi um kit de ferramentas para garantir a durabilidade, posso ter certeza de que meu código reutilizável será utilizável por algum tempo.
4. Outras inferências
Por fim, tirei muitas outras conclusões antes de escolher um desenvolvimento nativo. Muitos dos quais fiz em toda a minha carreira, tentando várias ferramentas, processos e abordagens. Uma descrição de tudo isso tornaria este artigo incrivelmente volumoso. Portanto, por brevidade, darei teses de alguns deles.
Coisas que eu considerei antes de escolher um desenvolvimento nativo:
1. Hora do desenvolvedor integrado
2. Infraestrutura de suporte
3. Pipelines de CI / CD
4. O custo de apoiar projetos herdados
5. Camadas de abstração = mais espaço para erro
6. Disponibilidade de desenvolvedores (número de desenvolvedores usando a ferramenta especificada)
7. Hierarquia de negócios (o Airbnb tem uma ótima série de blogs que aborda esse tópico)
8. Dependência da plataforma em plugins
9. Felicidade do desenvolvedor ao usar a ferramenta
10. Custos de projeto: a necessidade de projetar de forma a suportar as duas plataformas
11. Estrutura personalizada do projeto
12. Recursos de conhecimento - o número de áreas de conhecimento necessárias (por exemplo, o Xamarin requer: + plataforma Xamarin Api, C #, funcionalidade específica do Android, funcionalidade específica do iOS e conhecimento dos recursos de cada plataforma e como eles interagem através do Xamarin.)
13. Licenciamento + custo
14. O cenário dos sistemas operacionais móveis. Por exemplo: quanto tempo durarão apenas duas plataformas principais?
Conclusões
Nos últimos 2 anos, ele tem usado o desenvolvimento móvel nativo como seu principal conjunto de ferramentas. Uma das muitas razões pelas quais estou feliz com minha decisão é que dediquei um tempo para considerar o máximo de sutilezas possível para cada ferramenta. Conheço os prós e os contras, e isso me dá vantagens.
Espero que este artigo o ajude a fazer as perguntas certas ao escolher uma ferramenta. Não aceite marketing pelo valor nominal, e POR FAVOR, não siga o hype. Cavar, sujar e pensar criticamente.