Boas práticas no Desenvolvimento de Software

Danielle Teixeira

13/08/2016

Danielle Teixeira

  • Engenheira da Computação
    • Esp. Banco de Dados
    • Esp. Desenvolvimento para Aplicativos Mobile
  • Prêmio
    • Proteste Inovação 2015
  • No dia-a-dia
    • Analista de Requisitos
  • Membro
    • Woman Techmackers
    • Raul Hacker Club
    • PHPBA

  • Introdução

  • Porque os projetos dão errado

  • Etapas para aplicação de boas práticas

  • Designer Pattern

  • Testes

.agenda {}

Ciclo de Desenvolvimento

Porque os projetos dão errado?

Projetos não falham. Pessoas falham.

Porque os projetos dão errado?

  • Não ter um time no projeto
  • Prazos curtos
  • Funcionalidades do negócio não mapeada
  • Começar a desenvolver sem prototipar
  • Cliente não é envolvido no desenvolvimento do projeto
  • Homologação do sistema é suprimida
  • Procastinação
  • Ambiente não escalável

Projetos que deram "errado"

  • Google Glass
Sergey Brin: cofundador do Google apresentou o produto ao mercado antes da hora certa.

fonte

Google Glass

  • Ninguém sabia como ele deveria ser usado

  • Ele era apenas um protótipo

  • Tiro pela culatra, preço alto por um "protótipo". U$ 1500

  • Bateria ruim, muitos Bugs e funcionalidades estranhas foram alguns dos problemas apontados.

  • Invasão de privacidade

Google Glass do futuro

Recentemente, o Google anunciou mudanças drásticas no projeto. A equipe será reformulada em parte e o desenho do produto começará do zero.

O que são boas práticas?

O que são boas práticas?

  • Técnicas identificadas como as melhores para  realizar uma determinada tarefa.

Porque usar boas práticas?

Porque usar boas práticas?

  • Redução do Ciclo de Desenvolvimento do Software;
  • Permite uma aplicação mais tolerante a falhas;
  • Melhora manutenibilidade;
  • Dar feedback ao usuário (notificações claras)
    • ex: saque banco (deve notificar novo saldo)
  • Entregar o produto mais funcional

O que esperar de uma boa aplicação?

  • Funcional
  • Usabilidade
  • Segurança
  • Bom desempenho
.boas Praticas {}

Construir um software não é somente escrever código e vê-lo funcionar, é você saber que aquele código será manutenível e que outras pessoas vão alterá-lo.

.boas Praticas {}
  • Técnicas para aumentar produtividade;
  • Levantar requisitos;
  • Desenhar a solução antes de codificar;
  • Fazer tratamento de erro;
  • Adotar um padrão de programação;
  • Usar versionamento;
  • Estudar outros códigos;
  • Querys mais simples;
  • Segurança;
  • Testes.
.produtividade{}
  • Pomodoro
  • Kanban
  • Metodologia Agil
.pomodoro{}
  • Técnica de gestão de tarefas, desenvolvida por Francesco Cirillo em 1980
.pomodoro{}
  • Passo a passo para aumentar a produtividade
.pomodoro{}

fonte

.produtividade {}
  • Pomodoro
  • Kanban
  • Metodologia Agil
.kanban{}
  • Técnica de cartões, criado pela Toyota, Kanban é um termo de origem japonesa e significa literalmente “cartão” ou “sinalização”;
  • Indicam o andamento dos fluxos de desenvolvimento.

 

.metodologias Agil{}
  • Acelerar o desenvolvimento do software;
  • Melhoria contínua do processo;
  • Aumenta a comunicação e interação da equipe;
  • Atividades organizadas diariamente ;
  • Evitar falhas na elaboração;
  • Respostas rápidas às mudanças;
  • Aumenta produtividade;
.SCRUM {}
  • Processo de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.

Iterativo

Incremental

  • Desenvolvido na decada de 90 por Jeff Sutherland
.SCRUM {}
  • São atividades divididas que geralmente duram de 2 a 4 semanas.

Sprints

Sprints Backlog

  • São listas de funcionalidades a serem implementadas no projeto.
.SCRUM {}

Sprint backlog

.SCRUM {}
  • Define os requisitos do produto, decide a data de release e o que deve conter nela.
  • Responsável pelo retorno financeiro do produto.
  • Aceita ou rejeita o resultado de cada Sprint.

Product Owner

  • Líder e mediador que distribui as atividades;
  • Protege o time de interferências externas;
  • Participa das reuniões diárias, revisão da Sprint, e planejamento.

Scrum Master

.SCRUM {}

Scrum Team

  • Multifuncional, entre 5-9 membros.
  • Seleciona, entre os itens priorizados, os que irão ser executados durante a Sprint.
  • Desenvolve e produz com qualidade atividades da Sprint
.etapas {}
.requisitos {}
  • Que são requisitos de software?
    • São características que o  sistema deve possuir 
.requisitos Funcionais {}
  • Define o funcionamento perceptível do sistema pelos usuários para atender regras de negócios.
    • Telas, informações, relatórios, fluxo de negócio.

RF01 - Criar formulário de contato contendo, nome, email e mensagem.

.requisitos Funcionais{}

Funcionais

RF02 - validar campo de email

RN02 - Ao clicar no campo de senha, animar coruja

Regra de Negócio

.requisitos {}
  • Definem os parâmetros de funcionamento do sistema.
    • ​Desempenho, segurança, prevenção de falhas, usabilidade e etc.

Não Funcionais

RNF01 Requisitos de portabilidade. o sistema deverá rodar em qualquer plataforma.

.requisitos naoFuncionais{}

Segurança

  • Usar mascara nos campos de senha.
  • Usar  processo de hash com uma função pelo menos equivalente a SHA-256.

Confidencialidade

.requisitos {}
  • Baixa qualidade;
  • Retrabalho;
  • Maior números de bugs;
  • Escopo indefinido;
  • Problemas de usabilidade;
  • Insatisfação do cliente;
  • Ciclo de manutenção maior;
  • Vulnerável a falhas e invasões.

Consequências de Software sem Requisitos

.prototipacao {}

Processo que facilita o entendimento dos requisitos, apresenta conceitos e funcionalidades do software.

.prototipos Vantagens{}
  • Facilita o levantamento de requisitos e funcionalidades;
  • Receber o feedback do cliente em tempo ágil;
  • Possibilita a realizar testes de interações;
  • Reduz esforços no desenvolvimento.
.prototipos Tipos{}
  • Baixa Fidelidade
  • Média Fidelidade
  • Alta Fidelidade
.prototipos Tipos{}
  • Baixa fidelidade

São esboços concebidos ainda na fase inicial, durante a concepção do sistema.

fonte

.prototipos Tipos {}
  • Baixa Fidelidade
  • Média Fidelidade
  • Alta Fidelidade

 

Conhecidos por wireframes, são mais detalhados e desenvolvidos na fase da arquitetura da informação, é o layout básico do projeto.

 

  • Média Fidelidade

fonte

.prototipos Tipos {}
  • Baixa Fidelidade
  • Média Fidelidade
  • Alta Fidelidade

 

.prototipos Tipos {}
  • Alta Fidelidade

 

fonte

  • São protótipos completos, navegáveis e bem próximos do produto final.  
.prototipos Tipos {}
  • Testar a usabilidade
.prototipos Ferramentas {}

fonte

fonte

fonte

fonte

Qual padrão de projeto você utiliza?

Padrão Gambis?

O que são padrões de projeto ?

.design Patterns {}
  • São soluções de templates abstratas de alto nível.
.design Patterns {}

Ou seja...


É uma solução de um problema que alguém já teve no desenvolvimento e manutenção de  softwares orientado a objetos.

.design Patterns {}
  • Erich Hamma, Richard Helm, Ralph Johson e John Vlissdes, mais conhecidos como “Gang of Four”.
  • Documenta boas soluções para problemas recorrentes
  • Permite o reuso de conhecimento anterior documentados em boas práticas
  • Obtidas através de experiências de sucesso na indústria de software

Criado por

.padroes de Projetos {}

Vantagens

  • Facilita a evolução do código.
  • Reuso das soluções
  • Desenvolvimento acelerado
    • Reduz tempo de desenvolvimento e validação
.padroes de Projetos {}

fonte

.padrao MVC{}

Model View Controller (MVC)

  • Separa camada de desenvolvimento;
  • Facilidade de manutenção;
  • Reaproveitamento de código.

Vantagens

  • Padrão de arquitetura de software que divide as responsabilidades dos componentes;
  • Surgiu na década de 70 pela Xerox.
.padrao MVC{}

View

Trata dos dados e da lógica de negócios.

Model

Apresentação dos dados ao usuário, telas (CSS, HTML).

Controller

Interage com o model para criar a view e recebe as requisições do usuário.

.padrao MVC{}
  • Alguns frameworks que usam ...
.versionar Projeto{}

 

  • Permite que você altere um arquivo e, se fizer algo de errado, volte atrás.

 

  • Guarda as informações de quem alterou alguma funcionalidade.

Controle de versão

fonte

.versionar Projeto{}

Se alguém fizer algo de errado..

fonte

Ou seja...

Já sabem quem é o culpado!

.versionar Projeto{}

 

  • Controlar histórico
  • Marcar  e resgatar versões estáveis
  • Ramificar o projeto
  • Segurança
  • Multiplataforma

Porque usar versionamento?

.versionar Projeto{}

Quem usa Git?

.Normalizacao {}
  • Conjunto de regras que ajudam na definição de bancos de dados que não contenham redundância desnecessária  permitindo fácil acesso às informações.
.Normalizacao {}

  • A finalidade das regras de normalização é evitar anomalias de atualização no banco de dados

  • Anomalias de inserção é evitar a repetição desnecessária de dados (redundância).
.Normalizacao {}

  • Anomalias de alteração é evitar inconsistências e reduzir o esforço para a atualização dos dados

.Normalizacao {}

  • Anomalias de exclusão é evitar a perda de informações associadas a um dado registro

Evitar

Boa Prática

.normalizacao{}

Dividir  tabelas grandes em tabelas menores, através das formas normais

Objetivo: minimizar danos sofridos no desempenho do banco de dados

.consultas SQL{}

Com * o SGBD gasta muito tempo percorrendo todos os campos

Evitar

Boa Prática

.consultas SQL{}
SELECT * FROM tabelax
SELECT COLUNAA, COLUNAB FROM tabelax

Verificar se um campo string tem necessidade de usar Char ou Varchar

Evitar

Boa Prática

.consultas SQL {}
CREATE TABLE pessoa(
id int not null PRYMARY KEY
sexo varchar(10);
)

INSERT INTO pessoa(
sexo 'F' )
CREATE TABLE pessoa(
id int not null PRYMARY KEY
sexo char(1);
)

INSERT INTO pessoa(
sexo 'F' )

Objetivo: melhorar desempenho do banco, com EXISTS o banco sabe que é um teste de existência sua busca é interrompida assim que encontrar a  a primeira linha

  •  COUNT

Evitar

  •  EXISTS

Boa Prática

.consultas sql{}

O SGBD não consegue otimizar cláusulas de join ligadas por OR. Neste caso é mais eficiente ligar os conjuntos de resultados por UNION.

Evitar

Boa Prática

.consultas sql{}
SELECT a FROM tab1, tab2 
WHERE tab1.a = tab2.a 
OR tab1.x = tab2.x
SELECT a FROM tab1, tab2 
WHERE tab1.a = tab2.a 
UNION SELECT A FROM tab1, tab2	
WHERE tab1.x = tab2.x
  • são eliminadas as linhas duplicadas

OR

UNION

Esqueci alguma coisa?

  • Teste unitários (unit)

  • Testes de integração(service)

  • Testes de aceitação (UI)

.testes Automatizados {}

UI
 

Service

Unit

TDD  - Test Driven Development

.testes Automatizados {}

Onde aprender mais?

Made with Slides.com