Usamos apps todos os dias, todas as horas, em todos os lugares. É a primeira coisa que fazemos ao acordar e a última antes de fechar os olhos. Você já parou para pensar em como eles chegam às suas mãos e tanto nos facilitam a vida?

Antes de começarmos: um aplicativo é um software, também chamado de programa de computador. Se você está lendo esse texto agora em um navegador, como o Firefox, Chrome ou Safari (Edge não, né? 😊), está usando um software. Ele só funciona porque alguém escreveu uma quantidade enorme de instruções para o computador dizendo que ele deve mostrar textos, imagens e vídeos de um endereço da internet. Essas instruções são chamadas de código-fonte ou simplesmente código.

Abstrato? Deixa eu melhorar… Imagine uma casa. Ela é feita de tijolos e cimento. Esses tijolos e cimento não podem ser colocados de qualquer jeito, senão pode ocorrer duas coisas: a) a casa cair; b) a casa não ser do jeito que você quer.

Os tijolos e cimento são a linguagem do código-fonte usada. Da mesma forma que temos vários tipos de tijolos, temos várias linguagens: Python, Java, Javascript, PHP, C#, Ruby, SQL, entre muitas outras. Quem escreve o código nessas linguagens e constrói a “casa” é o desenvolvedor ou programador.

Então, se você está usando Chrome ou Firefox, é porque vários programadores escreveram milhares de linhas de código em C++ para que você possa ler esse post, ver vídeos fofos de gatinhos no YouTube e acessar o seu e-mail. O mesmo vale para o app do Instagram, do Candy Crush e WhatsApp.

Eu não sei você, mas acho incrível que um bando de linhas de código permitam tudo isso…! 🙂

Tá, mas como um app é criado?

O processo básico do desenvolvimento de qualquer software ou aplicativo é: ideia, desenho, desenvolvimento, testes e implantação.

Ideia

Tudo começa com uma ideia. O Facebook começou desse jeito, assim como o Windows (sim, é um software, chamado de software de sistema ou sistema operacional!), o PowerPoint, o CandyCrush (já deu pra ver que adoro, né?) e o aplicativo do seu banco. Nesta fase, aparecem os primeiros layouts, as primeiras funcionalidades. Idealiza-se aqui como você quer que seu produto pareça e o que ele faça.

Desenho

A etapa de Desenho aprofunda as ideias. Você pode fazer seu próprio layout, mas geralmente entram na equipe profissionais de UX/UI (User Experience e User Interface) para prototipar seu aplicativo. Um protótipo é um modelo que permite que a equipe e os usuários enxerguem a ideia antes de ela ser desenvolvida. No exemplo da casa, é a maquete.

Um protótipo simples pode ser apenas um desenho, chamado mockup, que mostra as cores, a posição dos botões e dos conteúdos e até a navegação entre as diversas telas. Isso pode ser feito em qualquer programa gráfico, como o Photoshop ou Illustrator, ou até no PowerPoint.

Entretanto, hoje temos várias boas (e gratuitas!) ferramentas para criar protótipos navegáveis, que permitem uma simulação bem real do produto, como o Figma. Nesse modelo, pode-se experimentar o programa no próprio laptop ou celular, como se o estivesse usando. É ótimo para testar desde tamanho de fontes até navegação entre as páginas ou telas. Também usamos para ver se nosso desenho é intuitivo para o usuário. Já percebeu como usamos os aplicativos e não precisamos de manual de instruções? Parece tudo “fácil” e no lugar certo? Agradeça aos profissionais de UX/UI e à usabilidade!

Quanto mais detalhado é o protótipo, mais especificações seu aplicativo vai ganhando. E não é só sobre suas telas, ou sua interface: começa-se a desenhar também a “mágica” que acontece por trás das telas.

Exemplo simples: quando você se loga em um aplicativo de comércio eletrônico, coloca login e senha e aperta o botão enviar. Essa é a interface, também chamada de front-end.

Mas… como o app sabe que seu login existe e que sua senha é a correta? Na prática, ele envia os dados para um computador da empresa pela internet. Lá, verifica-se se seus dados estão corretos no banco de dados. Se estiverem, mandam de volta para seu app, também pela web, a mensagem “você está logado” ou algo do gênero.  

Tudo isso também precisa ser desenhado: qual é o melhor banco de dados para usarmos no app? Qual é a linguagem que mais se adequa ao que o app fará e poderá fazer no futuro? Esse conjunto é a Arquitetura de Informação do app. E tudo acontece nos bastidores do aplicativo, ou no back-end.

Desenvolvimento

Com protótipos e arquitetura desenhadas, imagine que temos a maquete e as plantas da casa. Então, é hora de chamar quem realmente vai construir as coisas: os desenvolvedores.

Existem no mercado dois perfis de desenvolvedores: os front-end que, como já vimos, vão programar a interface das telas e as interações. Você já reparou que há sites de conteúdo de mostram paginação para você ver mais itens (Google) e outras que preferem o scroll infinito (Facebook)? Coisa de desenvolvedores front-end.

Os que fazem a “mágica” acontecer são os desenvolvedores back-end e os database designers. Este último é como um programador que lida especificamente com a programação dentro do banco de dados.

Conforme os programadores vão desenvolvendo páginas e telas, vão também testando o que fazem. O ideal é termos aplicativos sem erros, certo? Mas deixar apenas os desenvolvedores testarem é um pouco como deixar a raposa tomando conta do galinheiro. Ou melhor, deixar uma galinha tomando conta do galinheiro.

Explico: quando criamos um código, estamos acostumados a ele. Sabemos o que testar, o que vai dar certo ou não. Também temos nossos vícios e manias e sempre testaremos as mesmas coisas. Então, é muito provável que, quando um usuário comum, que não conhece o sistema e tem outros vícios e manias, acessa o aplicativo, vai usar de maneira diferente da nossa. E, com isso, é possível que encontre um problema que sequer foi cogitado por nós.

Usuário são imprevisíveis!

Então, para qualquer desenvolvimento, passamos para a fase de testes.

Testes

Quem toma conta do galinheiro? Depende. Quando há recursos, contratamos uma empresa de Qualidade de Software ou simplesmente… de Testes. Há várias avaliações de qualidade. Algumas das mais conhecidas e usadas são:

1. A mais básica é o Teste Unitário, que é parecido com que o desenvolvedor fez. A diferença é que é realizado por alguém “de fora”. O objetivo é verificar se não há erros – ou bugs – no sistema.
2. O Teste Integrado é usado quando temos nosso programa interagindo com outros sistemas. Vamos supor nosso ecommerce use meios de pagamento da Visa ou da MasterCard. Temos que verificar se a conexão com essas empresas está funcionando e se a validação do pagamento está sendo feita corretamente. Às vezes, há múltiplos sistemas dentro de uma só organização. Um hospital, por exemplo, pode usar um sistema integrado de prontuário eletrônico, mas usar uma ferramenta específica para o laboratório. Então, para garantir que os resultados dos exames estejam dentro do prontuário, temos que testar essa ligação.
3. O Teste de Performance verifica se o aplicativo “aguenta o tranco”, seja por excesso de usuários ao mesmo tempo ou por aumento do uso da ferramenta. Uma coisa é termos 1.000 usuários de e-mail acessando ao mesmo tempo. Outra é termos esses 1.000 usuários enviando arquivos de 100Mb. Ele também é chamado de Teste de Stress.
4. O programa funciona, sem problemas. Mas ele serve direito para os usuários? Aqui entra o Teste Funcional que, como o nome diz, testa as funcionalidades sob o ponto de vista da organização, do processo. É muito comum termos projetos em que a fase de design é feita de forma leviana: o usuário não sabe o que quer, o desenvolvedor não sabe perguntar e ninguém consegue desenhar. Aí o programador sai fazendo o que entendeu. Mas ele não conhece o processo, nunca pôs a mão na massa nas atividades do usuário. Quando a ferramenta chega para o usuário conhecer, não “era assim que eu queria”.

Antigamente, todos esses testes eram feitos de forma manual. Se eu quisesse fazer um teste unitário, contratava testadores ou convocava usuários e dava scripts de teste para eles realizarem. Hoje, muitas das atividades de teste são automatizadas por programas/sites como JUnit, Mocha e JMeter.

Quando uma tela ou funcionalidade não passa nos testes, volta para o desenvolvedor, que corrige o problema e envia novamente para ser testado.

Implantação

Tudo testado? Agora é a vez da Implantação (e não implementação, tá? 😊). É a hora de colocar no ar.

Imagine que você vai morar na casa. E leva o fogão. Mas não conferiu se o gás estava ligado ou se havia um botijão. Aliás, você pode muito bem ter levado um fogão com ligação para botijão quando a casa tem gás encanado. É o processo de implantação que cuida disso.

Em muitos projetos e organizações, é a equipe de Operações de TI. O nome é conhecido para quem já ouviu em DevOps (é o Ops, que conversa com o Dev, ous os desenvolvedores).

Após todos os testes liberados, essa equipe tem que verificar algumas coisas antes de instalar nos servidores o que vai ser implantado e liberado para os usuários:

1. O código dos desenvolvedores está ligado aos servidores? Os testadores realizam seus testes com uma base de dados… de teste! (Três pratos de trigo para três tigres! 😊) Então, o código dos desenvolvedores, quando foi para o teste, “chamava” essa base. Agora que vai para a produção, não pode mais usar os dados de teste! Para óbvio, mas esquecer isso não é tão difícil assim.
2. Temos todas as dependências? É o caso do fogão… A esmagadora maioria dos sites ou aplicativos que geram algum documento em pdf, como boletos e relatórios, usam uma ferramenta externa para isso. Por quê? Para não “inventar a roda”. Queremos gerar boleto, não ter que criar pdf do zero! Usamos nestes casos as chamadas bibliotecas. O desenvolvedor instalou a biblioteca de pdf na máquina dele. O pessoal de testes também. E na produção? Alguém lembrou disso?
3. Essas novas implantações terão impacto em escala? O Teste de Performance já trouxe informações sobre isso, mas a equipe de Operações deve reavaliar se o servidor real de produção aguenta as novas funcionalidades e as novas transações.

Esse é o processo básico de desenvolvimento de qualquer aplicativo ou software. Teremos algumas “customizações” quando tratamos de Metodologias Ágeis, DevOps e DI/DC, mas isso é papo para outro post.

Alguns podem “reclamar” que esse processo é o Waterfall e não o Ágil… Mas, na prática, mesmo no Ágil, a primeira release ou versão, é feita por este processo. Mas isso também fica para outro post!