Para quem está começando, aqueles termos que parecem outra língua
Resolvi montar um post para ajudar aqueles que estão começando na área de Tecnologia, onde percebi em alguns eventos e aulas, que muitos ficam sem entender tantos termos técnicos, há muitas postagens por aí explicando cada um, mas penso em compartilhar aqui alguns termos básicos para ajudar a dar um pontapé inicial.
Agile (metodologia ágil)
A expressão Agile vem do inglês Agile software development, isso é, desenvolvimento ágil de software. Trata-se de um nome atribuído a um conjunto de práticas para projetos de software que são consideradas inovadoras por quebrar determinados paradigmas que existiam até então na engenharia de software.
#Scrum, XP e #DevOps são alguns dos métodos ágeis mais conhecidos no mercado, além de outros genéricos, isso é, que não tiveram sua origem no #Desenvolvimento de software, mas que também são utilizados para práticas de projetos de sistemas, como é o caso do KANBAN.
Estas medologias abordam a entrega do produto em pequenas partes, onde os envolvidos podem experimentar e realizar pequenos ajustes de curso no decorrer do desenvolvimento, propiciando a entrega de um produto muito mais aderente às necessidades do cliente.
Lembrando-se que: “desenvolver software de forma ágil não quer dizer que seja mais rápido, agilidade quer dizer destreza em desviar de obstáculos e conseguir chegar ao destino”
Saiba mais em: https://www.portalgsti.com.br/agile/sobre/
API (Application Programming Interface)
A Sigla API na sua tradução quer dizer “Interface de Programação de Aplicações”, elas são aplicações disponibilizadas na Internet para integração entre aplicações e sistemas, com padrões para segurança de informações, realizando intercâmbio entre diferentes linguagens de programação e sistemas operacionais. Podem realizar desde tarefas simples até todas a tarefa de um software específico numa única API.
Saiba mais em: https://vertigo.com.br/o-que-e-api-entenda-de-uma-maneira-simples/
Back-End
Quando uma aplicação é desenvolvida, podemos definir como back-end toda a parte lógica por trás do seu funcionamento, onde encontram-se regras de negócio, cálculos, persistência de dados em bancos de dados, dentre outras atribuições.
Um Back-End pode ser feito em diversas linguagens como C#, Php, Java, Python, Node, Ruby, Go, Visual Basic, Delphi, dentre outras.
Define-se back-end tudo aquilo num sistema que não envolva “telas”.
Saiba mais em : https://www.treinaweb.com.br/blog/o-que-e-front-end-e-back-end/
Compilação
Compilação é o processo de “tradução” do programa escrito em uma linguagem de programação para um formato no qual o computador entenda (possa executar). A compilação gera um arquivo binário (executável) a partir do código fonte.
CI (Continuous Integration)
A integração contínua permite que desenvolvedores tenham um nível maior de produtividade e qualidade, ela é uma forma de realizar a entrega (Deploy) de aplicações de forma contínua.
Sem testes e deploy automatizados, o desenvolvedor tende a escrever uma grande quantidade de código antes de realmente colocar o programa para executar, afinal se o processo é trabalhoso e toma muito tempo, ele vai evitar de fazer isso ao máximo. Só que no final gasta-se muito tempo para corrigir todos os “detalhes” que não estavam corretos.
Para mitigar todos esses problemas, surgiu o conceito de Integração Contínua. A ideia é justamente automatizar o processo para que com bastante frequência, uma ou mais vezes ao dia, seja possível integrar todas as alterações de todos os desenvolvedores envolvidos no projeto e realizar um teste geral.
Debug (depuração)
Execução do programa passo a passo a fim de encontrar problemas que só são percebidos durante a sua execução, podendo parar em pontos específicos, analisar os dados em memória e identificar por que a aplicação está funcionando de forma inadequada.
Saiba mais em: https://pt.wikipedia.org/wiki/Depura%C3%A7%C3%A3o
Deploy (Implantação)
Pode-se chamar de deploy a implantação ou distribuição de um sistema/aplicação para uso, seja em ambiente de desenvolvimento, teste ou produção.
O deploy pode ser automatizado ou manual.
Framework
Falando de tecnologia de software, é um conjunto de bibliotecas ou componentes que são usados para criar uma base onde sua aplicação será construída.
Existem frameworks para diversas tecnologias, assim como podem definir também como framework ferramentas para a gestão de projetos, metodologias ágeis e alguns métodos de otimização de processos.
Framework então é uma estrutura de trabalho que atua com funções pré-estabelecidas que se adaptam à situação e à organização em questão
Saiba mais em: https://tableless.github.io/iniciantes/manual/js/o-que-framework.html
https://dinamicatreinamentos.com/blog/o-que-sao-frameworks/
Front-End
O termo Front-end é utilizado para definir tudo aquilo que está à frente de uma aplicação, tudo aquilo que é visualizado pelo usuário.
Para desenvolver um front-end o desenvolvedor tem que estar preocupado com a experiência do usuáro (UX) para que o desenvolvimento seja o mais agradável para o usuário.
Antigamente quando existiam apenas aplicações para computadores, não existia uma divisão clara entre Front-End e Back-End, pois regras de negócio e a parte visual eram desenvolvidas paralelamente, com a evolução das aplicações houve a necessidade de segmentar para que as regras de negócio pudessem ser utilizadas por qualquer aplicação Web, Aplicativos e Software Comum.
No desenvolvimento Web, o profissional de Front-End deve preocupar-se com HTML, CSS, Javascript e também especializar-se com Frameworks como: Angular, React, Bootstrap, etc.
Já no desenvolvimento de aplicações Mobile o profissional precisa aprender utilizar os frameworks específicos para estas aplicações para cada dispositivo nativo como Android e Apple ou Frameworks híbridos que permitem compilar para qualquer aplicação.
Microserviços
Polêmicos, eles surgiram nos últimos anos da idéia de desenvolvimento de uma aplicação separada em módulos ou da modularização de sistemas antigos para pequenas partes a fim de simplificar as tarefas de manutenção e deploy, segregando em pequenas partes de acordo com um contexto em geral.
A ideia não é exatamente nova, é usada em ambientes Unix desde a década de 60, mas recentemente se tornou o epicentro de uma grande revolução na forma como as empresas estão desenvolvendo software ágil baseado em equipes enxutas responsáveis por componentes autossuficientes.
O que facilitou o uso de Microserviços foi a maior utilização de Continuous Integration, pois ficou muito mais simples e rápida a sua publicação, dado que algumas soluções tem dezenas de microserviços.
Com a disseminação de API´s rodando em Nuvem, começou a haver maior facilidade para implantação de Microserviços, permitindo que possamos colocar em funcionamento a “Escalabilidade” onde eles terão a possibilidade de serem replicados e atender à demandas flexíveis, permitindo atender à muito mais solicitações.
Saiba mais em:
https://www.luiztools.com.br/post/introducao-arquitetura-de-micro-servicos/
https://cio.com.br/3-motivos-para-a-extincao-dos-softwares-em-monolitos/
Monolito
O Conceito de classificar uma aplicação como Monolito não existia há alguns anos atrás, de repente vimos um termo que transformava todos os softwares antigos em “Monolito”, seriam eles da idade da pedra ?
Na verdade, uma aplicação monolítica descreve um software que é projetado sem modularidade, toda a base de código utilizada em sua programação fica contida em um só lugar, de modo que todas as funcionalidades operam como se fizessem parte de um único bloco.
O monolito nos obriga, substituir a aplicação completa quando é atualizada uma pequena funcionalidade ou área específica, correndo o risco de derrubar uma aplicação inteira, ou perdendo muito tempo para publicar dado o tamanho de uma aplicação, obrigando que ela fique fora do ar durante o tempo de publicação.
Existem muitas controvérsias sobre os uso ou não de monolitos, inclusive há um paradigma conceitual que prega o uso da técnica: “monolith-first” onde o conceito básico é iniciar o desenvolvimento como um monolito, evitando assim as complicações de desenvolver Microserviços, e depois aos poucos ir segmentando partes da aplicação (já testada e funcional) para tornar-se uma aplicação de Microserviços ao final, o benefício disto é que as regras de negócio já estariam consolidadas e os técnicos teriam apenas que modificar a arquitetura da aplicação sem modificar as regras.
Nuvem
Computação em nuvem é o fornecimento de serviços de computação, incluindo servidores, armazenamento, bancos de dados, rede, software, análise e inteligência, pela Internet (“a nuvem”) para oferecer inovações mais rápidas, recursos flexíveis e economias de escala. Você normalmente paga apenas pelos serviços de nuvem que usa, ajudando a reduzir os custos operacionais, a executar sua infraestrutura com mais eficiência e a escalonar conforme as necessidades da sua empresa mudam.
Temos vários fornecedores de serviços de nuvem hoje em dia, os maiores e mais utilizados são: Microsoft (Azure), Amazon (AWS), Google (Google Cloud) e IBM (Ibm Cloud).
Saiba mais em: https://azure.microsoft.com/pt-br/overview/what-is-cloud-computing/
Full Stack
Quando um desenvolvedor é capaz de realizar tarefas tanto de Front-End como de Back-End, podemos chamá-lo de full-stack.
Kanban
Kanban é um termo em japonês que significa cartão ou quadro de sinais e ficou conhecido por ser uma metodologia de gestão visual, com cartões de informações que registram as ações da indústria.
Criada pela Toyota, ela foi responsável por auxiliar vários negócios a terem um fluxo de trabalho mais eficiente e alinhado com as demandas de seus clientes.
Diante da possibilidade de levar essas melhorias para outras áreas, a metodologia Kanban passou a ser incorporada em outros setores. No desenvolvimento de softwares, por exemplo, ela conseguiu criar um ambiente mais flexível e ágil.
Isso fez com que a Kanban se tornasse parte daquilo que vemos como as metodologias ágeis. Elas são uma forma de trabalho que ajuda times a conversarem melhor e, assim, atingirem as suas metas com facilidade.
Referências: https://blog.cronapp.io/como-utilizar-a-metodologia-kanban-no-desenvolvimento-de-softwares/
Refactor (Refatoração)
Refatoração em desenvolvimento de software significa tornar o código mais compreensível e bem estruturado alternando o seu design interno de modo a facilitar o desenvolvimento em equipe e a manutenção.
Seria refazer o código com maior qualidade que a forma com a qual estava escrito anteriormente.
Saiba mais em: http://www.linhadecodigo.com.br/artigo/2832/introducao-a-refatoracao.aspx#ixzz6Hd5xozpA
REST
É um protocolo de comunicação, baseado no protocolo de hipermídia HTTP. Porém ele não impõe restrições ao formato da mensagem, apenas no comportamento dos componentes envolvidos.
A maior vantagem do protocolo REST é sua flexibilidade. O desenvolvedor pode optar pelo formato mais adequado para as mensagens do sistema de acordo com sua necessidade específica. Os formatos mais comuns são JSON, XML e texto puro, mas em teoria qualquer formato pode ser usado.
Isso nos leva a outra vantagem: quase sempre Web Services que usam REST são mais “leves” e, portanto, mais rápidos.
O problema com o REST pode surgir justamente por causa de suas vantagens. Como a definição do corpo de dados fica totalmente a cargo do desenvolvedor, os problemas de interoperabilidade são mais comuns.
SOAP
SOAP é um protocolo de transferência de mensagens em formato XML para uso em ambientes distribuídos. O padrão SOAP funciona como um tipo de framework que permite a interoperabilidade entre diversas plataformas com mensagens personalizadas.
Aplicando este padrão em Web Services, geralmente usa-se o WSDL para descrever a estrutura das mensagens SOAP e as ações possíveis em um endpoint.
Uma das maiores vantagens disso é que várias linguagens e ferramentas conseguem ler e gerar mensagens facilmente. Várias linguagens de programação permitem a geração de objetos de domínio, Stubs e Skeletons a partir da definição do WSDL, permitindo a comunicação remota via RPC através de chamadas a métodos remotos, inclusive com argumentos complexos, como se fossem chamadas locais.
O problema desse padrão, é que ele adiciona um overhead considerável, tanto por ser em XML quanto por adicionar muitas tags de meta-informação. Além disso, a serialização e desserialização das mensagens pode consumir um tempo considerável.
Serverless
O conceito de serverless se refere ao modelo de cloud computing em que os desenvolvedores não precisam provisionar servidores ou gerenciar a escala das aplicações. Na verdade, essas tarefas rotineiras são abstraídas pelo provedor da nuvem, possibilitando que os desenvolvedores enviem códigos para produção com mais rapidez do que nos modelos tradicionais.
Resumindo, ao usar o modelo serverless os desenvolvedores se concentram no código, em vez da infraestrutura. Ou seja, é serverless porque as especificações do servidor não afetam os desenvolvedores. É claro que os servidores ainda existem, mas eles são gerenciados pelo provedor de serviços em nuvem.
Scrum
Scrum é uma metodologia ágil para gestão e planejamento de projetos de software.
No Scrum, os projetos são dividos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.
As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.
A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo.
Saiba mais em: https://www.desenvolvimentoagil.com.br/scrum/
TDD (Test-Driven Development)
TDD é uma técnica de escrita de código em que testes são escritos antes do nosso código de produção!
Através de Testes o desenvolvedor garante que as regras de negócio estão aplicadas corretamente, facilitando o processo de desenvolvimento e manutenção da aplicação.
O ciclo de desenvolvimento funciona assim:
Red,Green, Refactor. Ou seja:
- Escrevemos um Teste que inicialmente não passa (Red)
- Adicionamos uma nova funcionalidade do sistema
- Fazemos o Teste passar (Green)
- Refatoramos o código da nova funcionalidade (Refactoring)
- Escrevemos o próximo Teste
Saiba mais em:https://www.devmedia.com.br/test-driven-development-tdd-simples-e-pratico/18533
UI
O User Interface — ou interface do usuário — é tudo aquilo que é perceptível visualmente em alguma plataforma e leva o usuário a uma interação positiva. Pode ser um botão, um menu diferente ou até mesmo um som.
UX
User Experience (UX), experiência de usuário em bom português, nada mais é do que a arte de trazer o usuário para o centro do projeto, sabendo conciliar suas necessidades, anseios e satisfação com os objetivos do produto.
Dizendo de uma forma mais acadêmica: user experience é um método de engenharia e design que cria sistemas que funcionem melhor para o usuário pretendido. Os usuários devem ser incluídos no processo de design através de pesquisas do usuário e testes de usabilidade. Sem isso, não estamos praticando user experience.
A única maneira de entender o que faz sentido para um usuário é conversar, ouvir e observar. Contudo, é preciso deixar claro que entender os usuários não garante o sucesso do projeto. O que se pode afirma é que as chances do projeto dar certo aumentam significativamente.
Waterfall (Cascata)
Técnica de desenvolvimento de software onde é feito um planejamento com o cronograma de desenvolvimento com antecedência e seguindo todas as etapas linearmente. Diferente da metodologia ágil . Este tipo de abordagem tem sido evitada atualmente devido à somente disponibilizar um produto ao final do processo e normalmente este ao ser entregue ou está atrasado ou algumas das funções planejadas lá no início não fazem mais sentido, sendo necessário refazer muita coisa para sair da forma como o cliente desejava. Dado que não há momentos de entregas parciais onde os envolvidos podem ver e experimentar o produto em pequenas partes, diferente das abordagens ágeis.
Unit test
Um teste unitário basicamente é o teste da menor parte testável de um programa.