
Olá, Perfil !!!

Os princípios KISS, YAGNI e DRY são fundamentais para ajudar os desenvolvedores a criar código limpo, eficiente e fácil de manter.

O princípio **KISS** sugere que a solução mais simples é frequentemente a melhor. Isso significa que os desenvolvedores devem buscar manter as coisas simples e diretas sempre que possível, evitando a complexidade desnecessária que pode dificultar a manutenção e o entendimento do código.

O princípio **YAGNI**, por sua vez, incentiva a criação apenas das funcionalidades necessárias no momento presente. Isso evita a criação de recursos que podem nunca ser utilizados, economizando tempo e recursos valiosos.

Já o princípio **DRY** sugere que as informações no código devem ser armazenadas em um único local e que cada parte do código deve ter uma única fonte de verdade. Isso evita a duplicação de código e a inconsistência de informações, facilitando a manutenção e evolução do código ao longo do tempo.

## KISS - Keep it simple, stupid

O princípio KISS ("Keep It Simple, Stupid", ou "Mantenha Simples, Estúpido") é um princípio de design que prega que a solução mais simples costuma ser a melhor. Ele pode ser aplicado em diversas áreas, desde a criação de produtos até a programação de computadores e gestão de projetos.

O princípio KISS parte da ideia de que a simplicidade é a chave para soluções eficazes e eficientes. Soluções complexas são difíceis de entender, implementar e manter, enquanto soluções simples são mais fáceis de entender e utilizar.

No entanto, é importante ressaltar que simplicidade não significa simplismo ou superficialidade. Uma solução simples pode ser elegante, robusta e sofisticada, desde que não seja acrescida de elementos desnecessários que possam prejudicar sua eficácia e eficiência.

Em síntese, o princípio KISS prega que devemos manter as soluções o mais simples possível, eliminando tudo que for desnecessário e mantendo apenas as funcionalidades essenciais. Dessa forma, é possível criar soluções eficazes, eficientes e de qualidade.

```javascript
// Exemplo não KISS
function calculateAverage(numberList) {
  let total = 0
  for (let i = 0; i < numberList.length; i++) {
    total += numberList[i]
  }
  return total / numberList.length
}

// Exemplo KISS
function calculateAverage(numberList) {
  const sum = numberList.reduce((total, num) => total + num)
  return sum / numberList.length
}
```

A função `calculateAverage` foi simplificada usando o método `reduce()` em vez de usar um `for` para somar os elementos da lista. Isso torna o código mais simples e fácil de entender.

## YAGNI - You Aren't Gonna Need It

O princípio YAGNI ("Você Não Vai Precisar Disso") é uma filosofia que preconiza que não devemos adicionar funcionalidades que não são estritamente necessárias no momento presente. O objetivo é evitar a complexidade desnecessária e o desperdício de tempo e recursos na criação de recursos que podem nunca ser utilizados.

Seguindo o princípio YAGNI, os desenvolvedores devem se concentrar nas funcionalidades essenciais e evitar adicionar recursos adicionais que podem ser úteis no futuro, mas que não são necessários no momento. Esses recursos extras podem incluir código redundante, bibliotecas desnecessárias ou recursos de interface de usuário que não são críticos para a funcionalidade principal.

```javascript
// Exemplo não YAGNI
function calculateAverage(numbersList) {
  if (numbersList.length > 0) {
    let total = 0
    for (let i = 0; i < numbersList.length; i++) {
      total += numbersList[i]
    }
    return total / numbersList.length
  } else {
    return 0
  }
}

// Exemplo YAGNI
function calculateAverage(numbersList) {
  if (numbersList.length > 0) {
    const sum = numbersList.reduce((total, num) => total + num)
    return sum / numbersList.length
  }
  return 0
}
```

A função `calculateAverage` foi simplificada, removendo o código desnecessário que tratava o caso em que a lista de números estivesse vazia. Isso reduz a complexidade e torna o código mais fácil de ler.

## DRY - Don't repeat yourself

O princípio DRY ("Don't Repeat Yourself", ou "Não Se Repita") é um princípio que sugere que as informações no código devem ser armazenadas em um único local e que cada parte do código deve ter uma única fonte de verdade. O objetivo do princípio DRY é reduzir a duplicação de código e evitar a inconsistência de informações, o que pode levar a problemas de manutenção e a bugs no software.

Seguindo o princípio, os desenvolvedores devem evitar copiar e colar código sem modificá-lo. Em vez disso, eles devem criar funções, classes ou bibliotecas reutilizáveis em todo o código. Isso torna o código mais fácil de manter e atualizar, já que as mudanças precisam ser feitas em apenas um lugar. Adicionalmente, ao evitar a duplicação de código, o tamanho do código é reduzido, tornando-o mais fácil de ler e entender.

```javascript
// Exemplo não DRY
function sum(a, b) {
  console.log(`A soma de ${a} e ${b} é ${a + b}`)
}

function subtract(a, b) {
  console.log(`A subtração de ${a} e ${b} é ${a - b}`)
}

function multiply(a, b) {
  console.log(`A multiplicação de ${a} e ${b} é ${a * b}`)
}

function divide(a, b) {
  console.log(`A divisão de ${a} e ${b} é ${a / b}`)
}

// Exemplo DRY
function operate(a, b, operator) {
  let result
  switch (operator) {
    case '+':
      result = sum(a, b)
      break
    case '-':
      result = subtract(a, b)
      break
    case '*':
      result = multiply(a, b)
      break
    case '/':
      result = divide(a, b)
      break
    default:
      console.log('Operador inválido')
      return
  }
  console.log(`O resultado da operação ${operator} entre ${a} e ${b} é ${result}`)
}
```

A função `operate` foi criada para evitar a duplicação de código que estava presente nas funções de `sum`, `subtract`, `multiply` e `divide`. Ao passar um operador para a função `operate`, é possível realizar qualquer uma dessas operações.

## Conclusão

Esses princípios são fundamentais para ajudar os desenvolvedores a escrever código mais legível, organizado e compreensível, o que resulta em software mais eficiente e fácil de manter ao longo do tempo. Quando aplicados corretamente, esses princípios podem melhorar significativamente a qualidade do código e reduzir a incidência de bugs e problemas de manutenção. Além disso, um código claro e limpo também facilita a colaboração entre os membros da equipe e pode tornar a introdução de novos desenvolvedores ao projeto muito mais fácil.

## Referências

- [SOLID, KISS, DRY, YAGNI: Desvendando esses princípios de código](https://awari.com.br/solid-kiss-dry-yagni/?utm_source=blog)
- [Princípios YAGNI, KISS e DRY](https://www.linkedin.com/pulse/princ%C3%ADpios-yagni-kiss-e-dry-emerson-romano/?originalSubdomain=pt)
- [Princípios Dry, KISS e YAGNI](https://www.linkedin.com/pulse/princ%C3%ADpios-dry-kiss-e-yagni-jeftar-mascarenhas/?originalSubdomain=pt)
- [O que são os princípios DRY, KISS e YAGNI?](https://pt.stackoverflow.com/questions/23052/o-que-s%C3%A3o-os-princ%C3%ADpios-dry-kiss-e-yagni)
- [KISS, YAGNI, DRY – three principles that every developer should know about](https://www.boldare.com/blog/kiss-yagni-dry-principles/)
- [What are YAGNI, DRY and KISS principles in software development?](https://www.educative.io/answers/what-are-yagni-dry-and-kiss-principles-in-software-development)
- [DRY, KISS, YAGNI | Code/Drops #27 - video](https://www.youtube.com/watch?v=5yJ_cAUrpQc)
- [Software Design Principles (Basics) | DRY, YAGNI, KISS, etc](https://workat.tech/machine-coding/tutorial/software-design-principles-dry-yagni-eytrxfhz1fla)
- [O que são os princípios DRY, KISS e YAGNI](https://blog.caioaugusto.dev/blog/principios-dry-kiss-yagni)


Princípios KISS, YAGNI e DRY


Olá, Perfil !!!

Vamos explorar os princípios SOLID e como eles podem ser aplicados em JavaScript para criar código mais limpo, modular e fácil de manter.

Os princípios SOLID são diretrizes de programação que podem ser utilizadas para desenvolver sistemas mais robustos e flexíveis. Neste artigo, apresentaremos exemplos práticos de como aplicar esses princípios no contexto do JavaScript.

Ao seguir esses princípios, você poderá criar um código mais escalável e fácil de manter. Se você busca desenvolver código de alta qualidade em JavaScript, este artigo é uma leitura valiosa para você.

## Princípios

- **Princípio da Responsabilidade Única (SRP):** Uma classe ou função deve ter apenas uma responsabilidade para manter o código mais flexível e fácil de manter.
- **Princípio Aberto/Fechado (OCP):** Uma classe deve estar aberta para extensão, mas fechada para modificação, tornando o código mais modular e menos propenso a erros.
- **Princípio da Substituição de Liskov (LSP):** Uma classe derivada deve poder ser usada no lugar de sua classe base sem afetar a correção do programa, garantindo consistência e reutilização do código.
- **Princípio da Segregação de Interface (ISP):** Um cliente não deve ser forçado a depender de métodos que não usa, mantendo o código mais modular e fácil de manter.
- **Princípio da Inversão de Dependência (DIP):** Módulos de alto nível não devem depender de módulos de baixo nível, em vez disso, ambos devem depender de abstrações, o que torna o código mais flexível e fácil de testar.

### Responsabilidade única (SRP)

Ao aplicar o princípio da Responsabilidade Única (SRP) em JavaScript, podemos criar um código mais modular, coeso e fácil de manter. Ao seguir esse princípio, garantimos que cada parte do código tenha uma única responsabilidade bem definida, o que aumenta a legibilidade e a qualidade do código. Isso torna a manutenção do código mais simples e reduz a possibilidade de efeitos colaterais indesejados. O SRP ajuda a evitar o acoplamento excessivo entre diferentes partes do sistema, facilitando o reuso e a atualização do código. Em resumo, a aplicação do SRP ajuda a criar um código mais organizado e eficiente.

```javascript
class TasksList {
  constructor() {
    this.tasks = []
  }

  addTask(task) {
    this.tasks.push(task)
  }

  removeTask(task) {
    const index = this.tasks.indexOf(task)
    if (index !== -1) {
      this.tasks.splice(index, 1)
    }
  }

  completeTask(task) {
    task.concluida = true
  }
}
```

No exemplo, a classe `TasksList` possui apenas uma responsabilidade, que é gerenciar as tarefas adicionadas a uma lista. A classe contém métodos específicos para adicionar, remover e marcar uma tarefa como concluída, garantindo que cada método tenha uma única responsabilidade bem definida. Essa abordagem torna a classe mais fácil de entender e manter, reduzindo a complexidade e tornando-a mais modular. Ao seguir o princípio da Responsabilidade Única, tornamos nosso código mais coeso e aumentamos a sua qualidade, evitando que a classe se torne excessivamente grande e difícil de entender.

### Aberto/Fechado (OCP)

Ao aplicar o princípio Aberto/Fechado (OCP) em JavaScript, podemos criar um código mais reutilizável e flexível. Ao seguir esse princípio, permitimos que as classes sejam estendidas sem precisar serem modificadas, tornando a manutenção do código mais fácil. Isso ajuda a garantir a qualidade e escalabilidade do código. A extensão de classes também ajuda a evitar a duplicação de código e promove a reutilização de código existente, tornando o desenvolvimento mais eficiente. Em resumo, ao aplicar o OCP, tornamos nosso código mais modular, extensível e fácil de manter, o que resulta em um código mais robusto e de alta qualidade.

```javascript
class Animal {
  constructor(name) {
    this.name = name
  }

  makeSound() {
    console.log(`${this.name} faz um som.`)
  }
}

class Dog extends Animal {
  constructor(name) {
    super(name)
  }

  makeSound() {
    console.log(`${this.name} late.`)
  }
}

class Cat extends Animal {
  constructor(name) {
    super(name)
  }

  makeSound() {
    console.log(`${this.name} mia.`)
  }
}

class Cow extends Animal {
  constructor(name) {
    super(name)
  }
}

class AnimalSoundMaker {
  constructor(animals) {
    this.animals = animals
  }

  makeSounds() {
    this.animals.forEach((animal) => animal.makeSound())
  }
}
```

A classe Animal é fechada para modificação, mas aberta para extensão. As classes `Dog`, `Cat` e `Cow` estendem a classe `Animal` e adicionam seus próprios sons. A classe `AnimalSoundMaker` recebe uma lista de animais e chama o método `makeSound` de cada animal. Esta classe não precisa ser modificada se um novo animal for adicionado, desde que o animal implemente o método `makeSound`.

### Substituição de Liskov (LSP)

Suponha que você tenha uma classe `Car` que define um carro genérico e uma subclasse `ElectricCar` que herda da classe `Car`. Ambas as classes têm um método `drive()` que controla a movimentação do carro correspondente.

De acordo com o princípio de substituição de Liskov, a subclasse `ElectricCar` deve ser substituível pela classe `Car` sem afetar a lógica. Isso significa que qualquer método que espera uma instância da classe `Car` deve poder trabalhar corretamente com uma instância da subclasse `ElectricCar`.

No entanto, se a implementação do método `drive()` na subclasse `ElectricCar` for diferente da implementação na classe `Car`, isso pode violar o princípio de substituição de Liskov.

A classe `Car` tenha a seguinte implementação do método `drive()`:

```javascript
class Car {
  constructor() {
    this.speed = 0
  }

  drive(speed) {
    this.speed = speed
    console.log(`Car is driving at ${this.speed} km/h`)
  }
}
```

E a subclasse `ElectricCar` tenha a seguinte implementação do método `drive()`:

```javascript
class ElectricCar extends Car {
  constructor() {
    super()
  }

  drive(speed) {
    if (speed > 100) {
      console.log('Electric car cannot drive that fast')
    } else {
      super.drive(speed)
    }
  }
}
```

Nesse caso, se um método espera uma instância da classe `Car` e recebe uma instância da subclasse `ElectricCar`, o controle de movimentação do carro pode ser incorreto, violando o princípio de substituição de Liskov.

Para corrigir isso, a implementação do método `drive()` na subclasse `ElectricCar` deve ser consistente com a implementação na classe `Car`. Por exemplo, a implementação na subclasse `ElectricCar` poderia ser a seguinte:

```javascript
class ElectricCar extends Car {
  constructor() {
    super()
  }

  drive(speed) {
    super.drive(Math.min(speed, 100))
  }
}
```

Nesse caso, a subclasse `ElectricCar` ainda controla a movimentação do carro, mas de uma forma consistente com a implementação na classe `Car`. Se a velocidade solicitada for maior do que 100 km/h, a subclasse `ElectricCar` ajusta automaticamente a velocidade para 100 km/h, em vez de emitir uma mensagem de erro.

### Segregação de interface (ISP)

Se você estiver trabalhando em um e-commerce que envolve um módulo de carrinho de compras, um módulo de processamento de pagamento e um módulo de gerenciamento de estoque. Em vez de cada módulo depender diretamente dos outros, você pode definir interfaces que descrevem as operações que cada módulo oferece e que devem ser chamadas pelos outros módulos.

```javascript
interface ShoppingCart {
  addItem(item: Item): void;
  removeItem(item: Item): void;
  getItems(): Item[];
  clear(): void;
}
```

A interface para o módulo de processamento de pagamento pode ser assim:

```javascript
interface PaymentProcessor {
  authorizePayment(payment: Payment): boolean;
  capturePayment(payment: Payment): boolean;
  voidPayment(payment: Payment): boolean;
}
```

E a interface para o módulo de gerenciamento de estoque pode ser assim:

```javascript
interface InventoryManager {
  getStock(item: Item): number;
  reserveStock(item: Item, quantity: number): boolean;
  releaseStock(item: Item, quantity: number): boolean;
}
```

Dessa forma, cada módulo só precisa conhecer as interfaces que ele depende e pode se comunicar com outros módulos por meio dessas interfaces. Isso permite que cada módulo seja desenvolvido e testado de forma independente e facilita a manutenção e evolução do sistema como um todo.

### Inversão de Dependência (DIP)

Vamos supor que você está trabalhando em um sistema de vendas online que tem um módulo de pagamento que utiliza um serviço externo para processar os pagamentos. Nesse caso, você pode criar uma classe `PaymentService` que depende diretamente do serviço externo:

```javascript
class PaymentService {
  constructor() {
    this.paymentGateway = new PaymentGateway()
  }

  processPayment(order) {
    // chama o serviço externo para processar o pagamento
    this.paymentGateway.processPayment(order.total, order.customerInfo)
  }
}
```

Essa implementação viola o princípio de inversão de dependência (DIP) porque a classe `PaymentService` depende diretamente de uma implementação concreta do serviço externo, o que torna o código inflexível e difícil de manter.

Para corrigir isso, você pode inverter a dependência e criar uma interface `PaymentGatewayInterface` que a classe `PaymentService` irá depender. Essa interface pode conter apenas os métodos que a classe `PaymentService` utiliza:

```javascript
class PaymentService {
  constructor(paymentGateway) {
    this.paymentGateway = paymentGateway
  }

  processPayment(order) {
    // chama o método `processPayment` da interface `PaymentGatewayInterface`
    this.paymentGateway.processPayment(order.total, order.customerInfo)
  }
}
```

Nesse caso, a classe `PaymentService` agora depende de uma interface `PaymentGatewayInterface` ao invés de depender diretamente da implementação concreta do serviço externo. Isso permite que você mude o serviço externo no futuro sem ter que alterar o código da classe `PaymentService`. Para mudar o serviço externo, você só precisa criar uma nova classe que implementa a interface `PaymentGatewayInterface`:

```javascript
class PaypalGateway implements PaymentGatewayInterface {
  processPayment(amount, customerInfo) {
    // chama a API do Paypal para processar o pagamento
    // ...
  }
}

const paypalGateway = new PaypalGateway()
const paymentService = new PaymentService(paypalGateway)
```

Dessa forma, você pode alternar entre diferentes serviços externos de pagamento sem ter que alterar o código da classe `PaymentService`. Isso é uma aplicação do princípio de inversão de dependência, que prega que as dependências devem ser abstratas e depender de interfaces ao invés de depender de implementações específicas.

## Conclusão

Seguir os **princípios SOLID** é fundamental para criar um código de alta qualidade e fácil de manter, que pode ser estendido e modificado com facilidade. Ao aplicar esses princípios em sua programação, você pode melhorar a eficiência e a escalabilidade do seu código, o que consequentemente leva a um aumento na qualidade e produtividade do seu trabalho. Além disso, seguir os princípios pode ajudá-lo a evitar a duplicação de código, a reduzir a complexidade do seu código e a torná-lo mais modular, o que ajuda a facilitar a manutenção do código a longo prazo. Em resumo, ao aplicar os **princípios SOLID** em sua programação, você está investindo na qualidade do seu código e no sucesso do seu projeto.

## Referências

- [SOLID Principles: The Software Developer's Framework to Robust & Maintainable Code [with Examples]](https://khalilstemmler.com/articles/solid-principles/solid-typescript/)
- [S.O.L.I.D The first 5 principles of Object Oriented Design with JavaScript](https://medium.com/@cramirez92/s-o-l-i-d-the-first-5-priciples-of-object-oriented-design-with-javascript-790f6ac9b9fa)
- [Understanding SOLID Principles in JavaScript](https://hackernoon.com/understanding-solid-principles-in-javascript-w1cx3yrv)
- [Understanding SOLID Principles in JavaScript - Video](https://www.youtube.com/watch?app=desktop&v=m2GCb-x8e5s)
- [5 SOLID principles with JavaScript. How to make your code SOLID](https://dev.to/denisveleaev/5-solid-principles-with-javascript-how-to-make-your-code-solid-1kl5)
- [SOLID principles: Single responsibility in JavaScript frameworks](https://blog.logrocket.com/solid-principles-single-responsibility-in-javascript-frameworks/)
- [How to Implement the SOLID Principle in JavaScript?](https://javascript.plainenglish.io/solid-principle-in-javascript-part-1-4f67d8f9a31f)


Pincípios SOLID com Javascript


Domain Driven Design é uma filosofia de desenvolvimento lançada por Erick Evans. O DDD é composto por um conjunto de padrões para a construção de aplicações corporativas a partir do modelo de domínio.

Com DDD, estamos de olho nos modelos de um domínio com problema. A persistência, interfaces de usuário e outras coisas de mensagens pode vir mais tarde, é o domínio que precisa ser entendido, porque essa é a parte do sistema que está sendo construído que distingue negócios da sua empresa de seus concorrentes.

Quando digo modelo não se refere a um diagrama ou conjunto de diagramas. Os diagramas são úteis, mas eles não são o modelo, apenas diferentes visões do modelo. O modelo é o conjunto de conceitos selecionados para serem implementados em um software, representado no código e qualquer outro artefato de software utilizado para construir o sistema entregue. Em outras palavras, o código é o modelo. Editores de texto fornecem uma maneira de trabalhar com este modelo, embora modernas ferramentas forneçam a abundância de outras visualizações também (diagramas de classe UML e etc).

O DDD define quatro camadas principais, sendo elas:

- **User Interface:** Responsável por apresentar informações ao usuário e interpretar os comandos do usuário.
- **Application:** Esta camada coordena a atividade das aplicações. Ele não contém qualquer lógica de negócios. Não guarda o estado de objetos de negócios, mas ele pode armazenar o estado de um progresso das tarefas do aplicativo.
- **Domain:** Esta camada contém informações sobre o domínio do negócio. O estado de objetos de negócios é realizado aqui. Persistência dos objetos de negócios e, possivelmente, seu estado é delegado à camada de infra-estrutura.
- **Infrastructure:** Esta camada atua como uma biblioteca de suporte em todas as outras camadas. Fornece a comunicação entre as camadas, implementa persistência para objetos de negócios, contém bibliotecas de suporte para a camada de interface do usuário e etc.

## Conclusão

O DDD não é a solução para todos os problemas de todas as camadas de um sistema. Seu foco é na modelagem das entidades principais de negócio usando a linguagem adequada daquele domínio para facilitar a manutenção, extensão e entendimento.


Começando com Domain Driven Design


Behavior Driven Development (BDD) é uma técnica de desenvolvimento ágil de software que incentiva a colaboração entre desenvolvedores, QA e os participantes não técnicos ou de negócios em um projeto de software. Ele foi originalmente nomeado em 2003 por Dan North como uma resposta ao Test Driven Development (TDD), incluindo o teste de aceitação ou práticas de desenvolvimento de teste do cliente impulsionado como encontrados em programação extrema. Ela tem evoluído ao longo dos últimos anos.

De fato, um dos maiores benefícios do BDD é que une os interesses das empresas com requisitos técnicos, através da utilização de um vocabulário comum simplificado para descrever o comportamento do sistema que reduz o risco de comunicação entre os membros da equipe com diferentes formações.

Além de implementar uma linguagem comum, o BDD incluí:

- Um conjunto de ferramentas de software especializados;
- Um foco sobre as histórias de usuários, também conhecidos como cenários e situações, que delineiam claramente os comportamentos que contribuem com sucesso para os resultados do negócio.
- Uma mentalidade de fora para dentro que se aplica as técnicas em um nível maior de abstração: testando a intenção do sistema inteiro versus apenas o funcionamento de um único trecho de código.

A característica mais importante de BDD é que os métodos de teste em uma classe recebem nomes expressivos que descrevem claramente para o que os mesmos foram feitos.
Esta notação ajuda a manter em mente que há várias razões pelas quais o teste pode falhar, incluindo problemas no sistema, ou um erro no caso de teste em si.
Os casos de teste ou histórias de usuários próprios também seguem um formato de texto muito simples, que consiste em um título e várias frases que descrevem o que acontece em cada cenário incluído na história.

## Conclusão

O BDD tem um impacto significativo sobre a entrega do projeto, uma vez que incentiva as equipes de desenvolvimento para tornarem mais voltadas para o negócio e lidar mais facilmente com os seus colegas de trabalho ou parceiros externos.

Pode ser facilmente integrado dentro de equipes de Scrum. Como tal, BDD é um excelente método que pode ser usado para resolver problemas de comunicação em um projeto, e priorizar o atraso de modo que é mais em sintonia com os interesses comerciais do cliente.


Começando com Behavior Driven Development


Test Driven Development (TDD) é uma técnica de desenvolvimento de software que se baseia em um ciclo curto de repetições:

1. Ler e entender os requisitos para uma determinada funcionalidade.
2. Desenvolver um conjunto de testes que verificam o recurso. Todos os testes estão vermelhos, devido à ausência da funcionalidade.
3. Desenvolve a função até que todos os testes fiquem verdes.
4. Refatora o código.

Kent Beck, considerado o criador da técnica, declarou em 2003 que TDD encoraja o desenho de código simples e inspira confiança. Desenvolvimento guiado por testes é relacionado a conceitos de programação de Extreme Programming, iniciado em 1999, mas recentemente tem-se criado maior interesse pela mesma em função de seus próprios ideais. Através do TDD, programadores podem aplicar o conceito de melhorar e depurar código legado desenvolvido a partir de técnicas antigas.

TDD exige uma maneira diferente de pensar, de modo a fim de começar TDD você precisa esquecer a maneira como você desenvolveu código antes. Este processo é muito difícil. E é ainda mais difícil se você não sabe como escrever testes unitários.

Vantagens importantes:

- Melhor compreensão de um recurso que você implementou.
- Indicadores sólidos da funcionalidade.
- Código coberto com testes e menos chances de ser corrompido por correções ou novos recursos.

O custo destas vantagens é bastante elevado. Inconvenientes relacionados com a mudança para um novo modo de desenvolvimento e o tempo que você gasta para o desenvolvimento de cada novo recurso. O preço da qualidade.

## Conclusão

Testes são muitos importantes por motivos de qualidade e menos riscos para a sua aplicação. Mas não é um pensamento que irá dominar do dia para a noite. O caminho é bem árduo, mas é importante iniciar esse trajeto. O desenvolvedor ganha, o projeto ganha e o cliente com uma qualidade maior.


Começando com Test Driven Development


Se está familiariazado(a) com a metodologia ágil, já deve conhecer o Scrum. Scrum é um framework para desenvolver e manter produtos complexos. Criado em 1993, por Jeff Sutherland, o processo foi formalizado para a indústria mundial de software no primeiro artigo sobre Scrum, publicado na conferência OOPSLA 1995(hoje chamada SPLASH), por Ken Schwaber.

O nome Scrum é uma analogia a um estudo conduzido em 1986 por Takeuchi e Nonaka, publicado na Harvard Business Review. No estudo, compararam equipes de alto desempenho e multi funcionais com a formação "scrum" existente nas equipes de Rugby em que todo o time está junto em um objetivo. Se a formação for quebrada, o time todo perde. Se atingem o objetivo, a equipe toda é responsável pelo sucesso.

De 1995, para cá, o Scrum deixou de ser um método e passou a ser um framework. Pois, ele apenas indica o que deve ser feito e emprega vários processos ou técnicas.

## O time

### O Product Owner

O Product Owner é a pessoa que define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings.

O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint (iteração). Estes itens transformam-se no Sprint Backlog.

A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.

### O Scrum Team

O Scrum Team é a equipe de desenvolvimento. Nela, não existe necessariamente uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de "Scrum of Scrums". Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá freqüentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações.

### O Scrum Master

O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.

O papel de Scrum Master é tipicamente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe.

## Eventos

### Sprint

No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um tempo definido 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 no Scrum são chamadas de Sprints e geralmente duram de 2 a 4 semanas.

### Sprint Planning Meeting

O Sprint Planning Meeting é uma reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Scrum Team, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.

Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

O Product Owner não precisa descrever todos os itens que estão no Product Backlog. Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade para o próximo Sprint Planning Meeting.

Coletivamente, o Scrum Team e o Product Owner definem um objetivo para o Sprint, que é uma breve descrição daquilo que se tentará alcançar no Sprint. O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint.

Depois do Sprint Planning Meeting, a equipe Scrum se encontra separadamente para conversar sobre o que eles escutaram e decidir quanto eles podem se comprometer a fazer no Sprint que será iniciado. Em alguns casos, haverá negociação com o Product Owner, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a fazer.

### Daily Scrum

A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia.

Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.

Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.

O Daily Scrum não deve ser usado como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo. Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:

    O que você fez ontem?
    O que você fará hoje?
    Há algum impedimento no seu caminho?

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito. O Daily Scrum não é uma reunião de status report na qual um chefe fica coletando informações sobre quem está atrasado. Ao invés disso, é uma reunião na qual membros da equipe assumem compromissos perante os demais.

Os impedimentos identificados no Daily Scrum devem ser tratados pelo Scrum Master o mais rapidamente possível.

### Sprint Review Meeting

Ao final de cada Sprint é feito um Sprint Review Meeting. Durante esta reunião, o Scrum Team mostra o que foi alcançado durante o Sprint. Tipicamente, isso tem o formato de um demo das novas funcionalidades.

Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint.

### Sprint Retrospective

O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar.

### Burn Down Chart

O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo X indica o número de tarefas existentes no Sprint e o eixo Y os dias que representam o tamanho do Sprint.

## Artefatos

### Product Backlog

O Product Backlog é uma lista contendo todas as funcionalidades desejadas para um produto. O conteúdo desta lista é definido pelo Product Owner. O Product Backlog não precisa estar completo no início de um projeto. Pode-se começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Durante o Sprint Planning Meeting, o Product Owner prioriza os itens do Product Backlog e os descreve para a equipe. A equipe então determina que itens será capaz de completar durante a Sprint que está por começar. Tais itens são, então, transferidos do Product Backlog para o Sprint Backlog. Ao fazer isso, a equipe quebra cada item do Product Backlog em uma ou mais tarefas do Sprint Backlog. Isso ajuda a dividir o trabalho entre os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente relacionadas às funcionalidades solicitadas.

### Sprint Backlog

O Sprint Backlog é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.

## Conclusão

Mesmo sendo possível implementar apenas partes do Scrum, não será Scrum, se não for aplicado em sua totalidade. Seja adepto das metodologias ágeis e vale a pena conhecer mais sobre o Scrum.


Começando com SCRUM


A UML(Unified Modelling Language) é a linguagem para modelagem de dados orientado a objetos, para a especificação, construção, visualização e documentação de um software em desenvolvimento. Se formou na junção de 3 mentes responsáveis por métodos de modelagem orientada a objeto: [Grady Booch](https://twitter.com/grady_booch), James Rumbaugh e [Ivar Jacobson](https://twitter.com/ivarjacobson). A linguagem UML foi adotada em 1997 pela [OMG (Object Management Group)](http://www.omg.org/spec/), que define e ratifica padrões na área de Orientação a Objetos.

O desejo da criação da UML, começou em outubro de 1994, com Booch e Rumbaugh na Rational Software Corporation, que foi adquirida pela IBM em 20 de fevereiro de 2003. Em outubro de 1995, unificaram os métodos Booch e OMT, tendo o seu primeiro esboço da versão 0.8 do Unified Process (Processo Unificado). Um pouco mais tarde com a associando de Jacobson, em junho de 1996, a versão 0.9 da UML, foi lançada com a incorporação do método OOSE.

- **_Booch – Grady Booch_** - Booch definiu a noção de que um sistema é analisado a partir de um número de visões, onde cada visão é descrita por um número de modelos e diagramas. O Método de Booch trazia uma simbologia complexa de ser desenhada a mão, continha também o processo pelo qual sistemas são analisados por macro e micro visões.
- **_OMT(Object Modelling Technique) – James Rumbaugh_** - A técnica de Modelagem de Objetos é especialmente voltado para o teste dos modelos, baseado nas especificações da análise de requisitos do sistema. O modelo total do sistema baseado no método OMT é composto pela junção dos modelos de objetos, funcional e use-cases.
- **_OOSE(Object-Oriented Software Engineering) – Ivar Jacobson_** - O método é a visão de Jacobson de um método orientado a objetos. Baseado na utilização de use-cases, que definem os requisitos iniciais do sistema, vistos por um ator externo.

## Conceito da orientação a objetos

Para utilizar a UML, é necessário conhecer o conceito da orientação a objetos e entender sobre: objetos, classes,
abstração, encapsulamento, herança, comunicação com mensagens, métodos de organização e polimorfismo.

- **_Objetos_** - É um substantivo que pode ser abstrato ou real, sobre o qual armazenamos dados e operações que manipulam os
  dados, como uma pessoa, um carro e etc.
- **_Classes_** - É uma coleção de objetos que podem ser descritos com os mesmos atributos e as mesmas operações
- **_Abstração_** - Focaliza a visão externa de um objeto, separando - a em comportamento, descrito pela interface dos métodos da classe e implementação, composta pelas variáveis de instancia e corpo dos métodos.
- **_Encapsulamento_** - Esconde dos usuários de um objeto, os detalhes da implementação interna. Os usuários compreendem quais operações podem ser solicitadas de um objeto, mas não conhecem os detalhes de como a operação é executada.
- **_Herança_** - É o mecanismo de compartilhamento automático de métodos e dados entre classes, subclasses.
- **_Polimorfismo_** - Permite que o programa trate uniformemente objetos que pertencem a classe diferentes, isto é, o programa envia a mesma mensagem a objetos de diferentes classe resultando um comportamento diferente. Existem alguns tipos de Polimorfismo: paramétrico, de inclusão, por `overloading` e por coerção.
  - **_Paramétrico_** - quando uma função funciona uniformemente sobre uma gama de tipos.
  - **_De inclusão_** - através do mecanismo de herança de objeto pode pertencer a um número infinito de classes, aplicação do princípio de substituição.
  - **_Por overloading_** - mesmo nome de variável utilizado para denotar diferentes funções. É o contexto que decide que função utilizar.
  - **_Por coerção_** - operação semântica é utilizada para converter argumento para tipo necessário.

## Diagramas

Apenas vou listar os tipos de diagramas, que aos poucos irei criando um artigo para cada diagrama. :)

### Diagramas de Estrutura (estático)

- Diagrama de Classe
- Diagrama de Objeto
- Diagrama de Pacotes
- Diagrama de Componentes
- Diagrama de Implantação
- Diagrama de Estrutura Composta
- Diagrama de Perfis

### Diagramas de Comportamento(dinâmico)

- Diagrama de Caso de Uso
- Diagrama de Atividade
- Diagrama de Máquina de Estados
- Diagramas de Interação
  - Diagrama de Sequência
  - Diagrama de Comunicação
  - Diagrama de Tempo
  - Diagrama de Interação Geral

## Versões da UML

A versão atual é a UML 2.5.

- **_1.1_** - OMG (Object Management Group – 1997)
- [**_1.3_** - Março de 2000](http://www.omg.org/spec/UML/1.3/)
- [**_1.4_** - Setembro de 2001](http://www.omg.org/spec/UML/1.4/)
- [**_1.5_** - Março de 2003](http://www.omg.org/spec/UML/1.5/)
- [**_2.0_** - Julho de 2005](http://www.omg.org/spec/UML/2.0/)
- [**_2.1.1_** - Agosto de 2007](http://www.omg.org/spec/UML/2.1.1/)
- [**_2.1.2_** - Novembro de 2007](http://www.omg.org/spec/UML/2.1.2/)
- [**_2.2_** - Fevereiro de 2009](http://www.omg.org/spec/UML/2.2/)
- [**_2.3_** - Maio de 2010](http://www.omg.org/spec/UML/2.3/)
- [**_2.4_** - Março de 2011](http://www.omg.org/spec/UML/2.4/)
- [**_2.4.1_** - Agosto de 2011](http://www.omg.org/spec/UML/2.4.1/)
- [**_2.5_** - Junho de 2015](http://www.omg.org/spec/UML/2.5)

## Conclusão

Essa foi uma rápida introdução a UML. Terá uma série de artigos, explicando sobre cada diagrama e mais atualizações sobre o assunto.


Começando com UML


## Por que é necessário se ter um método ágil para o desenvolvimento de software?

Com o método tradicional conhecido como `Cascata` (Waterfall), se tem um processo de levantamento bem detalhado no início do projeto, junto ao cliente. Assim, muitas das vezes se tem o projeto com o escopo fechado. Logo de ínicio, precisamos saber de tudo que o cliente precisa e aí encontramos o problema em que o cliente pode não saber o que quer, sem ter amostras para que possa ter uma visão mais clara.

Mesmo que o cliente ainda não saiba o que quer, terá uma equipe de analistas que faria o levantamento dos requisitos, depois passando pelas equipes de design, modelagem e depois de um longo processo chegaria na equipe de programação. Muitas das vezes, o pensamento das equipes por onde se passou o projeto, não estão com a mesma linha de raciocínio.

Depois de um longo processo, por fim se chega na parte de testes, onde o prazo já está apertado ou inexistente. Provocando uma possível queda na qualidade do projeto e não dando oportunidade para correções dentro do prazo.

Com o cliente só tendo acesso ao projeto no final do mesmo, é gigantesca a possibilidade de haver o : "- Não foi isso que eu pedi.". E temos um sério problema.

Nas metodologias ágeis temos os mesmos processos, mas ao invés de fases extensas, temos ciclos com duração bem mais reduzidas. A cada ciclo, o cliente já poderá acompanhar o acréscimo da funcionalidade no produto, podendo dar `feedbacks` para as equipes.

## Manifesto Ágil

Em 2001, foi criado o manifesto ágil com a assinatura de especialistas em processos de desenvolvimento de software representando entre outros, os métodos Scrum e Extreme Programming (XP).

> "Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
>
> Indivíduos e interação entre eles mais que processos e ferramentas.
> Software em funcionamento mais que documentação abrangente
> Colaboração com o cliente mais que negociação de contratos
> Responder a mudanças mais que seguir um plano
>
> Ou seja, mesmo havendo valor nos itens à direita,
> valorizamos mais os itens à esquerda."
> <cite>
>
> - [Manifesto ágil](http://www.manifestoagil.com.br/) > </cite>

Aqui você pode conferir os [Princípios por trás do manifesto ágil](http://www.manifestoagil.com.br/principios.html).

Existem várias abordagens para as metodologias ágeis, dependendo da sua necessidade, você poderá estar usando o `Scrum`, `XP`, `Kanban` ou outros como ferramenta.

## Vantagens para o cliente

> - Foco e maximização do ROI (Retorno do Investimento) e do Valor de Negócio;
> - Entregas do produto + rápida, freqüentes e regulares;
> - Aceleração do Time-to-market o que se traduz em ganho de competitividade;
> - Maximização do Value-to-Makert;Foco no que é prioritário e traz mais valor para o usuário, o que se traduz em ganho de usabilidade;
> - Transparência e visibilidade do status do projeto;
> - Flexibilidade para mudanças de requisitos e prioridades além de maior agilidade na tomada de decisões;
> - Melhoria da Qualidade do produto final;
> - Produtividade;
> - Redução dos riscos e das indesejáveis surpresas.
>   <cite>
> - [O que são essas tais de metodologias Ágeis?](https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en) > </cite>

## Vantagens para o gestor e a equipe

> - Escopo e objetivos claros e priorizados;
> - Equipes auto-gerenciáveis, maior autonomia, disciplina e regularidade;
> - Maximização do comprometimento;
> - Melhoria na comunicação. A comunicação intensa com o cliente e a gestão de suas expectativas são parte do processo;
> - Inspeção e Adaptação constantes do processo em busca da melhoria contínua e a redução dos desperdícios;
> - Antecipação dos problemas e maior agilidade na tomada de ações.
>   <cite>
> - [O que são essas tais de metodologias Ágeis?](https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en) > </cite>

## Conclusão

O mais importante é colocar o projeto em primeiro lugar e avaliar o que é melhor para o mesmo. Se o projeto tem requisitos estáveis e previsíveis, o método tradicional se encaixa bem. Os requisitos sendo instáveis e o projeto estando em constantes mudanças, a metodologia ágil resolve e organiza esse fluxo que precisa de uma atenção em curto prazo.


Começando com a metodologia ágil


A lógica está presente em algo que você faz. Na lógica de programação, não é muito diferente. Tudo que se propõe a programar, você deve se basear em um raciocínio lógico no planejamento. Então, o foco é ter em mente o desenvolvimento da forma racional, buscando soluções para um problema. É um requisito básico para quem quer ser um programador, saber sobre lógica. Copiar e colar, não é programar. É necessário saber o que está fazendo e ter um raciocínio do que está sendo feito para solucionar um problema.

Na lógica de programação, uma coisa muito importante é a teoria da programação, que será a base para você programar, independente da linguagem.

O que será muito visto é a criação de algoritmos. Que é uma sequência de passos, para se executar uma tarefa.

> Um algoritmo é uma sequência finita de instruções bem definidas e não ambíguas, cada uma das quais devendo ser executadas mecânica ou eletronicamente em um período de tempo finito e com uma quantidade de esforço finita.
> <cite>
>
> - [Wikipédia](https://pt.wikipedia.org/wiki/Algoritmo) > </cite>

## O que é preciso para programar?

Quando precisamos desenvolvedor algo, partimos de 2 premissas: Saber o que precisa ser feito e como.

A lógica entra na primeira etapa. Exemplo:

Temos a tarefa de chupar uma bala. Precisamos saber como será feito. Entramos com a lógica, na elaboração do algoritmo.

- 1 - Colocar a mão no bolso;
- 2 - Pegar a bala;
- 3 - Desembrulhar o papel;
- 4 - Colocar a bala na boca;
- 5 - Chupar a bala;
- 6 - Jogar fora o papel;

Com a primeira etapa concluída, passamos para a etapa de como fazer. Assim, só será preciso escolher a linguagem que será utilizada. Que depende do seu conhecimento de uma linguagem e estudo da mesma. A parte do planejamento sendo bem pensado, evitar retrabalho e falhas quando a tarefa for executada pelo seu programa.

## Algoritmos

As formas mais conhecidas da representação de algoritmos, são:

- 1 - Descrição Narrativa
- 2 - Fluxograma
- 3 - Pseudocódigo ou linguagem estruturada

### Descrição Narrativa

É a linguagem normal que usamos no dia a dia e os passos como devem ser, como foi mostrado acima na tarefa "chupar uma bala".

### Fluxograma

É representado por formas geométricas, onde cada forma tem um significado e expressa uma ação, instrução ou comando.

![Fluxograma](/assets/tecnologia/artigos/fluxograma.svg)

### Pseudocódigo ou linguagem estruturada

É a que chega mais próximo de uma linguagem de programação. Utilizando: comandos de entrada e saída, variáveis, constantes, expressões, blocos e ações a serem realizadas.

Para essa etapa, você pode usar o [VisualG](http://www.apoioinformatica.inf.br/produtos/visualg). Na faculdade, usava o [Dev C++](http://sourceforge.net/projects/orwelldevcpp/), mas acredito que o VisualG é mais interessante, por não ser necessário conhecer uma linguagem.

Para quem usa o Linux, uma alternativa se não quiser usar o **_Wine_**, é o [G-Portugol](http://sourceforge.net/projects/gpt.berlios/).

Outras sugestões:

- [Portugol Studio](http://lite.acad.univali.br/portugol/) - Win
- [Potigol](https://github.com/potigol/Potigol) - Win / Linux

> O VisuAlg é um programa que edita, interpreta e executa algoritmos com uma linguagem próxima do portuguêsestruturado como um programa normal de computador. É um programa de livre uso e distribuição, empregado no ensino de programação em várias escolas e universidades no Brasil e no exterior.
> <cite>
>
> - [VisualG](http://www.apoioinformatica.inf.br/produtos/visualg) > </cite>

Exemplo com o VisualG:

```
algoritmo "exemplo"
// Função : Média
// Autor :  Hemerson Vianna
// Data : 26/08/2015

// Seção de Declarações
var nota1, nota2, media : real

inicio
	escreva("Digite a primeira nota:")
	leia(nota1)

	escreva("Digite a segunda nota:")
	leia(nota2)

	limpatela

	media <- (nota1+nota2)/2

	escreval("A média é:",media)
fimalgoritmo
```

## Conclusão

A lógica da programação é muito importante, para se ter um planejamento mais detalhado e assim, evitando falhas durante a execução dos passos.

Um algoritmo tem que partir do princípio que poderá ser compreendido por qualquer pessoa. Com isso, é necessário que ele seja feito de forma clara e no caso do **_pseudocódigo_**, com comentários e identação para fácil compreensão.


UI2CodeGo to Home Page

It management

Compartilhar

Compartilhar

Compartilhar

Compartilhar

Compartilhar

Compartilhar

Compartilhar

Compartilhar

Compartilhar