A carreira em tecnologia é frequentemente retratada como uma escalada meteórica, impulsionada por inovação e oportunidades sem fim. No entanto, por trás das histórias de sucesso, existe um percurso repleto de desafios, decisões críticas e, inevitavelmente, erros. A sabedoria não reside em evitar todos os percalços, mas em desenvolver a capacidade de autoavaliação e planejamento para aprender com eles.

Neste artigo proponho uma reflexão sobre um conjunto de erros de carreira que cometi ao longo dos anos, baseados em minhas experiências reais, para extrair lições valiosas que possam acelerar o crescimento profissional de outros.

Ao longo desta análise, exploraremos as armadilhas mais comuns que podem sabotar uma trajetória promissora. Investigaremos desde a gestão do conhecimento técnico em um cenário de constante mudança até o delicado equilíbrio entre vida profissional e pessoal.

Abordaremos também a dinâmica no ambiente de trabalho, a importância de saber quando permanecer e quando partir, e, finalmente, a necessidade fundamental de um planejamento estratégico para construir uma carreira sólida e com propósito.

Vamos começar pela primeira e talvez mais traiçoeira armadilha da nossa área: a estagnação tecnológica.

O Apego Tecnológico: O Risco de Ficar Para Trás

No universo da tecnologia, a única constante é a mudança. Ignorar essa verdade não é uma opção, é uma sentença de obsolescência. É por isso que a adaptabilidade é o seu ativo mais valioso. A falha em reconhecer essa realidade leva a dois erros interligados que podem estagnar uma carreira promissora.

Inércia vs. Perfeccionismo: Os Dois Lados da Estagnação

• Erro 1 – Estagnação por Afeição: O primeiro perigo é “se apaixonar” por uma tecnologia a ponto de ignorar as tendências do mercado. Um exemplo claro disso é a insistência em paradigmas de programação procedural, como o Pascal, quando a indústria já havia abraçado massivamente a orientação a objetos. Essa resistência à mudança, motivada pelo conforto do conhecido, resulta em um custo altíssimo: a perda de “várias vagas de trabalho em empresas muito boas”.
  Ficar preso a uma ferramenta específica é como construir uma casa em areia movediça; a base eventualmente cederá.
• Erro 2 – A Busca pela Maestria Absoluta: O segundo erro é o oposto da inércia, mas igualmente paralisante: a crença de que é preciso dominar 100% de uma ferramenta antes de ousar aplicá-la profissionalmente. Essa mentalidade perfeccionista ignora um princípio fundamental da nossa área: programação, assim como a tecnologia em geral, “você aprende na prática”.
  Esperar por uma preparação completa que nunca chega é uma forma sutil de autossabotagem. O conhecimento teórico é o ponto de partida, mas a aplicação precoce é o verdadeiro catalisador para o aprendizado real e a conquista de novas oportunidades.

Síntese da Lição Prática

Para navegar com sucesso no cenário tecnológico, é preciso adotar uma abordagem equilibrada, que combine vigilância e ação. As lições podem ser destiladas em duas recomendações principais:

• Aprendizagem Contínua Ativa: Mantenha-se “antenado nas tecnologias novas” que estão surgindo. Isso exige uma postura proativa e a coragem de “descartar o que você aprendeu anteriormente” quando uma abordagem mais eficaz se apresenta. O aprendizado em tecnologia não é um acúmulo linear, mas um processo constante de renovação.
• Aplicação Imediata: Coloque o conhecimento em prática assim que tiver uma “certa desenvoltura”. Não espere saber tudo para começar. O aprendizado se solidifica no campo de batalha, resolvendo problemas reais. O que você já sabe pode ser suficiente para começar, e o resto será desenvolvido ao longo do caminho.

Gerenciar o conhecimento técnico é apenas uma parte da equação. A outra é saber gerenciar a própria jornada profissional dentro e entre as empresas, o que nos leva ao próximo dilema.

O Dilema da Permanência: Equilibrando Lealdade e Crescimento

A decisão de permanecer ou sair de uma empresa é uma das mais complexas na vida profissional. Não existe uma fórmula única, mas sim um balanço delicado entre estabilidade, crescimento pessoal e relevância no mercado. Tanto a permanência excessiva quanto a mudança constante apresentam riscos que podem minar uma carreira a longo prazo se não forem avaliados com cuidado.

A Corda Bamba da Lealdade: O Risco de Ficar Demais e o Perigo de Sair Cedo

• O Risco de Ficar Demais (A Armadilha do Dinossauro Corporativo): Permanecer na mesma empresa e, principalmente, na mesma função por um período excessivamente longo pode levar à obsolescência. Com o tempo, as habilidades desenvolvidas podem se tornar tão específicas para aquele ambiente que “talvez não tenha mais utilidade fora dali”. O profissional corre o risco de se tornar um “dinossauro”, sentindo que teria uma “dificuldade gigantesca para conseguir um posto de trabalho em outro lugar”. A relação de trabalho não pode se resumir a “simplesmente a receber o salário no fim do mês”; ela precisa ser uma via de mão dupla de contribuição e crescimento.
• O Risco de Ficar de Menos: No outro extremo está o “caça salário”, o profissional que pula de empresa em empresa a cada poucos meses em busca de um pequeno aumento. Embora a busca por uma remuneração melhor seja legítima, essa atitude, quando desprovida de um compromisso com a entrega de valor, pode ser destrutiva.
  A longo prazo, cria-se uma reputação de profissional “não confiável”, alguém que “vai deixar a empresa na mão” na primeira oportunidade. É crucial ponderar, pois é evidente que “oportunidades muito boas Elas têm que ser aproveitadas”, mas a troca constante por ganhos marginais mina a confiança que as empresas depositam em você.

Quando é a Hora de Mudar?

Para tomar uma decisão informada, é crucial realizar uma autoavaliação periódica, utilizando critérios claros. Considere os seguintes pontos para determinar se é o momento de buscar um novo caminho:

1. Fim do Crescimento: Avalie honestamente se você ainda tem espaço para evoluir. Se você percebe que “não têm oportunidade de crescimento maiores nessa empresa” e seu desejo de aprender mais não é satisfeito, pode ser um sinal de estagnação.
2. Contribuição Mútua: A relação de trabalho deve ser benéfica para ambos os lados. O ciclo ideal é “você puder contribuir com ele [a empresa] e se eu puder contribuir com você”. Quando essa troca cessa e a relação se torna puramente transacional, o engajamento e a motivação tendem a desaparecer.
3. Relevância Externa: Pergunte-se se as suas tarefas e competências atuais estão alinhadas com as demandas do mercado de trabalho. Se a resposta for negativa, você pode estar se tornando um especialista em uma área que está perdendo valor fora dos muros da sua empresa atual.

A decisão de ficar ou sair está intrinsecamente ligada à forma como nos comportamos dentro da empresa, especialmente em relação à gestão dos nossos próprios limites, o que nos conduz à próxima reflexão crítica.

O Custo Oculto do “Sim”: Protegendo seu Bem-Estar e Foco

A cultura de alta performance em tecnologia pode, perigosamente, glamourizar o excesso de trabalho, transformando a exaustão em um símbolo de dedicação. No entanto, essa mentalidade é insustentável e contraproducente. Gerenciar a própria energia, saúde e tempo é uma competência estratégica, um ativo de carreira que, se negligenciado, pode levar ao esgotamento e a consequências irreversíveis.

O Preço da Dedicação Extrema: Saúde e Foco em Risco

• O Sacrifício da Saúde: A prática de “deixar de lado o meu bem-estar pessoal” para agradar uma empresa é uma armadilha comum. A anedota de trabalhar 24 horas seguidas, “comendo coxinha no bar da esquina”, ilustra vividamente as consequências dessa escolha. O sacrifício de sono, alimentação adequada e tempo com a família em nome de um projeto tem um preço alto.
  A trágica ironia é que o esforço desmedido do passado agora “me impede de trabalhar mais hoje”, mesmo sendo um profissional mais capacitado.
  Os mesmos sacrifícios feitos para avançar na carreira acabaram se tornando os maiores obstáculos para o seu potencial futuro.
• A Incapacidade de Dizer “Não”: A dificuldade em recusar tarefas está frequentemente ligada ao medo de “parecer incompetente” ou de ser demitido. Essa mesma insegurança é a raiz de outro erro que veremos adiante: o medo de pedir ajuda. Ambas as atitudes nascem do receio da vulnerabilidade. Aceitar responsabilidades além da própria capacidade é uma receita para o fracasso.
  Um exemplo disso é o profissional que, ao realizar um “trabalho X” com excelência, aceita um “trabalho Y” adicional para o qual não estava preparado. O resultado foi um segundo trabalho “muito mal feito”, que não apenas desagradou a empresa, mas também culminou na perda do projeto original no qual ele estava indo bem.

Formulação dos Princípios de Autoproteção

Para construir uma carreira longa e produtiva, é essencial substituir a mentalidade de sacrifício por uma abordagem de sustentabilidade profissional. A tabela abaixo contrasta essas duas visões:

A dificuldade em impor limites raramente é apenas sobre carga de trabalho; ela nasce de uma complexa mistura de medo e ego — o medo de parecer incompetente e o ego que nos impede de admitir nossas limitações, uma armadilha que merece sua própria análise.

A Armadilha do Ego: Humildade Como Ferramenta de Crescimento

Em um campo tão intensivo em conhecimento como a tecnologia, o ego pode ser o maior obstáculo ao aprendizado genuíno e à colaboração eficaz. A falsa necessidade de parecer infalível nos impede de fazer a coisa mais importante para o nosso desenvolvimento: admitir o que não sabemos. A humildade, longe de ser um sinal de fraqueza, é uma poderosa ferramenta de crescimento.

Quando o Orgulho Custa Caro: O Medo de Pedir Ajuda e a Ilusão do Conhecimento

• Medo de Pedir Ajuda: A recusa em procurar ajuda por “vergonha” ou medo de parecer incapaz é um erro clássico e destrutivo. A experiência de transformar um trabalho que “deveria ser feito em duas horas [em um que] foi feito em duas semanas” ilustra perfeitamente o resultado: “stress”, perda de “contratos de clientes bravos” e um desgaste profissional imenso que leva a “passar vergonha depois”.
  Contrariando a intuição do ego, procurar ajuda não desqualifica um profissional; pelo contrário, demonstra maturidade, acelera a resolução de problemas e promove o aprendizado.
• A Ilusão do Conhecimento: Outra manifestação do ego é “achar que sabe mais do que realmente sabe”. Essa atitude leva a subestimar a complexidade de tecnologias e desafios, resultando em problemas que, inevitavelmente, “estouram na sua cara”. A verdadeira sabedoria reside em reconhecer a vastidão do conhecimento e as próprias limitações.
  A postura de admitir publicamente, “eu não sei isso não vou dizer que eu sei”, é um exemplo de integridade e humildade intelectual que gera confiança e abre portas para o aprendizado.

Princípio da Humildade Intelectual

A lição fundamental aqui é a prática da humildade intelectual – a consciência clara dos limites do próprio conhecimento. É preciso ter a coragem de “descer lá no pedestal e admitir: eu não sei isso”. Esse reconhecimento é o primeiro passo para aprender de verdade. A realidade do nosso setor é que a tecnologia está em constante evolução, e a premissa de que “ninguém sabe tudo e nem jamais vai saber tudo” é libertadora. Ela nos permite estar sempre em modo de aprendizado, abertos a novas ideias e à colaboração.

Dominar o ego e abraçar o aprendizado é a base da maturidade profissional. Contudo, essa maturidade só gera resultados consistentes quando é aplicada a uma visão de longo prazo, nos protegendo do erro mais abrangente de todos: navegar a carreira sem um destino em mente.

Navegando sem Bússola: A Importância de um Plano de Carreira

Uma carreira em tecnologia não pode ser deixada ao acaso. Sem uma direção clara, corremos o risco de acumular experiências desconexas que não se somam para construir uma especialização valiosa. Um plano de carreira não deve ser visto como um roteiro rígido e imutável, mas como uma bússola que orienta as decisões diárias, garantindo que o esforço contínuo nos leve a um destino profissional desejado.

A Deriva Profissional: As Consequências de uma Jornada sem Rumo

Viver “um tempo ao sabor do vento” profissionalmente pode parecer libertador no início, mas suas consequências a longo prazo são graves. A experiência de trabalhar com uma “tecnologia A” em uma empresa e, em seguida, mudar para outra para trabalhar com “tecnologia B” que “não estava relacionada com a primeira” é um exemplo clássico. Sem um fio condutor, o resultado é um “acumulo de conhecimentos esparsos” em vez de uma especialidade sólida.

A pergunta que fica é bem problemática: “No final eu ia acabar com o quê? Com nada”.

Esboçando seu Caminho

Lembre-se: construir um plano de carreira não é sobre ter todas as respostas de imediato, mas sim começar a fazer as perguntas certas e a esboçar uma direção. Aqui estão alguns passos iniciais e acionáveis para criar seu roteiro profissional:

• Defina uma Direção Geral: Tenha uma visão, mesmo que ampla, de “onde você quer chegar daqui a cinco anos, daqui a dez anos”. Isso ajuda a filtrar oportunidades e a tomar decisões mais alinhadas com seus objetivos.
• Visualize uma Progressão: Entenda a linha natural de crescimento na sua área de interesse. O caminho de “estagiário” para “desenvolvedor Júnior”, depois “pleno” e “sênior” é um exemplo de progressão que ajuda a estruturar as expectativas e os próximos passos.
• Faça Perguntas Estratégicas: Questione-se regularmente: “Qual é a sua especialidade? O que você pretende?”. Essas perguntas forçam a clareza e garantem que você não está apenas reagindo às oportunidades, mas construindo proativamente a carreira que deseja.

A criação de um plano de carreira é o que conecta todos os pontos, transformando a jornada de aprendizado e a superação de erros em uma trajetória coerente e com propósito.

Conclusão: Transformando Erros em Degraus para o Sucesso

Ao longo desta reflexão, navegamos por cinco áreas críticas onde erros comuns podem desviar uma carreira promissora em tecnologia. Vimos a necessidade vital de aprendizado contínuo para não ficar obsoleto; o delicado equilíbrio entre lealdade e crescimento ao decidir permanecer em um emprego; a importância inegociável de proteger nosso bem-estar e saber dizer “não”; a prática da humildade como catalisadora do conhecimento; e, finalmente, a indispensável bússola de um plano de carreira para dar direção aos nossos esforços.

A mensagem central não é lamentar os erros, mas sim utilizá-los como ferramentas poderosas para uma tomada de decisão mais consciente e estratégica no futuro. Cada passo em falso, quando analisado com honestidade, se torna um degrau na escada do nosso desenvolvimento profissional. Eles nos ensinam sobre nossos limites, nossas paixões e o tipo de carreira que verdadeiramente desejamos construir.

O objetivo final é capacitar cada profissional a trilhar seu próprio caminho com mais segurança e clareza. Como diz a mensagem que inspirou este artigo, “o objetivo aqui […] é orientar vocês de modo que vocês tenham carreiras boas, brilhantes e se deem bem na vida”. Que estas lições sirvam como um guia para que você possa não apenas evitar as armadilhas, mas, acima de tudo, construir uma jornada profissional da qual se orgulhe.

PARA SABER MAIS

Assista ao vídeo no canal da Bóson Treinamentos em Tecnologia no qual abordo esse conteúdo:

O post Erros que cometi ao longo da carreira e lições aprendidas apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

E por que ele pode custar milhões (ou mesmo vidas)

Se você estuda ou trabalha em alguma área relacionada à tecnologia, é altamente provável – quase certeza – que já se deparou com a expressão “bug” ou com algum verbo “abrasileirado”, como “bugar” ou “bugado”. Mas o que significa exatamente isso?

Considere a seguinte situação: um comando simples, por exemplo programado para imprimir uma mensagem na tela dez vezes, acaba executando indefinidamente, sem qualquer critério de parada. O sistema permanece responsivo, mas o comportamento é claramente incorreto. Trata-se de um erro lógico comum — chamado de loop infinito — e é um exemplo clássico de bug em programação.

Entendendo o conceito de bug

Bugs são falhas no código-fonte que levam um programa a se comportar de forma inesperada ou incorreta. Podem resultar em pequenos transtornos, como uma interface mal formatada, ou em consequências graves, como perda de dados, travamentos do sistema e até riscos à segurança – ou ainda mais graves.

Qualquer pessoa que já tenha escrito código, por mais simples que seja, inevitavelmente se depara com esse tipo de problema.

Mas o que caracteriza, de fato, um bug? E por que eles continuam sendo tão prevalentes mesmo com os avanços nas ferramentas de desenvolvimento e boas práticas de engenharia de software? 

Ao contrário do que muitos pensam, computadores não “pensam” ou “entendem” intenções. Eles fazem exatamente o que mandamos — o problema é que nem sempre mandamos a coisa certa. Eles costumam surgir por erro humano: um código mal projetado, uma lógica mal pensada ou até mesmo por uma simples distração na digitação.

A origem do termo “bug”

A palavra bug (que literalmente significa “inseto” em inglês) foi popularizada pela almirante Grace Hopper em 1947. Durante a manutenção de um computador eletromecânico Mark II, uma mariposa foi encontrada presa em um relé, provocando falhas. O inseto foi cuidadosamente colado no diário de bordo com a legenda: “First actual case of bug being found” (em português, “Primeiro caso real de um bug sendo encontrado”).

A partir de então, o termo passou a ser usado para qualquer tipo de erro ou falha que ocorra em sistemas computacionais, não só de hardware, mas também (e hoje, principalmente) de software.

Primeiro “bug” de computador encontrado – literalmente. Mariposa presa em um relé em um painel do Mark II durante um teste na Universidade de Harvard, em 09 de setembro de 1947. Os operadores que a encontraram a afixaram no livro de registros do computador, com a frase “Primeiro caso real de um bug sendo encontrado”

Os três principais tipos de bug

Os bugs nem sempre se manifestam da mesma forma. Alguns são fáceis de identificar, outros podem passar despercebidos por muito tempo. Os principais tipos incluem:

1. Erros de sintaxe

São falhas na escrita do código — algo como esquecer de fechar aspas, colocar um ponto e vírgula onde não devia (ou não colocar), ou ainda digitar comandos inválidos. A boa notícia? São geralmente detectados imediatamente na hora da compilação ou interpretação, ou mesmo apontados pelo IDE antes mesmo de tentar executar o programa para testá-lo.

2. Erros de execução (runtime)

Esses erros só aparecem quando o programa está rodando. Um exemplo clássico é a tentativa de divisão de um número por zero. O código-fonte parece correto, a aplicação roda normalmente, realiza cálculos com precisão, até que… bum!,  a execução para bruscamente quando uma tentativa de divisão por zero ocorre, podendo ocasionar desde a parada da execução da aplicação até o travamento completo do sistema.

3. Erros semânticos (ou de lógica)

São os mais traiçoeiros e difíceis de detectar. O programa roda, executa tudo sem travar, apresenta a saída para o usuário, mas os resultados estão errados — e às vezes ninguém percebe. Um caso comum ocorre com determinados cálculos matemáticos – o sistema efetua os cálculos solicitados, mas por conta de um bug lógico o resultado apresentado é incorreto, e o usuário pode não perceber o problema.

Esse tipo de erro pode causar grandes transtornos, desde perdas financeiras até acidentes fatais.

Quando um bug deixa de ser só um incômodo

Se você acha que um bug é só um erro inofensivo que causa irritação, pense de novo. Bugs já causaram prejuízos bilionários e, em casos extremos, até mortes.

Citemos alguns exemplos notáveis:

• Nuclear Gandhi: No jogo Sid Meier’s Civilization (1991), um erro no sistema de agressividade das civilizações fazia com que o personagem do pacifista Mahatma Gandhi, inicialmente programado com o menor nível possível de agressividade, se tornasse extremamente beligerante após adoção de políticas democráticas. Devido a um underflow (valor abaixo do mínimo) no valor da variável, seu nível de agressividade era reduzido para um valor negativo, que acabava sendo interpretado como o valor máximo permitido.
  O resultado: um Gandhi obcecado por armas nucleares — um bug icônico da história dos games. Divertido? Sim. Mas ainda um bug.
• Therac-25: Entre 1985 e 1987, um equipamento de radioterapia de nome Therac-25, usado no tratamento de câncer, apresentou falhas críticas causadas por erros de programação em seu sistema de controle. Devido à ausência de verificações adequadas e à confiança excessiva em software, o dispositivo permitia que doses de radiação muito acima do limite seguro fossem aplicadas nos pacientes em tratamento.
  Seis pacientes morreram por exposição acidental a níveis fatais de radiação. 
• Mars Climate Orbiter: Em setembro de 1999, a NASA perdeu contato com a sonda Mars Climate Orbiter pouco antes de sua inserção na órbita do planeta Marte. A falha ocorreu porque um módulo do software produzia dados de impulso na unidade libras-força (sistema imperial), enquanto outro módulo esperava receber esses dados em newtons (sistema métrico).
  A ausência de conversão entre unidades resultou em um erro de trajetória fatal, fazendo com que a sonda descesse demais na atmosfera marciana e fosse destruída. O prejuízo estimado ultrapassou US$ 327 milhões.
• Guitar Hero II: Em 2007, uma atualização lançada para o jogo Guitar Hero II em sua versão para o console Xbox 360 causou problemas sérios de estabilidade em diversos aparelhos. Alguns dispositivos passaram a apresentar falhas críticas após a atualização, incluindo travamentos frequentes e, em muitos casos, o temido “Red Ring of Death” (Anel Vermelho da Morte) — um erro fatal de hardware que inutilizava o console. Embora o bug fosse de software, seu impacto foi sentido no hardware, resultando em muitas unidades defeituosas.

Máquina para tratamento de câncer Therac-25

Como lidar com bugs: a arte da depuração

O processo de encontrar e corrigir bugs é conhecido como debugging (em português, depuração). Ferramentas chamadas depuradores (ou debuggers) ajudam a examinar o código linha por linha, inspecionar variáveis e identificar o ponto exato em que tudo começa a dar errado.

Ambientes de desenvolvimento (IDEs) modernos geralmente vêm com depuradores embutidos, tornando essa tarefa um pouco menos ingrata e mais fácil de realizar.

Prevenção de bugs: manipulação de exceções

Outro recurso fundamental é o tratamento de exceções. Trata-se de prever que algo pode dar errado (como dividir um número por zero em um cálculo) e preparar o programa para lidar com isso de forma antecipada, sem falhar completamente. Linguagens de alto nível como Java, Python e C# têm mecanismos específicos para isso, como os blocos try…catch.

Exemplo em Java:

import java.util.Scanner;
public class Divisao {
  public static void main(String[] args) {
    Scanner entrada = new Scanner(System.in);
    System.out.print("Digite o valor de a: ");
    int a = entrada.nextInt();
    System.out.print("Digite o valor de b: ");
    int b = entrada.nextInt();
    int c = a / b; // BUG EM POTENCIAL: pode lançar ArithmeticException se b = 0
    System.out.println("Resultado = " + c);
    entrada.close();
  }
}

Neste exemplo, se o usuário digitar o valor zero ao entrar com o valor de b, será feita uma divisão por zero ao executar o cálculo da variável c. Qualquer outra divisão funcionará, exceto essa.

Ou seja, se b for igual a zero, o programa lançará uma exceção do tipo ArithmeticException e será encerrado abruptamente. Esse é um exemplo clássico de erro de tempo de execução (runtime error), causado por não tratar uma condição excepcional comum.

Como tratar isso? Uma solução é realizar a manipulação dessa exceção, como segue:

import java.util.Scanner;
public class DivisaoSegura {
  public static void main(String[] args) {
    Scanner entrada = new Scanner(System.in);
    System.out.print("Digite o valor de a: ");
    int a = entrada.nextInt();
    System.out.print("Digite o valor de b: ");
    int b = entrada.nextInt();
    try {
      int c = a / b;
      System.out.println("Resultado = " + c);
    }
    catch (ArithmeticException e) {
      System.out.println("Não é possível dividir por zero.");
      System.out.println(e);
    }
    entrada.close();
  }
}

Neste caso a exceção (erro) ArithmeticException foi tratada por meio do uso de um bloco try .. catch, que impedirá o travamento do sistema caso seja fornecido o valor zero à variável b, exibindo em vez disso a mensagem mais amigável “Não é possível dividir por zero” ao usuário..

Testes: prevenindo problemas

A melhor forma de combater bugs é evitá-los desde o início. Testes de software — tanto manuais quanto automatizados — são parte essencial do desenvolvimento. Eles verificam se o programa atende aos requisitos e ajudam a identificar falhas antes que elas possam causar estragos maiores.

Entre os tipos de testes mais comuns estão:

• Testes unitários: verificam o funcionamento de partes específicas do código.
• Testes de integração: checam se os módulos interagem corretamente.
• Testes de sistema: avaliam o sistema como um todo.
• Testes de aceitação: garantem que o software atende ao que o cliente espera.

Bugs no mundo real: onde menos se espera

É importante lembrar que nem só de software vive o mundo dos bugs. Hardware também pode apresentar falhas semelhantes, como erros de projeto em placas, aquecimento excessivo ou falhas elétricas. Mas no fim das contas, tudo parte da mesma raiz: uma falha humana durante a concepção ou implementação de um projeto.

Conclusão: errar é humano, depurar é essencial

Bugs fazem parte da vida de qualquer programador. Não há como evitá-los completamente, mas é possível preveni-los, detectá-los rapidamente e corrigi-los antes que causem problemas sérios.

Com boas práticas de codificação, testes constantes e ferramentas adequadas, dá para dormir mais tranquilo. Ou ao menos, sem sonhar com mariposas voando entre os relés.

Colabore com a Bóson Treinamentos

Ajude o canal adquirindo meus cursos na Udemy:

• Bancos de Dados com MySQL Básico: https://bit.ly/35QdWE4
• Lógica de Programação com Português Estruturado: https://bit.ly/3QKPn22
• Programação em Python do Zero: https://bit.ly/python-boson

Adquira também livros e outros itens na loja da Bóson Treinamentos na Amazon e ajude o canal a se manter e crescer: https://www.amazon.com.br/shop/bosontreinamentos

O post O que é um bug em programação? apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Aprender novas linguagens de programação é uma tarefa comum na carreira de um desenvolvedor de software. Comumente precisamos usar linguagens diferentes em novos projetos, e algumas áreas da tecnologia se beneficiam do emprego de linguagens específicas, que possuem recursos mais adaptados a determinadas tarefas, como Ciência de Dados, Computação em Nuvem, Automação de Tarefa e outras.

Vamos falar neste artigo sobre uma categoria de linguagens muito especial- as linguagens de programação funcional, que são muito empregadas nas áreas supracitadas, entre outras. Mas antes, vamos entender oque é programação funcional.

O que é Programação Funcional?

Programação funcional é um paradigma na programação no qual podemos executar toda a codificação de uma aplicação usando apenas funções (matemáticas). Ao contrário de paradigmas como a programação orientada a objetos, na programação funcional nos preocupamos apenas com “o que é” em vez de “como” resolver um problema.

Com a programação funcional, aprender novas ferramentas, paradigmas e perspectivas é um processo mais suave e simples e geralmente resulta em um código mais limpo e organizado.

Assim, podemos dizer que linguagens de programação funcional oferecem uma forma “compacta” de programação. Alguns dos recursos oferecidos por essas linguagens incluem o reuso de código e as melhorias de eficiência resultantes, uma legibilidade comparativamente melhor e uma sintaxe bastante simples de depurar.

Além disso, a maioria das linguagens de programação funcionais se integram e trabalham muito bem em tarefas voltadas à ciência de dados.

Vamos às 7 linguagens de programação funcional recomendadas que podem ser úteis em sua carreira como programador, e que valem a pena aprender neste ano.

7 Linguagens de Programação Funcional

1. Clojure

Linguagem de programação de uso geral, compatível com Java Virtual Machine (JVM) e que evita duplicação durante chamadas ao Java. É altamente acessível e interativa para um estilo de programação multithread. Apesar de ser uma linguagem compilada, oferece vários recursos importantes que são suportados em tempo de execução.

Site oficial: https://clojure.org/

2. Elixir

Uma linguagem de programação que suporta concorrência elevada e com baixa latência, é comumente empregada na construção de aplicativos escaláveis ​​e versáteis, com suporte adicional para baixa latência e tolerância a falhas.

Caso você precise projetar um aplicativo para atender a uma grande quantidade de solicitações, Elixir é uma linguagem altamente recomendada, por combinar os melhores recursos e características de linguagens como Clojure, Erlang e Ruby, oferecendo suporte a aplicações com threads múltiplas (multithread).

Site oficial: https://elixir-lang.org/

3. Haskell

O Haskell é uma linguagem de programação funcional avançada, com uma sintaxe declarativa e que pode ser digitada estaticamente. Isso significa que se trata de uma linguagem do tipo de compilação, e essa linguagem fornece mensagens de erro quando a sintaxe está errada, auxiliando muito o processo de debugging do código.

No geral, é empregada na criação de programas de alto desempenho, pois é excelente no quesito otimização. A avaliação dos argumentos facilita a composição abrangente e um melhor controle dos construtos.

Site oficial: https://www.haskell.org/

4. Scala

A linguagem Scala combina recursos tanto de linguagens estáticas quanto de linguagens dinâmicas, sendo usada para criar pipelines de dados e projetos de Big Data. Possuindo um ecossistema gigante de bibliotecas, seus tipos estáticos ajudam a evitar bugs em aplicações complexas.

Muito compatível com Java e a JVM, fornece programação totalmente funcional com funções classificadas como objetos de primeira classe.

Site oficial: https://www.scala-lang.org/

5. Elm

A linguagem Elm, não tão conhecida quanto as outras nessa lista, é mais adequada para a criação de aplicativos Web e também apps HTML, e possui características interessantes como refatoração bastante simplificada, pois ela possui um compilador muito inteligente.

Alimentados por uma estrutura bem arquitetada, os aplicativos em Elm são renderizados muito rapidamente.

A linguagem possui alta interoperabilidade com JavaScript e permite leitura fácil de seu código, podendo ser aplicada a diferentes projetos sem a necessidade de refazer o padrão que o código possuía anteriormente.

Site oficial: https://elm-lang.org/

6. F#

O F# (“F sharp“) é uma linguagem de programação de código aberto e multiplataforma, usada principalmente para escrever código robusto. Trata-se de uma versão funcional da linguagem C# (da Microsoft) e possui uma sintaxe fácil de entender. Possui suporte a correspondência de padrões e programação assíncrona com um conjunto diversificado de tipos de dados.

O F# pode realizar transformação de dados com a ajuda de funções porque segue um paradigma de programação funcional orientado a dados.

Site oficial: https://fsharp.org/

7. Erlang

O Erlang é uma linguagem de programação orientada a processos que emprega usa processos leves. A beleza desta linguagem está em sua capacidade de criar funções que se comunicam entre si.
É considerada a melhor linguagem de programação para aplicações baseadas em mensagens, como por exemplo aplicativos de bate-papo (chat apps), filas de mensagens e aplicativos da blockchain.

Os programas escritos em Erlang acabam sendo altamente responsivos devido ao gerenciamento automatizado de armazenamento e coleta de lixo (garbage collection) da linguagem implementados por processo.

Site oficial: https://www.erlang.org/

Referências

Adaptado de https://www.analyticsinsight.net/top-10-functional-programming-languages-to-know-in-2022/

O post 7 Linguagens de Programação Funcional para aprender em 2022 apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Programação de computadores é uma tarefa que pode ser altamente complexa, cheia de detalhes minuciosos, e altamente propensa a erros. E, no geral, a maioria dos problemas associados a software se refere a código mal escrito, que não segue normas ou padrões, e que foi criado sem o devido cuidado. Em outras palavras, boa parte dos bugs em software são causados pelos próprios desenvolvedores – evidentemente, sem intenção.

Por isso é essencial prestar a máxima atenção ao trabalho realizado quando um software ou sistema de softwares é construído. Muitos problemas podem ser evitados se algumas regras simples forem seguidas desde o início do ciclo de vida de desenvolvimento de um software.

A seguir listamos sete erros comuns que são cometidos com frequência por programadores, e que podem – e devem –  ser evitados desde o início.

Erros comuns ao desenvolver software

1. Não planejar antes de começar a codificar.

Os programas devem ser planejados de antemão – é para isso que serve a fase de análise. A coleta de requisitos, avaliação, pseudocódigos, fluxogramas, são todas ferramentas e técnicas que auxiliam no planejamento de como o software deverá ser desenvolvido na sequência, e que impactam significativamente todo o processo.

Software mal planejado significa, invariavelmente, software que precisará ser reescrito futuramente – e o impacto disso se dá no tempo de desenvolvimento estendido, custo do produto aumentado e, muito comumente, na (má) imagem passada pelo desenvolvedor ou empresa que desenvolve o software aos clientes.

2. Não escrever código limpo.

O código deve ser legível, seguir boas práticas de programação e de padrões de projetos (design patterns), ser organizado e bem-formatado.

Isso inclui usar uma convenção de nomes adequada para variáveis, métodos, eventos, funções, etc.. Os nomes devem expressar a intenção do elemento representado, serem inequívocos, claros e o mais sucintos possível.

Além disso, é importante documentar o código por meio de comentários (mas sem exagero – não escreva um livro dentro do código-fonte!).

Como disse Martin Fowler, autor e desenvolvedor que ajudou a criar o Manifesto para o Desenvolvimento de Software Ágil:

“Qualquer idiota pode escrever um código que um computador consegue entender. Bons programadores escrevem código que os humanos conseguem entender.”

A qualidade do código é sempre fundamental.

Dica de leitura sobre o assunto (link afiliado):

3. Reinventar a roda.

É sempre tentador e desafiador criar nossos próprios algoritmos e bibliotecas, como algoritmos de busca, ordenação, bibliotecas de cálculos e funções variadas. Mas isso, normalmente, é altamente trabalhoso, toma um grande tempo de nosso trabalho, e pode acarretar a inserção de erros variados nos programas que estamos criando. Obviamente precisamos escrever código para nossos projetos, mas se algumas das funcionalidades que necessitamos já existem, na forma de código já pronto, talvez seja uma melhor opção usá-los.

Tente, sempre que possível, usar as bibliotecas e classes escritas por terceiros, pois no geral trata-se de código escrito e otimizado por um grupo de profissionais, cuja probabilidade de apresentar erros é baixa, e assim você poupa um tempo enorme ao não precisar escrever código que já existe pronto e testado.

Além, é claro, da alta probabilidade de seu próprio código apresentar uma série de falhas e bugs.

Reuso de código é a regra!

4. Não realizar testes e não pensar em manipulação de erros no código.

Se o programa funciona para você, não significa que irá funcionar sempre para o usuário – talvez haja alguma falha oculta, ou uma maneira específica de usar a aplicação que traga à tona problemas não previstos. Melhor detectar, tratar e eliminar essas possíveis falhas antes de entregar o produto ao usuário, para evitar problemas mais graves e custosos.

Para tal você deve lançar mão de ao menos duas técnicas: a manipulação de exceções (erros) dentro do código, e a realização de testes de software, dos mais variados tipos (unitários, de integração, etc.).

Pode ser trabalhoso (e aparentemente custoso) escrever rotinas de testes ou de manipulação de exceções, mas muito menos do que corrigir bugs em software já finalizado e em produção (além de ser, no final das contas, mais barato).

5. Somente copiar e adaptar código, sem entender como ele funciona

É extremamente comum, em desenvolvimento de software, que o programador procure trechos de código e algoritmos em sites de busca (como o famoso Stack Overflow), e use os códigos encontrados em sua aplicação, tentando adaptá-los.

Até aí, nenhum problema – afinal, isso é uma espécie de “reuso de código” por meio de compartilhamento. O problema surge quando o programador não procura realmente entender como o código opera – quais as ideias empregadas, técnicas específicas da linguagem, como a lógica foi organizada. Isso impede que o profissional aprenda com o exemplo e seja capaz de, futuramente, escrever por si próprio código sem a necessidade de “copiar e colar”.

Use os códigos compartilhados na Internet à vontade, mas procure aprender como eles foram feitos para que você também seja capaz de escrevê-los – afinal, para que os algoritmos compartilhados existam é necessário que alguém saiba como fazê-los – e esse alguém pode ser você, em algum momento.

6. Não efetuar backup de seus arquivos-fonte.

O backup é de crucial importância, e isso se aplica a quem trabalha com desenvolvimento, e também a quem trabalha com tecnologia em geral, e mesmo a quem não trabalha diretamente com tecnologia, mas usa computadores em suas atividades.

Além de backups (local/nuvem), aprenda a usar sistemas de controle de versão, como o Git ou SVN (Github é um ótimo começo).

Por exemplo, assista ao Minicurso de Git da Bóson Treinamentos em Tecnologia no YouTube para uma introdução ao assunto de controle de versão:

Leitura recomendada (link afiliado):

E por último, mas não menos importante:

7. Não praticar todos os dias (ou quase todos).

Programação é uma atividade prática, que envolve o emprego de uma série de conhecimentos, ferramentas e técnicas, muitas vezes de alta complexidade, e somente a prática constante e focada pode garantir seu aprendizado adequado e o desenvolvimento satisfatório de código funcional, em tempo hábil, e com poucos erros.

Além disso, como em tecnologia em geral o aprendizado é constante, devido à velocidade na qual as tecnologias são desenvolvidas e atualizadas, a necessidade de prática de forma sistemática se torna ainda mais evidente.

Como disse o famoso cientista da computação Alan Turing:

“Programação é uma habilidade adquirida pela prática e pelo exemplo, e não por meio de livros.”

Conclusão

Evitar que erros ocorram durante o desenvolvimento de software é uma tarefa desafiadora, mas há muitas formas de minimizarmos problemas, desde que sejam seguidas algumas recomendações simples, como as apresentadas neste artigo.

O post 7 erros que todo programador deve evitar ao desenvolver software apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Artigo complementar do Curso Completo de Modelagem de Dados da Bóson Treinamentos no YouTube.

Neste artigo vamos explorar um tópico de elevada importância em modelagem de dados: o conceito de chaves e seus tipos, com algumas dicas de como determinar chaves primárias e estrangeiras em uma tabela, e exemplos.

O que são Chaves em Bancos de Dados

Uma chave consiste em uma ou mais colunas combinadas de uma relação (tabela) cujos valores são usados para identificar de forma exclusiva uma linha ou um conjunto de linhas relacionadas.

Uma chave pode ser única, ou seja, identifica uma única linha em uma tabela, ou ainda não-única, permitindo identificar um conjunto de linhas (registros). A seguir listamos as chaves de acordo com essa classificação:

• Chaves Únicas: Chave Candidata, Chave Composta, Chave Primária, Chave Surrogada (ou ChaveSubstituta), Chave Alternativa
• Chave Não-Única (Non-Unique): Chave Estrangeira

Vamos detalhar um pouco mais cada tipo de chave a partir de agora.

Chave Candidata

• Atributo ou grupo de atributos com o potencial para se tornarem uma chave primária.
• Uma chave candidata que não seja usada como chave primária será conhecida como Chave Alternativa.

Exemplos: Os campos Num_Matrícula e CPF em uma tabela de registro de alunos são chaves candidatas, pois podem ser usados como chave primária.

Chave Primária

• É achave candidata escolhida para ser a chave principal na relação.
• A chave primária identifica de forma exclusiva os registros em uma tabela, não podendo haver repetição de valores nem tampouco valor nulo neste campo.
• Em inglês Primary Key / PK

Podemos indicar uma chave primária em um modelo de dados com um #, por exemplo #Cod_Livro, ou ainda sublinhando o nome do campo, como Cod_Livro.

Chave Estrangeira

• Uma chave estrangeira é uma coluna de uma tabela que estabelece um Relacionamento com a Chave Primária (PK) ou coluna unique de outra tabela relacionada.
• É a partir da chave estrangeira (Inglês: Foreign key / FK) que sabemos com qual registro em uma tabela B um registro em uma tabela A está relacionado. Assim, por exemplo, é possível saber qual livro foi vendido, em um sistema de uma livraria, pois o campo Cod_Livro (chave primária em uma tabela de cadastro de livros) estará presente em uma tabela de registro de vendas como chave estrangeira, apontando para o registro do livro especificado.

Chave Composta

• Trata-se de uma chave que é composta de dois ou mais atributos (colunas) combinados, formando uma combinação única, cujos valores nunca se repetem (mas podem se repetir isoladamente).
• Uma chave composta geralmente é empregada quando não é possível utilizar uma única coluna de uma tabela para identificar de forma exclusiva seus registros.

Chave Surrogada ou Chave Substituta

• Uma chave surrogada é um valor numérico, único, adicionado a uma relação para servir como chave primária, quando nenhuma chave candidata for identificada.
• Não possui significado para os usuários e geralmente fica escondida nas aplicações.
• As chaves substitutas são frequentemente usadas no lugar de uma chave primária composta, para simplificação dos relacionamentos.

Instruções para criação de chaves primárias e estrangeiras

Podemos seguir algumas recomendações simples para identificar e criar chaves primárias e chaves estrangeiras em uma tabela, como por eexmplo:

• Não é possível haver valores duplicados em uma chave primária
• No geral, não é possível alterar o valor de uma chave primária
• Chaves estrangeiras são baseadas em valores de dados, classificadas como ponteiros lógicos
• Um valor de uma chave estrangeira deve corresponder a um valor existente em uma chave primária associada (ou valor de chave única). Caso contrário, deve ser nulo (NULL)
• Uma chave estrangeira deve referenciar uma chave primária ou uma coluna de chave única.

Exemplo de chave primária e chave estrangeira

No exemplo a seguir temos três tabelas relacionadas: tbl_Clientes, tbl_Vendas e tbl_Produtos. A tabela de vendas possui duas chaves estrangeiras, que a relacionam com as tabelas de clientes e de produtos, permitindo assim saber qual produto está incluído na venda, e para qual cliente esse produto foi vendido.

O conceito de Domínio

• O conceito de Domínio em bancos de dados nos permite definir os tipos de dados usados em cada campo de uma tabela ou relação.
• Também permitem especificar valores que são válidos em um campo, de acordo com o tipo de dado e intervalo de valores possível para o tipo.

Conclusão

O conceito de chaves e seus tipos é de crucial importância no desenvolvimento de bancos de dados, pois a partir da determinação do campos que serão chaves primárias e estrangeiras é que poderemos estabelecer os relacionamentos entre as tabelas, em um modelo relacional.

Próximo: Cardinalidades em Relacionamentos

O post Modelagem de Dados – Tipos de Chaves apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Neste artigo vamos falar sobre um dos cursos mais procurados na área de tecnologia: o curso de Análise e Desenvolvimento de Sistemas (ou simplesmente Análise de Sistemas), e o que um Analista faz como profissional de tecnologia.

Tipo de curso

Este é um curso de Nível Superior em Tecnologia (tecnólogo), ou seja um curso de curta duração que lhe permitirá obter uma graduação (faculdade) e seguir carreira na área da Tecnologia da Informação (T.I.).

O que faz um Analista de Sistemas?

O Analista de sistemas projeta, desenvolve, codifica, documenta e implanta programas e sistemas para empresas. Também pode realizar auditoria de sistemas já existentes, testar softwares para descobrir erros e falhas, projetar e gerenciar bancos de dados e atualizar / melhorar programas existentes.

Pode trabalhar como funcionário em uma empresa ou ainda prestar consultoria, por conta própria ou por meio de empresas especializadas.

Duração do curso

Em torno de 2 a 3 anos (4 a 6 semestres), podendo variar em função de período ou da instituição. É oferecido tanto em modalidade presencial quanto EAD.

O que é importante saber – aptidões

O aluno que estuda análise e desenvolvimento de sistemas precisa ter bom raciocínio lógico e facilidade com matemática e cálculos, além, é claro, de gostar de computadores. Curiosidade é um aspecto importante, pois muitas vezes é necessário descobrir novas formas de resolver problemas, além do gosto pelo aprendizado, que nesta área é contínuo e de longo prazo.

Conhecer outras áreas também é importante, como economia, administração e contabilidade, pois é comum que se desenvolvam sistemas e software para essas áreas.
Saber outro idioma, principalmente o inglês, é um diferencial enorme, pois boa parte da literatura e cursos estão nessa língua.

Saber se relacionar e lidar com público, além do trabalho em equipe, são fundamentais, pois o analista precisa saber se comunicar com clientes, usuários e outros stakeholders durante o processo de desenvolvimento de software.

Apesar disso, não há necessidade de saber programar nem tampouco de ter conhecimentos específicos em informática para começar a cursar essa faculdade. O aluno aprenderá tudo o que ele precisa, desde como funciona um computador e como usar um editor de textos até programação em linguagens específicas e tópicos de engenharia de software.

Grade Curricular Geral

As disciplinas mais comuns encontradas nos diversos cursos de tecnologia em análise e desenvolvimento de sistemas incluem:

• Algoritmos e Lógica de Programação
• Arquitetura e Organização de Computadores
• Administração Geral
• Análise Orientada a Objetos e Modelagem de Sistemas
• Comunicação e Expressão
• Engenharia de Software
• Linguagens de Programação (variadas, como Java, C, Python, etc.)
• Estruturas de Dados
• Sistemas Operacionais
• Interface Humano-Computador (IHM)
• Programação para Web / Internet (inclui HTML, CSS, JavaScript, PHP)
• Desenvolvimento para dispositivos móveis e IoT
• Matemática e Estatística
• Redes de Computadores (básico)
• Segurança da Informação
• Modelagem e Projeto de Bancos de Dados
• Empreendedorismo
• Sistemas Distribuídos
• Gestão de Projetos
• Qualidade de Software
• Gestão e Governança de TI
• Microinformática

Com algumas pequenas variações, principalmente no tocante às disciplinas optativas ou eletivas, que os alunos podem escolher ao longo do curso.

Onde é possível trabalhar?

Basicamente, em todo local que fizer uso de sistemas informatizados – ou seja, em praticamente toda parte atualmente. Exemplos de empresas que mais necessitam de Analistas de Sistemas são instituições financeiras, industrias, hospitais, consultorias, concessionárias, etc.

O mercado para esse tipo de profissional está bastante aquecido e em constante crescimento, e oportunidades surgem em empresas de todos os tamanhos – pequeno, médio e grande porte, incluindo grandes multinacionais e empresas públicas.

Você cursa análise e desenvolvimento de sistemas ou é formado na área? Fale a respeito nos comentários logo abaixo! Eu, por exemplo, sou formado exatamente neste curso – portanto, sou analista de sistemas por formação.

Nos próximos artigos vamos trazer informações sobre outros cursos de graduação, pós-graduação e técnicos, como Sistemas de Informação, Ciência da Computação, Técnico em Informática, Tecnologia em Bancos de Dados e outros.

O post Perfil do Curso de Análise e Desenvolvimento de Sistemas apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Programação Orientada a Objetos – POO (Object-Oriented Programming – OOP) é um paradigma de programação que usa tipos de dados personalizados. Em vez de operar apenas com tipos de dados primitivos, podemos construir novos tipos de dados, conforme nossa necessidade.

Esses novos tipos de dados, que chamamos de classes, podem conter estruturas semelhantes a funções, denominadas métodos, e variáveis internas, chamadas de atributos. As classes dão origem a objetos, em um processo denominado instanciação.

Os objetos são os “blocos de construção” de software na OO.

Vantagens da Orientação a Objetos

• Fornece uma estrutura modular para a construção de programas
• Objetos podem ser reutilizados em aplicações diferentes
• O software se torna mais fácil de manter
• O desenvolvimento é mais rápido, devido ao reuso de código
• Encapsulamento: não é necessário conhecer a implementação interna de um objeto para poder usá-lo

Objeto

Trata-se de uma ocorrência específica de uma classe; é uma “instância de classe”.

Os objetos são a base da OO (Orientação a Objetos).

Os objetos representam entidades do mundo real, como aviões, pessoas, contas correntes, etc., mas também podem representar outros conceitos, como gráficos (círculos, quadrados, cones, esferas, etc.)

Um objeto possui características próprias (atributos) e executa determinadas ações (métodos), sendo esses atributos e métodos provenientes da classe que origina o objeto.

Abstração

Abstrair significa selecionar aspectos específicos de um problema a ser analisado, deixando de lado outros aspectos. É a  representação de uma entidade do mundo real na forma de idéias.

As entidades abstraídas podem se comunicar entre si, por meio da troca de Mensagens.

De acordo com o autor Correia (2006):

“Pelo princípio da abstração, nós isolamos os objetos que queremos representar do ambiente complexo em que se situam, e nesses objetos representamos somente as características que são relevantes para o problema em questão”.

Mensagens

Os objetos se comunicam a partir da troca de mensagens.

Uma mensagem é um sinal enviado de um objeto a outro, o qual requisita um serviço, usando uma operação programada no objeto chamado. Por exemplo, para que um objeto execute um método, é necessário enviar a este objeto uma mensagem solicitando a execução do método desejado.

As mensagens somente ocorrem entre objetos que possuem uma Associação.

As mensagens também são programadas. Quando uma mensagem é recebida, uma operação é invocada no objeto chamado.

Há vários formatos de mensagens: procedures (subs e functions), passagem de sinais entre threads, acionamento de eventos, etc.

O que são Classes

Uma Classe é uma coleção de objetos que são descritos com os mesmos atributos e as mesmas operações. Uma classe representa uma ideia ou conceito e classifica objetos que tenham propriedades similares.

As classes são os blocos de construção mais importantes dos sistemas orientados a objetos, e devem possuir responsabilidades bem definidas dentro da aplicação.

Uma classe é um tipo personalizado de dados.

Desta forma, uma classe é um tipo abstrato de dados, um “molde” para a criação de objetos. Cada classe criada se torna um novo tipo disponível para declarar variáveis e criar objetos

Por convenção, começamos o nome de uma classe com letra maiúscula, e capitalizamos cada palavra subsequente que o compuser.

As classes representam os blocos de construção mais importantes dos sistemas orientados a objetos, e devem possuir responsabilidades bem definidas dentro da aplicação.

Uma classe é como se fosse um tipo abstrato de dados, um “molde” para a criação de objetos.

Um objeto é, portanto, um “Instância de uma Classe”

As classes possuem atributos e métodos.  Atributos são características da classe, que são comuns a todos os objetos derivados, e que podem apresentar valores diversos. Já os Métodos são as operações possíveis em uma classe (nos objetos instanciados a partir dela).

Atributo de Classe

Ou Propriedade: Característica particular de uma ocorrência de uma classe, como por exemplo o nome e a idade de uma pessoa.

Existem dois tipos principais de propriedades:

• Estáticas: Mantém o mesmo valor durante toda a sua existência. Por exemplo, a data de nascimento de uma pessoa é uma propriedade estática, pois mantém o mesmo valor durante toda a existência do objeto instanciado.
• Dinâmicas: Podem ter valores que variam com o passar do tempo. A idade de uma pessoa pode ser considerada um atributo dinâmico, pois pode variar ao longo do tempo.

Método

É a lógica contida em uma classe para atribuir-lhe comportamentos. São as funções e procedimentos contidos na classe.

O ato de invocar um método é a passagem de mensagens para o objeto.

Toda classe possui um método especial chamado de método construtor, que inicializa o objeto instanciado.

As classes também usam métodos destruidores para finalizar os objetos após seu uso.

Um método é uma sequência de declarações (comandos) que possui um nome de identificação. É similar a uma função ou procedimento.

Um método possui um nome e um corpo onde ficam os comandos que serão executados quando o método for chamado, e também podem receber dados para processamento (parâmetros) e retornar informações.

Os métodos são a forma principal de passagem de mensagens entre objetos. Um método deve executar sempre uma operação única. Os métodos também precisam ter um tipo de retorno, que pode ser um tipo de valor, de referência ou ainda void (não retornam valor).

Classe – Notação UML para representação

A seguir temos a forma padrão para representação de uma classe usando um diagrama de classes UML:

Instância de Classe

É o objeto, uma ocorrência específica de uma classe.

As classes originam instâncias sob requisição, no processo denominado Instanciação. O projetista / analista cria a classe. A classe é então usada para criar objetos em tempo de execução.

Veja a seguir um exemplo de criação de classe na linguagem C#. É declarado um atributo da classe Caixa – lado – e um método – Volume():

Herança

Herança, em orientação a objetos, é a capacidade de um novo objeto tomar atributos e operações de um objeto existente.

Assim, podemos criar classes mais complexas sem que precisemos repetir código.

Aqui, a palavra-chave é Reuso de código, e é uma das metas a se atingir ao desenvolver software. O reuso permite reduzir o esforço dispendido no desenvolvimento de software ao reaproveitarmos códigos de uma classe na criação de outras classes.

A Herança é, portanto,  um conceito extremamente importante em Orientação a Objetos.

Usamos a herança, por exemplo, para evitar repetição ao definirmos classes com características em comum e que são relacionadas entre si.

A herança é um relacionamento entre classes, que permite que uma classe “adquira” os membros (atributos e métodos) de outra classe.

Um exemplo clássico de herança seria a classificação de mamíferos no reino animal.

Homens, Baleias e Gatos são mamíferos, que compartilham muitas características entre si, mas claramente possuem atributos que os diferem uns dos outros.

Como podemos modelar Baleias, Gatos e Humanos em um software?

Podemos criar classes distintas para cada animal, mas essas classes teriam muitos comportamentos (“métodos”) em comum entre eles, como Respirar, Mamar e Reproduzir-se, o que ocasionaria repetição desnecessária de código.

Usamos então Herança para resolver esse problema. Podemos criar uma classe chamada Mamífero que possua as características comuns a todos os animais mamíferos, e então criar as classes Humano, Baleia e Gato herdando essas funcionalidades e também implementando as funcionalidades específicas de cada animal, como Falar, Nadar e Miar.

O quadro a seguir mostra duas classes, Humano e Gato, que herdam os atributos e métodos da superclasse Mamífero, e implementam seus próprios atributos e métodos adicionais: atributos nome e sobrenome e métodos andar() e falar() para a classe Humano, e os atributos raça e nome e métodos andar() e miar() para a classe Gato:

Encapsulamento

Encapsulamento é a combinação de atributos e operações dentro de uma classe, deixando visível apenas o que é necessário para a comunicação entre dois objetos, como por exemplo alguns detalhes da implementação ou ainda a lógica de um método.

O encapsulamento permite ocultar a complexidade do código. Não é necessário entender como a operação funciona para poder utilizá-la. Um exemplo clássico é o de um motorista conduzindo um veículo. O motorista não precisa saber exatamente como um motor funciona internamente para poder dirigir o automóvel – o detalhes da “implementação” do motor ficam ocultos do motorista.

O encapsulamento protege os dados, permitindo o acesso a eles apenas a partir de métodos específicos e autorizados.

Desta forma, os objetos encapsulados podem ser comparados uma caixa preta: conhecemos  asua interface externa, porém não precisamos nos preocupar com o que acontece internamente na caixa.

Encapsulamento – Níveis de Acesso

Há três níveis principais de acesso dos objetos:

• Público
• Privado
• Protegido

Vamos discutir em mais detalhes esses níveis de acesso em uma lição especial sobre o assunto.

Polimorfismo

Uma operação de um objeto qualquer pode assumir vários comportamentos dependendo da chamada recebida, tratando e devolvendo respostas ao chamador.

Poli = Muitos; Morphos = Formas. Portanto, Polimorfismo = “múltiplas formas”.

Portanto, o polimorfismo ocorre quando um objeto tem um comportamento diferente para uma mesma ação. Por exemplo, usando nosso exemplo de classes de animais, nas classes Gato e Humano existe um comportamento (método) em comum: Andar. Porém, cada uma dessas classes implementa o método Andar de forma diferente – os gatos andam em quatro patas, enquanto os humanos andam em duas. Ambos podem percorrer a mesma distância andando, ou seja, executando o método andar, mas o farão de forma diferente entre si.

Então, dependendo de como um método é invocado, seu comportamento será diferente.

Neste artigo publicamos uma pequena introdução à Orientação a Objetos. Nos próximos artigos desta série vamos nos aprofundar nesses assuntos, e apresentar muitos outros conceitos relativos a esse tópico.

O post Conceitos de Programação Orientada a Objetos apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.

Olá pessoal! Neste artigo vou explicar, de forma sucinta, alguns dos principais conceitos presentes na disciplina de Programação Orientação a Objetos. Meu intuito não é o de me aprofundar nesses conceitos, mas sim de apresentá-los inicialmente, como uma espécie de sumário, de modo a apresentar e esclarecer algumas ideias fundamentais da matéria.

Posteriormente vamos nos aprofundar em cada conceito, inclusive com exemplos de aplicações nas linguagens de programação mais comuns da atualidade.

Definição

Programação Orientada a Objetos – POO (Object-Oriented Programming – OOP) é um método de programação (estilo) que usa tipos de dados personalizados. Em vez de operar apenas com tipos de dados primitivos, podemos construir novos tipos de dados, conforme nossa necessidade (necessidade da aplicação).

Esses novos tipos de dados, que chamamos de classes, podem conter estruturas semelhantes a funções, denominadas métodos, e variáveis internas, chamadas de atributos.

As classes são estruturas semelhantes a strucutures e unions, utilizadas em programação estruturada, porém tem características diferenciadas, como:

• Classes possuem suas próprias funções (métodos)
• Podem ter dados privados ou protegidos
• Podem herdar características de outras classes para absorver sua funcionalidade
• Cada classe pode agir como se fosse uma entidade completamente separada do resto do programa

Uma das principais ideias em orientação a objetos é o conceito de Abstração, que consiste em esconder do usuário os detalhes de um processo. Em OOP, o programador (que é o usuário) não precisa conhecer todos os detalhes de implementação intrincados de uma classe, basta que saiba como utilizá-la em seu programa.

Membros de Classe

Existem dois tipos de membros (elementos internos) em uma classe: atributos e métodos.

• Atributos: “Conteineres” onde um objeto armazena dados, de forma similar a Variáveis. Armazenam informações sobre um objeto. Por exemplo, um objeto “Pessoa” pode ter um atributo “Nome” e um atributo “Altura” para armazenar essas duas propriedades de uma pessoa em particular.
• Métodos: São funções e procedimentos vinculados a um objeto, as quais permitem que o objeto realize (ou sofra) ações. Por exemplo, um objeto Pessoa pode ter os métodos “andar()”, “comer()” e “dormir()”, que descrevem como essas ações são realizadas. Note o uso dos parênteses para descrever o nome do método.

Tipos de linguagens OO (Orientadas a Objetos)

Existem, fundamentalmente, dois tipos de linguagens orientadas a objetos:

• OO Suportada: Tratam-se de linguagens procedurais que possuem um componente de programação OO inserido. Como exemplos, podemos citar as linguagens PHP, Visual Basic, COBOL e Objective C.
• OO Pura: São linguagens nativamente orientadas a objetos, como Java, Scala, Smalltalk e C#. Algumas dessas linguagens, como o Java, possuem alguns elementos procedurais disponíveis.

Níveis de acesso

Os níveis de acesso em uma classe determinam a visibilidade de seus componentes (métodos e atributos). Temos três níveis de acesso no geral:

• Público: Elementos acessíveis a todo o código da aplicação, em toda a parte.
• Privado: Um elemento privado pode apenas ser acessado pelo próprio objeto (internamente) ou por funções “amigáveis”.
• Protegido: Um elemento protegido somente é acessível pelo próprio objeto e por objetos herdeiros dele.

Além disso, o acesso pode ser classificado em:

• Acesso em nível de classe (estático): Os membros pertencem ao objeto, e não à instância
• Acesso em nível de instância (não-estático): Os membros pertencem À instância e não ao objeto.

As instâncias não possuem os métodos e atributos estáticos do objeto que representam.

Métodos Construtor e Destrutor

Tratam-se de dois métodos especiais que possuem funções bem-definidas em um objeto.

• Método Construtor: É um método que é executado automaticamente quando uma classe é instanciada (objeto é criado), sendo utilizada normalmente para inicializar determinados atributos do objeto. Pode aceitar parâmetros para criar um objeto de forma personalizada, e permite a manipulação de campos (atributos) estáticos.
• Método Destrutor: Este método é executado automaticamente quando uma instância existente de uma classe (objeto) é destruída (eliminada da memória). Também manipula atributos estáticos.

Setters e Getters

Um Setter é um método especial que permite configurar indiretamente valores dentro de um objeto (atributos). 

Um Getter é outro método especial, usado para obtermos de forma indireta os valores armazenados dentro do objeto.

Ambos previnem o acesso direto à informações privadas do objeto, permitindo o acesso controlado aos dados.

Polimorfismo

O conceito de Polimorfismo é a habilidade em uma linguagem de permitir que múltiplos tipos da dados apareçam e sejam utilizados como outro tipo. Podemos classificar as linguagens de duas formas com relação a tipos de dados:

• Fortemente tipada: Os tipos de dados sempre derivam de um outro tipo.
• Fracamente tipadas: Os tipos de dados são implicitamente polimórficos.

Para que serve o polimorfismo?

• Desenvolvedores não precisam conhecer os tipos de dados (internamente) ao codificar.
• Os tipos de dados serão reconhecidos e manipulados em tempo de execução (processo denominado dynamic binding)
• Tipos diferentes de dados podem compartilhar os mesmos operadores, por meio de um processo chamado de Sobrecarga de Operadores.

Com a sobrecarga de operadores, uma mesma classe pode fornecer múltiplos métodos para manipular diferentes operadores.

O polimorfismo permite, por exemplo, que as funções de atributos ou métodos sejam modificados quando uma classe é criada herdando de outra classe-pai. Esse é um dos pilares da Programação Orientada a Objetos.

Sobrecarga de Métodos

Podemos também sobrecarregar métodos, o que significa que podemos fornecer múltiplos métodos com uma variedade de parâmetros, tornando-os mais genéricos. Por exemplo, podemos ter um método que, ao receber duas strings, as concatena, formando uma terceira, mas se receber dois inteiros realiza sua soma em vez de concatená-los. 

Method Overriding

Este conceito diz respeito à substituição de um método em uma classe por uma função externa, quando de seu uso.

Os métodos que podem ser sobrescritos assim são chamados de Métodos Virtuais.

Recursão aberta

É a habilidade de uma linguagem de programação que permite o acesso a membros de uma instância do objeto. Tipicamente, é usada com palavras-chave específicas e construída em nomes de variáveis.

Por exemplo, temos palavras-chave como this, self, me, que são ponteiros para a instância real na qual eles são utilizados.

É isso aí! Vimos neste tutorial alguns conceitos iniciais importantes para o estudo de Programação Orientada a Objetos.

Na parte 02 deste tutorial vamos tratar de mais conceitos, como Delegates, Namespaces e Encapsulamento, entre outros.

O post Conceitos gerais de Programação Orientada a Objetos – 01 apareceu primeiro em Bóson Treinamentos em Ciência e Tecnologia.