Desenvolvimento

Dicas para lançar um aplicativo de sucesso

Os aplicativos tem ganhado cada vez mais espaço na vida das pessoas. A partir deles fazemos desde tarefas mais simples como olhar a previsão do tempo, como também conseguimos pedir um delivery, marcar uma consulta, jogar, estudar e mais uma infinidade de coisas.

Provavelmente você já teve alguma ideia para algum aplicativo, mas ficou sem saber até mesmo como começar. Realmente, o desenvolvimento de aplicativos é um processo que engloba muitas etapas e demanda tempo e conhecimento. Por isso, neste artigo vamos dar algumas dicas do que você tem que pensar e fazer antes de lançar um aplicativo.

Pesquise muito antes de iniciar

Essas pesquisas são importantes antes de iniciar o processo, pois senão, no final você poderá ver que o que foi desenvolvido não era uma necessidade do seu público e consequentemente, ele não será utilizado/vendido. Por isso, devemos fazer uma pesquisa a fundo nos seguintes itens:

Ideia – Pesquise se alguém já teve a mesma ideia que você, se tem algum aplicativo parecido. Se sim, como você pode melhorar essa ideia?
Público-alvo – Esse é um fator muito importante pois, sem eles, seu aplicativo não terá uso. Pesquise mais sobre quem será seu público. O que seu aplicativo terá que fará com que eles baixem? O que eles buscam que seu aplicativo vai atender?
Mercado – Pesquise sobre o mercado. Está pensando em um aplicativo, mas tem vários desse segmento? Será que valerá a pena? Ou você tem um super diferencial para oferecer? Como você vai fazer para que ele traga a rentabilidade que você espera?
Tecnologias – Pesquise sobre as tecnologias e ferramentas que você irá utilizar, estude qual atenderá mais suas necessidades.

Outro ponto que devemos pensar antes do desenvolvimento do aplicativo, é se ele será híbrido ou nativo. Temos um artigo que explica exatamente sobre cada um deles e sobre um ponto importante: App Nativo x App Híbrido: existe o melhor?

Não se esqueça do protótipo

Quando pensamos em um aplicativo, já queremos ir logo para a parte de desenvolvimento em si, até mesmo porque ficamos ansiosos querendo já ver algo rodando na nossa frente. Porém, devemos tirar um tempo antes disso para pensar em como será o layout do app, pensar na usabilidade e na identidade visual. Quando você faz um planejamento de como ele irá ficar, você consegue pensar mais a fundo na melhor forma ou técnica de fazer aquilo. Além de evitar muitas mudanças no design lá na frente, evitando retrabalhos. Além disso, junto com o layout você trabalhará também em outras questões, como por exemplo quantas telas terá, como funcionará cada tela, etc.

Se atente a experiência do usuário

A experiência do usuário no seu aplicativo tem que ser a melhor possível. Você deve dar a devida importância nesse quesito, criando um aplicativo que seja atraente, fácil de ser utilizado e que instigue as pessoas a se manterem nele. Outro ponto importante é evitar ao máximo os bugs. Afinal, ninguém gosta de baixar algo que está cheio de bugs, não é? E eles são sempre mencionados pelos usuários nas lojas oficiais, como App Store e Play Store, fazendo com que seu aplicativo fique com uma nota baixa.

Como é muito comum usuários baixarem aplicativos e minutos depois já desinstalarem, vale muito a pena se atentar nessa primeira impressão.

Campanha de marketing

Como vimos, sem usuários seu aplicativo não tem utilidade. Então você deve começar uma campanha de marketing antes mesmo de lançar o aplicativo. Assim você consegue ir construindo uma marca e ir atraindo o seu público ao lançamento. Você pode fazer um bom uso das redes sociais sem gastar muito, utilizando o Facebook e Instagram por exemplo. Isso é ótimo para atrair seu público, além de você ficar mais próximo deles, criando um bom relacionamento.

Testes e mais testes…

Além de manter uma rotina no desenvolvimento para que o aplicativo saia do papel e chegue ao produto final, é importante sempre estar fazendo testes para que possíveis erros sejam corrigidos antes do lançamento, minimizando assim as chances deles chegarem ao usuário.

Concluindo

Sabemos que não basta somente desenvolver o aplicativo e deixar ele lá – até mesmo porque sozinho ele não vai gerar $$. Como vimos neste artigo, precisamos ter um diferencial, precisamos proporcionar um atendimento legal para os usuários e sempre estar aprimorando o nosso produto, para que nosso aplicativo seja bem utilizado por muitas pessoas.

Caso você esteja com dúvidas quanto ao desenvolvimento, temos diversos cursos voltados ao desenvolvimento mobile. Dá uma conferida 🙂

Paralisia por Análise – o bloqueio que te impede de começar

Olá Web Developers!
Você possui algum projeto ou plano mas nunca inicia ou finaliza por estar sempre pensando demais? Você pode estar com a Paralisia por Análise.

O que é Paralisia por Análise?

Paralisia por Análise é quando não conseguimos chegar em nenhum lugar por pensarmos em excesso.
Isso pode pode acontecer tanto na vida profissional quanto na pessoal, e está cada vez mais comum em um mundo conectado e que nos oferece várias opções para um mesmo objetivo.

Por que isso acontece?

Há muitos motivos para a Paralisia por Análise.

Um dos motivos mais comuns é o excesso de opções. Você fica pensando em qual a melhor escolha, e por querer algo perfeito acaba não escolhendo e gastando todo o seu tempo apenas analisando as opções.
Quantas pessoas você conhece que dizem ficar horas tentando escolher um filme ou série na Netflix e acabam não assistindo nada?

Outro motivo também muito comum que pode contribuir para este fenômeno é o medo de algo: de mudanças, do desconhecido, de falhar, de passar vergonha, etc. E então você começa a treinar, pesquisar e fazer várias coisas para poder traçar o plano perfeito. O resultado é que esse plano acaba nunca sendo iniciado ou concluído, pois nunca é o suficiente.

Também podemos citar o perfeccionismo. Muito comum em entrevistas a pessoa falar “meu pior defeito é ser perfeccionista”. Esse candidato normalmente nem faz ideia que realmente ser perfeccionista pode mesmo ser muito prejudicial.

Um motivo que também vejo muitos colegas cometendo é ficar pensando: “e se eu escolher e me arrepender? E se depois eu ficar pensando como poderia ter sido com a outra opção?”.

Exemplos comuns

Opções, muitas opções

Um exemplo muito comum na vida pessoal é o citado acima: a Netflix disponibiliza várias opções de filmes e séries. Se ficarmos pensando muito, gastaremos todo o nosso tempo livre e não aproveitaremos para assistir nada. Antes dos serviços de streaming, ao passar um filme na televisão, tínhamos apenas duas opções: sim ou não.

Em serviços de entrega como ifood também é muito comum as pessoas ficarem muito tempo escolhendo em meio a tantas opções. Antigamente você basicamente telefonaria para a pizzaria que você tivesse o número anotado na agenda.

Então o excesso de opções é algo que vem crescendo com a tecnologia. É óbvio que ter opções é ótimo, mas nem todos estão preparados para tomar decisões rapidamente.

Inclusive, reduzir opções foi uma das estratégias da Apple em uma época em que ela estava quase indo à falência. Basta comparar quantas opções temos de iPhone em relação aos modelos de smartphones de outras marcas.

Medo e insegurança e perfeccionismo

Já na parte dos medos, isso pode se relacionar com o perfeccionismo também. E sabemos que “feito é melhor do que perfeito”.

É muito comum vermos projetos que nunca lançam uma versão final do produto. Sempre tem algo a melhorar antes de mostrar para algum potencial cliente.

Também já vi casos de programadores mais novos produzindo mais do que programadores mais experientes em projetos próprios. Isso parece meio estranho, mas veja o motivo:

Programador Iniciante

O programador iniciante ainda não conhece muitas ferramentas. Se ele precisar fazer algo, ele vai tentar fazer com o pouco que sabe com a única linguagem de programação que ele sabe mexer. Ele provavelmente não seguirá boas práticas, o código pode não estar tão bem organizado, muitas coisas podem acabar tendo sido feitas manualmente e haverá várias outras coisas que podem dar problemas no futuro por falta de planejamento e experiência. Porém, ele foi lá com o pouco que sabia e fez, entregando algum resultado.

Programador Experiente

Já alguns programadores mais experientes vão começar analisando o problema para escolher a melhor linguagem de programação a ser usada. Definido isso, qual dos diversos frameworks que ele conhece será o que entregará mais produtividade, robustes e segurança? Será que esse framework possui uma boa comunidade e é simples de atualizar de versão?
E qual será o banco de dados? Onde iremos hospedar? Qual a melhor estrutura para meus dados que me permita escalonar meu sistema sem problemas? Será que os requisitos foram bem capturados e não está faltando nada? Será que a estrutura da minha tela está bonita e entrega a melhor experiência ao usuário de forma intuitiva?

Só essas perguntas podem fazer uma pessoa gastar meses e ainda nem começar a escrever uma única linha de código. Se o desenvolvimento começar, essa pessoa pode aprender coisas novas e pensar em refazer partes de seu sistema por achar que ele pode ser melhor, mesmo que ele ainda nem tenha terminado de entregar o básico que o sistema deve propor. E assim uma ideia basicamente nunca será finalizada.

Obviamente que nestes casos iremos preferir algo feito por um amador, mas que resolva nosso problema, do que algo feito por uma pessoa bem mais experiente mas que ainda só tem o projeto na cabeça dele e ainda não dá para usar.

Como se livrar?

Há algumas coisas que podemos fazer para evitar ou pelo menos diminuir a Paralisia por Análise.

Primeiro precisamos sempre lembrar que não há solução e nem momento perfeito. O momento sempre é agora e a solução que você escolher pode ser arrumada no futuro, ela não é uma escolha para o resto da vida.

Limite o número de suas opções para o mínimo possível.
Defina um objetivo com um prazo. Se chegar o prazo e você decidir que todas as opções são boas, não fará diferença qual escolher, então jogue um dado ou uma moeda e siga em frente sem questionar!
Algo para treinar tomar decisões rápidas é evitar responder para as pessoas “você que sabe”, “você decide”, “para mim tanto faz”, etc. Se te perguntaram é porque estão te dando permissão para escolher.

É ótimo ser curioso, mas contenha-se para não acabar descobrindo pequenas imperfeições que no final não fazem diferença no resultado de seu objetivo.

Planeje tudo em pequenas metas e dê um passo de cada vez.

Tomar muitas decisões também causa um cansaço. Então diminua a quantidade de decisões que você precisa tomar durante o dia (não precisa chegar a ser como Steve Jobs e Mark Zuckerberg que usavam/usam sempre roupas iguais para evitar escolher roupa) e sempre comece pelas decisões mais importantes.

Conclusão

Então, a Paralisia por Análise acaba acontecendo quando o nosso excesso de pensar vai além dos benefícios que teríamos caso tivéssemos feito uma escolha mais rapidamente.
Se você está tendo esse tipo de problema, tente seguir as dicas aqui para se livrar o quanto antes e veja sua vida mudar.

Você tem ou já teve algum bloqueio assim? Compartilhe com a gente nos comentários!

O que é uma API?

Você já deve ter ouvido falar, pelo menos alguma vez, sobre esse termo chamado “API” e pode ter pensado o que realmente vem a ser uma API e como ela pode ajudar os desenvolvedores no seu trabalho do dia a dia. Vamos ver então neste artigo o que vem a ser uma API.

Uma API (Application Programming Interface) pode ser definida como um conjunto de padrões que permite a construção de aplicativos, onde ele conecta aplicações, podendo ser utilizada nos mais variados tipos de negócios.

Apesar de ter essa integração, quando um usuário estiver navegando em um site que tem uma integração com uma API por exemplo, nem saberá que sua aplicação está fazendo uma comunicação com uma API, pois ela é invisível ao usuário comum, já que ele enxerga apenas a interface dos softwares e aplicativos.

Com a API você tem uma interface para que um sistema se comunique com outro sistema, compartilhando suas ações e ferramentas. A comunicação é feita através de vários códigos, definindo comportamentos específicos.

Além de conectar sistemas, elas têm um papel muito importante na criação de aplicativos porque nos ajudam muito na produtividade. Você mesmo com certeza já acessou um site onde tinha uma integração com uma API. Vou te explicar melhor com dois exemplos.

Imagine que você está navegando por um site para a compra de um produto. Depois de escolher, você deseja saber quanto isso custará para chegar até o seu endereço e quais são as opções de envio (PAC, SEDEX, etc) e o tempo estimado. Quando você digita o seu CEP para esse cálculo de frete, o site está utilizando provavelmente uma API dos Correios. Isso também vale na hora de efetuar o pagamento, caso o site também aceite PayPal ou o PagSeguro, por exemplo. A transação financeira acaba sendo por meios dessas APIS e diretamente com o site do meio de pagamento. Ou seja, a integração desses sistemas e os sites que utilizamos como exemplo, se dão por meio de uma API.

Outro exemplo é a API do Google Maps. Se você está num site procurando um hotel, já deve ter percebido que aparece um mapa do Google Maps indicando onde é o local exatamente, e através deste mapa você consegue até mesmo navegar por ele.

Muitas pessoas podem confundir uma API com um outro termo muito falado ultimamente, que são os endpoints. Um endpoint é basicamente o que um serviço expõe e esse serviço pode ser acessado por uma aplicação, por isso muitas vezes acaba sendo confundido com uma API, mas vale ressaltar que não é.
Um endpoint contém três principais características: Address (onde o serviço está hospedado), Binding (como o serviço pode ser acessado) e Contract (o que tem no serviço). Além disso, uma API pode existir sem um endpoint e vice-versa.

É seguro utilizar uma API?

As APIs são muito úteis e tem diversos benefícios, além disso proporciona uma troca de informações muito segura, já que somente o proprietário da aplicação define quais informações estarão disponíveis. Você pode e deve utilizar uma API quando necessário, mas sempre visando pontos importantes de segurança.

É importante utilizar SSL nas conexões das APIS, assim toda a comunicação e dados enviados pelas APIS serão transportados criptografados pelo HTTPS. A autenticação também é importante para isolar o que pode ser fornecido de informação para cada um dos softwares que chama a API. Um exemplo são os tokens, que são validados como se fossem uma senha, pois são identificadores únicos que são enviados juntos das chamadas aos endpoints das APIs.

Para levar as informações de um lado para o outro, geralmente é utilizado o JSON, muito utilizado para retornar os dados das APIS baseadas em web. Além disso, esse conceito ocupa pouco espaço e é fácil de transportar via rede.

Apesar de estarmos falando o tempo todo de APIs mais voltadas para web, uma API não necessariamente é utilizada via web. Quem desenvolve softwares desktop pra Windows também pode utilizar APIS, como por exemplo utilizar as APIs do sistema operacional.

Depois que você tiver mais experiência além de consumir APIS de outras pessoas ou empresas, você pode construir as suas próprias, assim você pode utilizar em diversos outros projetos, poupar tempo e até mesmo disponibilizá-las para outras pessoas usarem.

O que define um desenvolvedor como júnior, pleno ou sênior?

Em algum momento da sua carreira você já deve ter pensado: em qual nível será que me encaixo? Será que ainda sou júnior ou já posso ser considerado pleno? Essas dúvidas costumam aparecer ainda mais na hora de elaborar um currículo ou de se candidatar para uma determinada vaga…

Neste artigo iremos abordar exatamente essa questão: quais são geralmente as diferenças entre os níveis de carreira júnior, pleno e sênior. Sim, falamos geralmente porque não existe uma regra específica, ela varia de empresa pra empresa, podendo variar de uma para outra.

Todo desenvolvedor deseja chegar ao ponto máximo de sua profissão, ser expert naquilo que faz. No caso, chegar ao nível sênior é o ápice de carreira pra muita gente. Mas o que determina um profissional sênior? Isso tem muito a ver com o tempo de experiência, mas não somente isso, pois a determinação desses níveis acabam sendo um mix de complexidade de tarefas e maturidade profissional. Sendo assim, vamos passar por cada um desses níveis para que possamos entender melhor.

Nível Júnior

Esse é o primeiro nível. Aqui o profissional pode ser um recém-formado na faculdade ou um profissional que ainda viveu pequenas experiências. Ele terá tarefas com uma complexidade menor, ou seja, tarefas mais básicas, sem tantas exigências. Além disso sempre terá algum outro profissional que irá coordená-lo, dando os direcionamentos, explicando, revisando suas tarefas, para que ele possa ir aprendendo e crescendo na sua área.
Em média, um profissional considerado nível júnior tem até 5 anos de experiência.

Nível Pleno

Aqui esse profissional já tem uma experiência mais significativa e geralmente acumula em média mais de 5 anos na mesma área, assim ele consegue tomar decisões mais estratégicas e conhece mais profissionalmente sua área de atuação. É um profissional mais confiante, porém ainda conta com um supervisor para auxiliá-lo, geralmente um profissional nível sênior. No quesito de formação, ele já é pelo menos um pós-graduado.

Nível Sênior

Esse profissional tem 10 ou mais anos de experiência e terá mais participações em reuniões importantes com coordenadores e diretorias, além de receber mais atividades que exigem mais experiência profissional. Muito provavelmente quem chega a esse nível tem mais possibilidade de se tornar um coordenador, um líder dentro da empresa, por isso é interessante a pessoa se desenvolver como profissional, aprendendo um pouco da área de gestão seja por cursos, MBA… para que consiga gerir bem uma equipe, lidar com os projetos, prazos… ou seja, para chegar a esse nível o profissional deve se preparar para esses tipos de atividades também.

Concluindo

Apesar do tempo de experiência contar bastante, você não pode ser um profissional estagnado, você deve progredir e evoluir junto com a tecnologia em que trabalha. Por isso nunca se deve abrir mão do estudo, você deve se especializar e se atualizar para ter essa progressão de carreira. E é claro, quanto maior a posição nessa escala crescente, maior a complexidade de tarefas, responsabilidades e, consequentemente, melhor será a remuneração.

Aqui vai uma observação: muitas vezes observamos essas nomenclaturas quando vamos procurar por determinadas vagas, como por exemplo “Desenvolvedor Java Pleno”. Mas vale lembrar novamente que esse nível varia de uma empresa para outra. Você não deve se prender tanto a isso, mesmo se você for um desenvolvedor Java júnior, deve se atentar também aos requisitos da vaga e ao que ela pede, o que pode ser pleno para uma empresa, pode não ser para outra. Se atente aos requisitos e se estiver apto, pode tentar sem problemas =)

Até a próxima!

Como quintuplicar a produtividade no desenvolvimento de software?

Desenvolvimento de software é algo complexo, mesmo para quem está desenvolvendo. É algo que, durante o processo de encontrar sua melhor maneira de ser produtivo, você acaba se debatendo com suas próprias escolhas.

Existem muitas maneiras de se definir o que é um software, mas particularmente eu gosto dessa: um software é uma sequência de instruções escritas por um programador, para executar uma ou mais funções, otimizando assim algo que previamente era manual ou não existia.

Veja, se grande parte do meu trabalho como desenvolvedor é otimizar processos, a minha rotina de trabalho também costuma ser como um protótipo de software.

Isso se transforma em uma rotina estruturada, ou, ao menos, uma maneira estruturada de como resolver um problema. Vou contar um pouco do meu processo de construção de software/trabalho e como desenvolvi hacks para ser mais produtivo ao longo do tempo.

Vou contar um pouco da minha experiência para tentar ajudá-lo(a) a otimizar a sua. Vamos lá!

Comece de maneira gradual

Dificilmente consigo acordar e codar alguma coisa. Normalmente eu preciso que meu cérebro ligue os motores de maneira processual, um passo de cada vez.

No entanto, penso que isso não pode ser um processo que leva várias horas, então eu tomo um caminho gradual, mas rápido, para que esse processo ocorra.

Ao abrir minha máquina para programar eu começo geralmente pela leitura dos meus cards do Trello, nosso reservatório de tasks infinito onde sempre pode se tirar algo da cartola. Eu uso Trello, mas essa dinâmica aplica-se a qualquer ferramenta de gestão de projetos.

A leitura me ajuda a pensar nas tasks que vão ser executadas no dia. É um processo rápido. Ao ler rapidamente os títulos dos cards eu já sei o que devo fazer, quando fazer e como fazer, em sua grande maioria.

Após isso eu começo pelas tasks mais simples, coisas que são rápidas, mas me farão emergir no processo de pensar em software.

Um exemplo disso é executar alguns scripts para transferir dados de usuários, dar update em alguma informação no banco, ou refatorar algum trecho simples de código.

Leitura recomendada:
Por que a comunicação em TI é um negócio tão importante?

Coding Hard

É hora de codar. Mas como saber no que eu começo primeiro?

Para executar as tasks mais complexas, eu as separo em 2 tipos:

  1. As que são relativamente rápidas e as que são de longo prazo. As tasks complexas são aquelas que envolvem mais de uma parte do sistema, que têm alto impacto, em que é preciso prever muitas coisas antes de se começar a executar;

  2. Normalmente minha prioridade começa com as tasks que posso fazer em 1-2 horas. Elas permitem imprimir ritmo no desenvolvimento e fazem com que minha cabeça entre no modo foco.

Durante esse período normalmente não respondo e-mails, não olho o Slack, não faço nada que me faça perder a linha de pensamento. O porquê disso é simples, vamos imaginar a seguinte situação:

2.1 Usuário vai entrar na tela de login e nesse momento informo ao banco que ele está ativo
2.2 O banco guarda essa informação e ativa uma trigger para que daqui a 30 minutos um alerta seja enviado a esse usuário
2.3 Se o usuário entrou na tela 1 o alerta será x. Se entrou na tela 2 o alerta será Y, mas apenas depois de 30 minutos
2.4 Caso o usuário entre na tela 3 o tempo de alerta deve ser reduzido para 15 minutos

Pronto.

Imagine que pensei nas linhas gerais de como a task vai ser feita e, quando estou no meio da segunda instrução, paro para responder e-mails ou fazer outras coisas. O que ocorre?

Posso simplesmente esquecer que já fiz algo ou deixei de fazer algo. Por isso manter uma linha única de pensamento é importante quando estamos codando.

É preciso se ter em mente o tempo todo os passos que foram ou não executados. Caso você esqueça onde estava, todo o ciclo recomeça. “Será que setei o tempo certo na tela 1? Fiz o tempo de maneira diferente para a tela 3?” E então começa um processo de revisão da sua linha de pensamento.

Para se produzir as tasks de longo prazo é necessário quebrá-las em pequenas etapas, dificilmente é possível ficar 8 horas ininterruptas desenvolvendo. Bugs surgem, pessoas falam com você, outras tasks são priorizadas e por aí vai.

Por isso é um processo que exige a quebra. Exige que você determine quando cada etapa será executada para que diariamente você progrida dentro da task.

Leitura recomendada:
Como se destacar na carreira de TI?

As pausa são importantes para a produtividade

Algo que já vi ser bem comum entre programadores — talvez seja para outras áreas também — é o tempo necessário para “resetar” o cérebro.

Ao finalizar tasks complexas, onde você levou sua mente a pensar na otimização de um processo específico, normalmente você precisa “não pensar” durante algum tempo.

O que quero dizer com isso? Se pensei na otimização de um processo de candidatos dificilmente é possível, no instante seguinte, pensar em um código para empresas.

Isso porque a mente está “contaminada”, pensando ainda em otimizações e melhorias do processo que você acabou de criar.

É preciso esvaziar a mente antes de colocar outra idéia no forno para iniciar um novo processo de desenvolvimento, por isto as pausas entre uma task e outra são importantes.

Leitura recomendada:
As certificações para programadores mais importantes do mercado.

Afinal, como ser produtivo(a) no Desenvolvimento de Software?

E quando acaba essa sequência “colocar” coisas na caixa, “tirar” da caixa, “descansar”, “colocar” outro no lugar? Para a maioria dos Desenvolvedores que conheço a resposta é nunca.

Ao se deparar com problemas, normalmente eles são jogados em processos de background na sua mente e ficam produzindo idéias de maneira passiva.

Acredito que muitos Desenvolvedores — senão todos — já se depararam com uma idéia no meio da noite, acordaram e escreveram um trecho de código.

Ou já teve uma elucubração no meio da mesa do jantar, ou enquanto estava vendo sua série da Netflix.

Acredito que esse processo de nunca parar de pensar sobre os problemas técnicos ou sobre software em longo prazo é danos.

Talvez fique aqui a minha hipótese do porquê tantos Desenvolvedores curtem tanto fazer algo fora do serviço que atraia 100% do foco.

Como jogar algo ou estar imerso dentro de uma série.

Esse tipo de atividade simplesmente força sua mente a se desligar do mundo do software e é essencial para resetar sua mente e dar tempo para você ter novas idéias de maneira fresca e descansada.

Esse era um pouco do meu ciclo enquanto era 100% Desenvolvedor dentro da GeekHunter.

Hoje, assumindo a área de gestão, esse fluxo mudou um pouco, porém a essência ainda é a mesma.

Cada Desenvolvedor tem sua particularidade na hora de programar, mas acredito que existam muitas similaridades entre todos quando se trata do nível de foco necessário para desenvolver.

Espero ter ajudado. Até a próxima!

Esse post foi desenvolvido pela GeekHunter

Para que serve um framework?

A utilização de frameworks já está inclusa no dia a dia de muitos desenvolvedores. O principal benefício que faz muitos desenvolvedores utilizarem frameworks é o poder de reutilização de estruturas de código, poupando horas de desenvolvimento e fazendo com que os desenvolvedores possam focar no que é de fato importante e que agrega valor ao negócio com relação ao software que está sendo desenvolvido.

O que vem a ser um framework?

Um framework é uma estrutura-base que contém um conjunto de funções e componentes pré-definidos, funções e componentes estes que se relacionam para disponibilizar funcionalidades específicas ao desenvolvimento de software. Estas funções e componentes genéricos pré-prontos agilizam o processo, poupam tempo e evitam retrabalho para o desenvolvedor.

Os frameworks podem ser criados ou pela própria comunidade ou por empresas mantenedoras de uma linguagem ou ambiente de desenvolvimento, como a Microsoft e a Oracle.

Por que utilizar um framework?

O foco principal de um framework é a reusabilidade. Você pode utilizar um framework para desenvolver várias aplicações, reaproveitando estas estruturas pré-disponibilizadas para lidar com tarefas repetitivas ou que são comuns em vários tipos de sistemas (como, por exemplo, a funcionalidade de autenticação). Nesse exemplo, você não precisa dedicar tempo para desenvolver a funcionalidade de login, já que existem frameworks já testados para essa finalidade. Além disso, se necessário, você pode personalizar estes componentes pré-disponibilizados de acordo com as demandas do projeto em questão.

Um exemplo: a Microsoft tem o .NET Framework, que disponibiliza componentes pré-configurados para rodar aplicativos em diferentes plataformas. Se você vai criar uma aplicação web, por exemplo, você não precisa desenvolver toda a estrutura necessária para lidar com requisições HTTP (que é uma tarefa repetitiva): basta você criar uma classe que estenda a clases Controller e… Pronto! Você já tem automaticamente uma classe que consegue lidar com requisições HTTP.

Existem diversos frameworks para as mais diferentes linguagens e plataformas, seja desktop, web ou mobile, tanto com relação ao front-end quanto ao back-end. Devemos escolher os frameworks corretos para cada tipo da aplicação, para que ele realmente ajude no objetivo final.

Ao final, podemos concluir que um framework é um facilitador para o desenvolvedor chegar no resultado final que ele deseja – que é o desenvolvimento de uma aplicação, poupando tempo e esforço de desenvolvimento.

Dicas para manter seu código limpo e legível

Atualmente, o mercado exige que os desenvolvedores não “programem” simplesmente. Muitas empresas desejam profissionais que possuem domínio de boas práticas e noções de arquitetura – o famoso “código limpo”. Muitas vezes, podemos até pensar: “não… as empresas desejam apenas que o software funcione”. A curto prazo pode até ser real esta afirmação, mas quando falamos sobre médio e longo prazo, que é quando certos problemas começam a aparecer, é que os débitos técnicos (os trechos de código que foram mal escritos ou funcionalidades que não foram implementadas da maneira correta) voltam para nos assombrar.

O famoso “código limpo” (ou “clean code”) é um estilo de desenvolvimento que tem como foco a escrita de código claro, conciso e de fácil manutenção posterior. Profissionais que se atentam a essas práticas costumam ser vistos de maneira diferente quando seu código é analisado em uma entrevista de emprego. Ter o código limpo e bem escrito facilita a leitura e é importante para o aumento da qualidade do software. Se você não se preocupa com isso, fatalmente, até mesmo em um curto prazo, você mesmo pode não entender seu próprio código! A situação piora ainda mais quando um desenvolvedor vai tentar entender o código de outra pessoa, ainda mais se for em uma empresa que tenha alta rotatividade na equipe (o que é uma situação bem comum nas empresas de software aqui no Brasil). As consequências desse tipo de situação são claras: perde-se muito tempo com a manutenção do software, gerando muitas vezes até mesmo situações de retrabalho.

A adoção de práticas de “clean code” acaba auxiliando a resolver estes pontos. Porém, ainda podemos obter outros benefícios através da adoção destas práticas: mais do que garantir a qualidade do código e do software, a adoção de práticas de “código limpo” trazem também maior produtividade, por consequência direta ao fato de que um software com qualidade exige menos processos de manutenção e, quando esta é necessária, o esforço a ser realizado acaba se tornando muito menor do que o usual.
Abaixo, descrevemos alguns tópicos comuns no que diz respeito ao “clean code”.

Escreva métodos curtos

Um método deve ser escrito de uma forma que qualquer pessoa que “bata o olho” entenda o que ele faz. Métodos demasiadamente extensos certamente não ajudam neste ponto. Alguns livros de arquitetura de software pregam que um método deve ter no máximo 15 linhas, embora até 25 linhas seja tolerável, caso seja muito necessário.

Utilize nomes de variáveis e métodos claros e bem definidos

Os nomes de variáveis e métodos devem ser precisos, claros e diretos, passando diretamente a ideia do que ele faz. Não tenha medo de escrever um nome grande caso seja necessário. Um nome bem descritivo irá possibilitar uma melhor compreensão e, posteriormente, uma melhor manutenção do código. Antes termos uma variável chamada valorTotalNotaFiscal do que valTot. A grande maioria das ferramentas de desenvolvimento hoje em dia oferecem a funcionalidade de autocomplete, o que invalida a justificativa de que “perdemos tempo ao digitar nomes de variáveis e métodos muito grandes” para não utilizarmos nomes mais diretos para nossas estruturas de código.
Vale lembrar que nomes de métodos sempre deve ter nomes de verbos, já que são criados para executar algum procedimento. No caso de classes, deve-se usar substantivos no singular.

Separação clara de responsabilidades entre métodos e classes (Single Responsability Principle – SRP)

Um método deve desempenhar apenas uma tarefa. O Single Responsability Principle, ou Princípio da Responsabilidade Única, é um de cinco princípios para utilização de boas práticas de codificação chamados S.O.L.I.D. Este princípio define que cada estrutura de código, seja uma classe ou um método, deve possuir apenas uma única responsabilidade, ou seja: cada estrutura deve fazer uma única coisa.
Tome cuidado também com a justificativa de uma classe. Os métodos existentes de uma classe devem estar alinhados com sua definição. Não adianta colocarmos um método chamado acelerar() dentro de uma classe chamada Mesa, sendo que quem acelera é um Carro.

Cuidado com a quantidade de parâmetros que os métodos recebem!

Quanto menos parâmetros um método receber, mais legível ele será. Sempre garanta que os parâmetros que um método recebe são de fato necessários. Quando uma quantidade muito grande de parâmetros for necessária, tente utilizar design patterns como o builder ou, pelo menos, agrupar esta quantidade de parâmetros em uma especificação de objeto a ser repassado como parâmetro único para o método.

Cuidado com o overpattern!

Design patterns são legais, desde que utilizados da maneira correta. Quando os design patterns são aplicados da maneira incorreta ou utilizados em conjunto de maneira complicada por pura “satisfação técnica pessoal”, estes acabam mais atrapalhando do que ajudando, já que a utilização de design patterns acaba por trazer uma certa complexidade ao código. Por isso, para evitarmos futuros débitos técnicos, é essencial que essa complexidade oriunda com a aplicação de um ou mais patterns seja devidamente justificada.

Para avaliar se você deve aplicar ou não um conjunto de design patterns, lembre-se sempre de um princípio chamado K.I.S.S. – Keep It Short and Simple, ou Mantenha Isso Pequeno e Simples (ainda existem algumas variações sob essa sigla). Sempre escreva suas estruturas de código da maneira mais direta e simples, aplicando simplesmente os patterns que são de fato necessários para a situação. Não crie débitos técnicos desnecessários por sofrer antecipadamente: escreva trechos de código claros e concisos que, quando necessário, possam ser modificados para estruturas e patterns mais complexos de maneira tranquila.

Entre um desenvolvedor que sai aplicando técnicas como DDD, CQRS, Event Sourcing e uma variedade de patterns gigantesca para um simples cadastro de uma entidade que nem tem relacionamentos e um desenvolvedor que utiliza patterns mais simples como o Repository e o Service Pattern, pode ter certeza que o mercado de maneira geral irá dar a preferência para o segundo desenvolvedor. E isso não o define com menos habilidades técnicas que o primeiro desenvolvedor – muito pelo contrário: o segundo desenvolvedor provavelmente possui um nível de maturidade maior que o permite calcular bem os benefícios de cada abordagem em diferentes situações.

Afinal: o que é de fato o LINQ?

Certamente, uma das features mais interessantes e legais que o .NET e seu ecossistema oferece é o LINQ. LINQ é um acrônimo para Language Integrated Query, ou Consulta Integrada à Linguagem . Trata-se de um “framework” dentro do .NET destinado a auxiliar os desenvolvedores a escrever expressões de consulta diretamente em C# de maneira agnóstica.

Mas o que exatamente é o LINQ?

Para entender melhor: pense nas seguintes hipóteses dentro de um software:

  • Se o software em questão precisar realizar consultas em um banco de dados relacional, provavelmente será necessário escrever consultas SQL;
  • Se o software em questão precisar realizar consultas em um arquivo XML, provavelmente será necessário utilizar expressões XPath e/ou XQuery;
  • Se o software em questão precisar realizar consultas em coleções de objetos, provavelmente será necessário utilizar blocos de código com a linguagem na qual o software está sendo desenvolvido.

Essa complexidade é adicionada pelo fato de estarmos tratando de fontes de dados heterogêneas de dados, cada qual com suas linguagens de manipulação específicas. Ou seja: se seu software se conecta a uma base de dados relacional e manipula objetos, você provavelmente precisará desenvolver e dar manutenção em pelo menos três linguagens diferentes: SQL, XPath (ou XQuery) e a linguagem utilizada para desenvolver a aplicação em si.
O LINQ tem como objetivo justamente remover essa complexidade, pois ele abstrai a complexidade envolvida na utilização de diferentes linguagens de consulta, como SQL, xPath e xQuery. Essa abstração é feita em cima de uma API de alto nível compatível com as linguagens integrantes do .NET Framework. Ou seja: você consegue consultar uma base de dados relacional, um arquivo XML uma coleção de objetos através de uma API unificada, invocada através de uma linguagem integrante do .NET Framework. Trazendo para um exemplo mais palpável: você consegue unicamente com código C# fazer consultas a conjuntos de objetos, bases de dados relacionais e arquivos XML, sendo o LINQ o encarregado de fazer a devida “tradução” para cada uma das fontes a serem consultadas.

Providers LINQ e árvores de expressão (expression trees)

O LINQ consegue trabalhar de maneira agnóstica (ou seja, a mesma API do LINQ consegue trabalhar em cima de várias fontes de dados diferentes) principalmente por causa de dois pilares: os providers e as árvores de expressão – ou expression trees. Para entendermos cada um deles, vamos a partir deste ponto adotar o C# como a linguagem de referência.

De maneira geral e simplificada, uma expression tree é um trecho de código organizado como uma árvore onde cada nó pode corresponder a um valor, uma chamada de método ou até mesmo um operador aritmético ou lógico. No .NET, as árvores de expressão são definidas pela classe Expression, advinda do namespace System.Linq.Expressions.
Vamos montar uma árvore de expressão simples: uma árvore que retorna true caso receba um número menor que 5 ou retorna false no caso contrário. Para isso, precisamos criar um delegate que seja capaz de realizar essa análise… No .NET, existem dois tipos de delegate especializados e já disponibilizados pela API do LINQ:

  • Func: é um delegate que indica que um valor vai ser retornado. Delegates do tipo Func podem não receber parâmetros, mas sempre tem que prover algum retorno;
  • Action: é um delegate que indica que nenhum valor será retornado. Delegates do tipo Action podem não receber parâmetros e nunca irão retornar um valor.

Se verificarmos a situação acima, veremos que um delegate do tipo Func com um parâmetro de entrada do tipo int e uma saída do tipo boolean é o mais adequado. Sendo assim, utilizando expressões-lambda, podemos escrever esta definição:

Func<int, bool> expr = num => num < 5;

Para que este delegate se torne uma árvore de expressão de verdade, é necessário que ele seja envolvido pela classe Expression:

Expression<Func<int, bool>> expr = num => num < 5;

Agora, temos uma árvore de expressão completa com três ramificações:

  • O argumento do tipo int de entrada;
  • O operador de comparação >, revelando que se trata de uma árvore de expressão binária;
  • O 5, um valor constante que deve ser utilizado para comparação.

Qualquer expressão LINQ é decomposta nestas árvores de expressão. Neste momento, entra em cena os providers LINQ.
Os providers LINQ são utilizados basicamente para fazer a tradução das árvores de expressão para cada uma das fontes de dados na qual a expressão LINQ está conectada. Os principais providers LINQ são:

  • LINQ to objects: utilizado quando a fonte de consulta é um conjunto de objetos;
  • LINQ to XML: utilizado quando a fonte de consulta é um XML;
  • LINQ to SQL: utilizado quando a fonte de consulta é um banco de dados relacional.

As principais estruturas dos providers LINQ são as interfaces IQueryProvidere IQueryable. Todos os providers LINQ e suas variações são obrigados a implementar estas interfaces.
Através das implementações dos providers LINQ, as expressões de consulta podem ser traduzidas para as suas respectivas fontes de dados… Por exemplo: vamos considerar a árvore de expressão anterior (Expression expr = num => num < 5) com o número 4 como entrada.

Se estivéssemos falando de LINQ to Objects, cada nó que faz parte da expressão seria traduzido para o código C# correspondente. Teríamos o resultado abaixo:

Se estivéssemos falando de LINQ to SQL, cada nó que faz parte da mesma expressão seria traduzido para o código SQL correspondente. Teríamos o resultado abaixo:

Já se estivéssemos falando de LINQ to XML, cada nó que faz parte da mesma expressão seria traduzido para o código xPath/xQuery correspondente. Teríamos o resultado abaixo:

Veja que o LINQ, de acordo com a fonte de dados que está sendo analisada, utiliza o provider para realizar uma “tradução” da API de alto nível em C# para o código correspondente ao tipo da fonte de dados que está sendo utilizada. E esse processo torna a API completamente independente da fonte de dados a qual esta se conecta: quem fica responsável por dizer ao LINQ como cada nó da árvore de expressão tem que ser traduzido é o provider.

Existem muito mais coisas do LINQ a serem exploradas!

O LINQ é de fato uma ferramenta muito poderosa quando utilizada corretamente (especialmente quando estamos falando do LINQ to SQL). Este primeiro post na verdade tem a intenção de mostrar os princípios básicos e o funcionamento interno do LINQ. Nos próximos posts, iremos começar a analisar alguns pontos interessantes para quem utiliza o LINQ no dia-a-dia.

Como melhorar seu perfil online de desenvolvedor

A busca por um novo emprego é um dos principais dilemas na atualidade. Muitos buscam novas formas de ingressar no mercado de trabalho e as dificuldades vem surgindo dia após dia.

Não tem sido fácil a procura por novas vagas. Conseguir o primeiro emprego ou até mesmo a recolocação no mercado tem se tornado uma das principais barreiras para todos, independente de sua área de atuação.

Muitas empresas têm investido na busca pelo profissional ideal através do seu perfil online, o que não é diferente para a área de desenvolvimento.

Mas como posso melhorar meu perfil online de desenvolvedor para alcançar aquela tão sonhada vaga?

Neste artigo daremos algumas dicas de como melhorar este perfil online e aumentar suas chances de conseguir o “emprego dos sonhos”.

GitHub, GitLab e BitBucket

A maioria das empresas analisam a contribuição dos seus candidatos através de plataformas que armazenam código-fonte.

Aqui no blog, lançamos um artigo sobre as principais delas: o GitHub, GitLab e o BitBucket, que poderá ser acessado através do link:

https://www.treinaweb.com.br/blog/as-principais-plataformas-para-armazenamento-de-codigo-fonte/

Esta análise tem a ver com a forma com que são realizadas suas contribuições em projetos públicos e como são desenvolvidos seus projetos particulares.

É válido sempre lembrar que qualquer projeto conta. Independente do tamanho da aplicação, muitos recrutadores buscam saber da qualidade do seu código, independente do tamanho do projeto. Sendo assim, qualquer aplicação pode (e deve) ser hospedada em plataformas de armazenamento de código-fonte para incrementar seu perfil na ferramenta.

Linkedin

O Linkedin tem sido uma das principais formas de manter atualizado e disponível todos os dados do candidato e sua experiência profissional. Mas é sempre importante ficar atento a “como manter este perfil sempre em dia.”

A dica mais valiosa em torno do linkedin é, sem dúvida, a atualização constante do seu perfil profissional. Manter seu perfil atualizado e em ordem te dá, sem dúvidas, pontos extras na hora de tentar conquistar uma vaga.

Deve atentar-se também às suas conexões. Buscar sempre pessoas relacionadas a sua área de atuação, facilita a forma de expandir sua busca em vagas que são compatíveis a seu perfil.

Atentar-se também as suas declarações de escolaridade, cursos de idiomas, certificações e competências. Tudo que está escrito ali, deverá ser aquilo que você de fato domina e possui habilidade e comprovação.

Há, e seguir aquelas empresas que lançam vagas para sua área, também é uma excelente escolha, pois te deixa por dentro de novas oportunidades e mais próximo do objetivo que você espera.

Stack Overflow

Assim como citamos a importância de manter-se ativo em projetos postados em plataformas de código-fonte, o Stack Overflow também te auxilia a estar sempre em evidência. O website funciona de forma simples, onde você poderá lançar perguntas e responder dúvidas de outros usuários, tudo relacionado a área de programação, o que facilita para que novos desenvolvedores ativos na comunidade possam ser descobertos.

Para cada dúvida respondida, é gerado um “like”, utilizado para determinar os usuários mais ativos na plataforma. É com esta informação que as empresas filtram os perfis mais ativos no Stack Overflow, já que é gerado um ranking com todos esses usuários.

Artigos

Escrever sobre aquilo que você domina, também tem sido uma ótima forma de estar em evidência na web. Hoje em dia, diversos são os sites onde você poderá colaborar com seus artigos e escritos de forma que possa ajudar outras pessoas com informações válidas e úteis.

Mas busco vaga de desenvolvedor, isso conta?

Sim, e muito. Escrever sempre é muito importante, e aprimorar sua escrita será sempre uma opção válida na busca do emprego dos sonhos.

Participação em grupos de desenvolvimento

Vários grupos de desenvolvimento têm ganhado força em variados aplicativos como telegram, slack, entre outros. Desta forma, você poderá trocar informações com vários desenvolvedores, seja para tirar dúvidas ou prover uma solução, sendo mais uma ferramenta para se manter ativo na comunidade.

Além disso, diversas empresas estão constantemente publicando novas vagas de emprego nestes grupos, tornando-os ainda mais atrativos.

Conclusão:

Possuir um bom perfil online como desenvolvedor é a porta de entrada para conseguir o emprego dos sonhos. Desta forma, é possível utilizar a internet ao seu favor e aumentar suas chances de se destacar como um potencial candidato. Vimos neste artigo algumas dicas preciosas, esperamos que elas te ajudem em sua busca e que você consiga ingressar no mercado de trabalho o mais rápido possível. =)

Devo começar como Front-End, Back-End ou Full Stack?

Olá, Web Developers!

Muitos programadores no começo de suas carreiras acabam encontrando os termos Front-End, Back-End e Full Stack quando vão se candidatar a vagas de emprego. Então surgem as seguintes dúvidas: “o que devo seguir?”, “qual a mais difícil e qual a mais fácil?”, “qual paga melhor?”, etc.

Todos possuem vantagens e desvantagens. Vamos ver os pontos base sobre cada um.

Front-End

Desenvolvimento Front-End

Necessidades

O desenvolvedor Front-End terá que desenvolver as telas da aplicação que foram projetadas pelo Arquiteto e Designer, normalmente com HTML, CSS e JavaScript.

Este desenvolvedor também terá que saber analisar o trabalho do designer para poder seguir o que ele projetou, portanto também pode ser necessário saber o básico de softwares como PhotoShop, Illustrator, Adobe XD e Sketch.

Você não precisa saber sobre experiência de usuário e design, mas há empresas em que o próprio desenvolvedor Front-End precisa desempenhar os papéis de arquiteto e designer, tornando esses conhecimentos um diferencial deste profissional.

Há empresas que também vão querer um desenvolvedor Front-End para criar um site/blog feito com WordPress, então também pode ser interessante saber um pouco de PHP.

Desvantagens

O código feito por um Front-End é executado no cliente. Porém, não sabemos se o usuário está em um smartphone, tablet, notebook ou desktop. Será que o usuário está usando um bom Wi-Fi ou está com uma Internet móvel bem lenta?

Também não sabemos o sistema operacional, qual navegador, versão, etc. Um desenvolvedor Front-End precisa desenvolver um código que possibilite que a maioria dos usuários possam utilizar a aplicação sem problemas. Portanto, é necessário muitos testes em diversos ambientes.

Como estará em contato direto com o usuário, deverá entregar uma boa experiência, e isso se inicia no tempo de carregamento da aplicação. Portanto, também é preciso se preocupar com a otimização dos arquivos HTML, CSS, JS, imagens, etc.

Vantagens

Um Front-End tem como principal linguagem de programação o JavaScript, que está crescendo muito. Você pode ver mais no post O que se pode fazer com JavaScript hoje em dia?.

Além da web, este profissional pode aprender facilmente a criar aplicações desktop e mobile, desenvolver jogos e começar a trabalhar com Back-End utilizando apenas JavaScript.

Ele também não precisa se preocupar com performance do processamento feito no servidor e nem com o Banco de Dados.

Todas as empresas precisam de um Front-End, permitindo que você envie currículo para qualquer empresa.

Outro ponto é que o resultado do seu trabalho pode ser visto em ação (sistemas, aplicativos, sites, etc), permitindo deixar o seu currículo mais interessante.

Como normalmente as regras de negócio ficam no servidor, o Front-End pode ser um pouco mais amigável para quem não tem tanta lógica de programação (isso não significa que lógica é dispensável).

Hoje em dia as empresas estão valorizando cada vez mais o JavaScript, fazendo a demanda e o salário oferecido aumentarem, já que ainda há poucos Front-Ends de qualidade se comparar com a quantidade de desenvolvedores Back-End.

Back-End

Desenvolvimento Back-End

Necessidades

O desenvolvedor Back-End é aquele que responderá às requisições do cliente. Ele precisa saber alguma linguagem de programação, ter uma boa lógica para programar as regras de negócio do sistema, se conectar ao banco de dados para recuperar ou gravar dados, etc.

O banco de dados pode ser de responsabilidade de um profissional especializado, mas muitas vezes ele fica por conta do próprio desenvolvedor Back-End, fazendo da otimização de banco de dados algo interessante de se saber. Independente disso, o Back-End precisa saber mexer com banco de dados.

Além disso, este desenvolvedor também precisará saber publicar a aplicação, podendo ser necessário conhecimento em serviços como AWS ou Azure e a criação de contêineres como o Docker.
Para saber mais sobre o que é Docker, veja nosso post: No final das contas: o que é o Docker e como ele funciona?

Hoje em dia, dependendo do sistema, pode ser necessário que este profissional saiba lidar com Internet das Coisas (IoT), Aprendizado de Máquina (Machine Learning), Mineração de Dados (Data Mining), etc. Algumas destas habilidades será um grande diferencial deste profissional.

Desvantagens

Normalmente desenvolvedores Back-End tem mais familiaridade apenas com uma linguagem de programação, o que ilmita os lugares para onde podem enviar currículos. Então entra a questão: “devo estudar outra linguagem ou me especializar no que já sei?”

Se um Front-End pode enviar currículo para qualquer lugar, um desenvolvedor Back-End especializado em Java dificilmente será chamado por uma empresa que só trabalhar com Python, por exemplo.

Como lidam diretamente com a regra de negócio, precisam ser os mais atentos a cada detalhe, inclusive os dados enviados pelo Front-End, pois o cliente pode dar um jeito de burlar as regras do Front.

Devem estar atentos a vários casos de teste e lidar com a segurança do servidor para evitar ataques aos dados. Um pequeno problema aos dados e toda a empresa pode ter sérios problemas. Front e Back precisam estar atentos, mas erros no servidor podem ser muito mais graves.

Outro ponto é que a velocidade do Front-End muitas vezes vai depender das respostas do servidor, então também devem saber otimizar o banco e o código. Todos os usuários estarão acessando o seu servidor, então é preciso saber como escalar a sua aplicação para que ela não caia em um momento de grande quantidade de acessos.

Vantagens

O Back-End não precisa se preocupar com o dispositivo ou versão do navegador do cliente, pois seu código estará rodando em apenas uma única máquina a qual você mesmo pode configurar.

Um Front-End precisa saber logo de início HTML, CSS, JavaScript, deixar as telas funcionando em todos os tamanhos de dispositivos, etc, enquanto o Back-End precisará de uma linguagem de programação e um banco de dados, podendo o Back-End ser um pouco mais amigável para alguns iniciantes, principalmente os que tem boa lógica de programação e/ou aqueles que não se dão muito bem com as partes mais visuais de um sistema.

Além disso, hoje em dia ainda é muito comum que empresas paguem salários maiores para desenvolvedores Back-End, principalmente por sua alta responsabilidade com os dados da aplicação.

Full Stack

Pessoa Trabalhando

Necessidades

O NINJA! O Full Stack é o desenvolvedor que faz tanto Front quanto Back. Então tudo o que foi dito aqui são necessidades para que alguém seja considerado um verdadeiro Full Stack.

Mas deve-se tomar cuidado! Há desenvolvedores Back-End que só por saberem se virar com JavaScript e um pouco de CSS se consideram Full Stack (precisa mais que isso para ser Front), do mesmo jeito que muitos Front-Ends, por saberem como fazer uma API e salvar algo no Banco de Dados (precisa mais que isso para ser back), já se consideram Full Stack também.

Um verdadeiro Full Stack deve estar bem familiarizado com ambos os lados. Por esses motivos, muitos acreditam que um verdadeiro Full Stack é algo que não existe, como um ser mitológico. Porém, isto não te impede de ser Full Stack.

Há empresas que apenas esperam que uma mesma pessoa pegue dados do banco e exiba em uma tela, e depois pegue os dados da tela e salve no banco. Conseguir fazer o fluxo completo com qualidade já pode qualificar este profissional como Full Stack, mas é preciso se dedicar muito para fazer tudo isso com qualidade.

Você pode aprender mais sobre isso com o nosso curso MEAN 2 – JavaScript FullStack

Desvantagens

As tecnologias estão sempre evoluindo, e é muito difícil se manter atualizado em várias coisas ao mesmo tempo, o que seria o ideal para quem quer se manter como Front e Back ao mesmo tempo.

Não confunda Full Stack (sabe bem Front e Back) com um generalista (sabe um pouco de tudo).

Vantagens

Possibilidade de enviar currículos para mais lugares e poder encontrar empresas que ofereçam salários maiores. Além disso, pode se oferecer para trabalhar apenas como Back ou apenas como Front.

Conclusão

Cada caminho possui vantagens e desvantagens. O melhor é analisar sua realidade, necessidade e objetivos para fazer a melhor escolha. E não se preocupe em ter que escolher certo de primeira, pois se não gostar da sua escoha sempre haverá tempo de recomeçar com algo diferente.

Confira também nosso Post sobre Ser especialista em algo ou saber um pouco de tudo?

JUNTE-SE A MAIS DE 150.000 PROGRAMADORES