Arquivo da categoria: Técnicas

Técnicas

Conhecendo a filosofia de codificar da NASA

O conteúdo deste artigo é uma tradução do original escrito por Abner Coimbre que pode ser conferido aqui. Ao final do texto há mais referências sobre ele bem como seus contatos. O texto traz algumas premissas utilizadas pela NASA no desenvolvimento dos seus softwares e na sequência algumas considerações do próprio autor sobre o mundo do desenvolvimento de softwares

Desde já agradeço ao Abner por ter permitido esta tradução.

Nearly an hour after launch, contrails from the lift-off of US space shuttle Atlantis float above the Vechicle Assembly building 08 June, 2007 at the Kennedy Space Center in Florida. The shuttle is on an 11-day mission to the International Space Station. (Photo credit should read TIM SLOAN/AFP/Getty Images)

O Mundo do software moderno

Existe um tema recorrente na comunidade de desenvolvimento que está associado a encontrar “melhores formas” de escrever “software moderno”.  Se o termo “moderno” é ou não realmente útil – programação de computadores é relativamente nova –  eu definitivamente sigo com a impressão de que sempre há algo novo ou melhor para falar. Então, se nós prestarmos atenção nos temas abordados no desenvolvimento de software hoje, rapidamente perceberemos o quão importante é separar o joio do trigo: o que é útil e o que não é.

Dada toda essa conversa sobre software moderno, eu tenho visto programadores iniciantes perguntando o que eu penso ser a questão mais importante das suas carreiras: “No que devemos prestar atenção?”, e honestamente, é um pouco cruel encorajá-los a seguir com:

  • POO deve ser o futuro da programação?
  • Vamos nos juntar ao Rust Evangelism StrikeForce
  • Go é muito melhor que qualquer <language_with_other_design_goals>?

Pelo menos, não é assim que a NASA se posicionou para responder quando esta pergunta foi feita. A história da agência é bem conhecida, sabemos que o programa espacial pode sofrer consequências irreversíveis se alguns dos seus softwares tiver problemas, podendo ser fatal. O choque de realidade permitiu-lhes desenvolver certas atitudes a respeito do seu modelo de desenvolvimento. Vale a pena conferir o que eles têm valorizado.

Com alguns anos de trabalho lá, gostaria de apresentar em primeira mão a filosofia de trabalho que permitiu a agência espacial produzir alguns dos softwares mais confiáveis do mundo e irei elencar suas atitudes em relação a programação num conjunto de quatro premissas que eles praticam na sua força de trabalho (e que eu vivenciei diretamente).

 

As quatro premissas da NASA 

  • Você terá acesso a um mentor.

Quem é seu mentor? É um quebra gelo comum com qualquer programador da NASA graças ao seu compromisso de garantir que todo programador possa ter um mentor. Isto poderia ser no nível de negócios, com o programa OSBP’s Mentor-Protégé, com o projeto interno NEXT ou com o Pathways Agency Cross-Center Connection (PAXC). Curiosamente, você não precisará sair procurando por um porque todos nós temos nossos mentores pessoais desde o início. A ideia de que um programador não pode ter alguém com uma experiência sênior para acompanhar seu progresso é descartada no programa espacial.

 

  • Nós confiamos no potencial de cada um

Existe um razoável grau de confiança quando você entra em uma equipe, devido as investigações de antecedentes a que você é submetido. Também assumimos que cada um tem algum valor para oferecer e nós confiamos no potencial do indivíduo. Mostre que você é bom e o título se torna quase sem sentido. Não é incomum um estagiário contribuir com projetos de software de alto nível da NASA.

 

  • Você dirá “Eu não entendo”

Esta declaração é dita a todo momento. Você verá desenvolvedores experientes perguntando para estagiários “Eu não entendo essa parte do código, é um novo recurso da linguagem que eu ainda não conheço? ” ou gerentes perguntando para engenheiros “Eu não tenho certeza das implicações do seu trabalho neste momento. Poderíamos rever mais algumas vezes até que eu tenha uma boa ideia disso? ” Estas são questões que fazem parte da rotina de trabalho.

 

  • Nós valorizamos Insights sobre como os sistemas computacionais funcionam

A NASA procura incessantemente por novas descobertas sobre os o funcionamento dos computadores, o valor desta procura está em conhecer as limitações dos sistemas para prevenir decisões ruins no desenvolvimento de softwares.

Considere Gene Amdahl. Ele foi um dos pioneiros da computação com uma interessante questão: Qual é a eficácia de melhorar um componente de um sistema? Digamos que 50% do tempo de execução do seu programa foi melhorado por apenas um fator dos quatro existentes e agora queremos saber o quão rápido a aplicação está. Em outras palavras, algo consumiu o tempo T1 para executar até o fim, agora uma parte desse algo (que consumiu uma fração f de T1) é k vezes mais rápida. Pouparei de você alguns cálculos, embora seja muito simples – definir o novo tempo T2 e expressar a melhora relativa de performance como uma razão de T1 e T2. Você terá a seguinte equação:

Al1

Continuando com o exemplo anterior para saber o quão rápido sua aplicação está,vamos aplicar na fórmula:

Al2

 

O resultado é 1,6. Embora você tenha otimizado para ser quatro vezes mais rápido, no geral o sistema é somente 1,6 X mais rápido. Vamos ainda mais longe. Digamos que você melhorou algum outro componente e o tempo que este leva para rodar é agora zero (k tende ao infinito). Você agora tem um tipo especial da lei de Amdahl.

Al3

 

Suponha que o componente responda por 60% do tempo de execução do seu sistema, e agora não consome tempo algum para executar. A velocidade máxima teórica é de 2,5… a lei de Amdahl nos diz que para melhorar significantemente a velocidade de execução, teremos que melhorar uma grande fração disso. Pura verdade, mas facilmente esquecida. A lei é usada frequentemente na computação paralela para prever acelerações utilizando processadores de vários núcleos e Julian Browne reformulou ela no seguinte contexto: “Essencialmente a lei afirma que enquanto um processador pode trabalhar com fluxos que podem então rodar em paralelo, o tempo tomado pelo processo inteiro será significativamente limitado pelos fluxos que restam sequencialmente”. Ver Artigo sobre a Lei.

 

Com estas suposições em mente, o resto do artigo fornece uma visão mais pessoal sobre as lições que poderiam ser aprendidas.

  

Evitar fontes de conhecimentos duvidosas

Alguns dos meus amigos concordam que a atividade de programar ainda precisa amadurecer, pois ela estaria no estágio pré-científico da sua existência. Eu diria que muitos de nós estamos aderindo subconscientemente a fontes tradicionais de conhecimento que tem se provado duvidosas, e posso dizer que a NASA tem feito um bom trabalho para se proteger contra isso.

 

Fé

Eu não quero dizer fé no sentido de esperança. Fé também é compreendida quando nós queremos acreditar em algo sem que tenhamos bons motivos para acreditar. Vejamos um exemplo:

 

Lead: “Gosto das novas funcionalidades das aplicações para nossos usuários, mas você disse que baixou uma biblioteca para escreve-las. ”

 

Junior: “Sim. Funcionaram muito bem. ”

 

Lead: É código aberto? De qualquer modo, quem é o fornecedor e como é o suporte que eles oferecem?

 

Junior: “Não é, mas eu tenho usado ela e por enquanto não tive nenhum problema. ”

 

Lead: *PLONK*

 

Isto acontece não apenas para downloads aleatórios, mas quando seu código não estava funcionando e então magicamente ele funcionou e você resolve utiliza-lo um dia. Pode ser difícil perceber quando alguém está confiando na fé para decidir o quão bom é o seu software, mas se isso se prolongar por muito tempo, o resultado será um software lento de cheio de bugs.

 

Revelação

Por revelação, quero dizer quando uma figura de autoridade revela algo como incontestavelmente verdadeiro, ou algum fato que tem sido transmitido até hoje, e você acredita ser verdade simplesmente porque se acredita ser verdade. Se você associar isso com a necessidade de as pessoas se identificarem com algum assunto aleatório da comunidade de programação, vai descobrir que essa é a causa raiz de discussões calorosas sobre qual editor de textos reina supremo e se a linguagem que usa faz de você um verdadeiro programador.

 

Carisma

A conferência está repleta com uma atmosfera de euforia, empolgação para o anúncio do que virá a ser o próximo framework. Um palestrante empolgado chega ao palco com uma voz altissonante.  A fala e os slides discorrem sobre os mais novos princípios que prometem práticas de programação a prova de balas – do tipo que fará de você um programador 10X melhor. Com uma habilidade natural para interagir com a plateia e conduzir muito bem o tema da palestra, pode ser difícil de perceber que passamos a acreditar em suas afirmações, e o mais importante, comprando seus livros.

 

Brilho

Percebo que esta é uma palavra estranha para usar, mas quando uma ideia é atraente e empolgante o suficiente isto parece dar um certo “brilho”.  É “brilhante” e, portanto, deve ser verdadeiro. Poderíamos continuar, mas afastar-se desse tipo de desejo (ou sentimento) é o que significa ser científico sobre o nosso progresso tecnológico.

 

Expanda seus conhecimentos na área

Uma conversa sobre a natureza do universo geralmente é mais interessante quando as pessoas envolvidas são pessoas cientificamente alfabetizadas. Igualmente, uma conversa sobre programação beneficia a todos elevando a um certo patamar os seus conhecimentos. De fato, existem conhecimentos já bem difundidos sendo utilizado em novos sistemas computacionais, e os programadores deveriam estar atentos a isso.  Se nos intitulamos profissionais, temos uma grande responsabilidade em aprender os conceitos fundamentais da computação. Isso nos protege de fontes de informação não confiáveis e nos mostra aquilo de devemos prestar atenção. A NASA percebeu isso e garantiu que a cultura da organização seja capaz de expandir rapidamente seus conhecimentos.

 

Recomendações

Alguma coisa lhe chamou a atenção? Você é um programador procurando melhorar seus conhecimentos? Se for, eu tenho algumas sugestões pessoais.

Computer System’s: A Programmer’s Perspective: Foi muito importante na minha carreira, e para constar, este é meu conteúdo favorito de programação. Os temas apresentados aqui são os fundamentos que eu acho que todos deveriam ter. Pelo menos um estudo mais aprofundado dos capítulos 1-3, a hierarquia de memória e os sistemas de entrada e saída são excelentes. Se você está trabalhando em qualquer coisa relacionada a web, é claro que o capítulo sobre redes é de extrema importância.

Encontrando pessoas com o mesmo interesse

Existe uma pequena comunidade chamada Handmade Network, essa comunidade possui um time incrível (eu faço parte do time) onde tentamos construir um lugar em que evitamos conversar sobre softwares modernos, em vez disso, falamos sobre coisas que eu citei aqui. Assim como em qualquer comunidade, somos passíveis de cair em um dogma (já aconteceu no passado) mas estamos cientes disso.

Na comunidade também há entrevistas com programadores conhecidos discutindo diversos assuntos independentemente de nossas ideias. Confira algumas aqui.

 

Blogs/sites relacionados:

 

Abner Coimbre foi um estagiário do Kennedy Space Center no ano de 2015 e no ano de 2016 foi nomeado como Kennedy’s 2016 top 10 innovators. Onde encontra-lo: Twitter, Twitch ou e-mail.

Padrão
.NET, Banco de Dados, Certificação, Dica de leitura, Mova-se, Técnicas, Visual Studio

Certificações Microsoft – Por onde começo?

Olá pessoal, o objetivo desse post é esclarecer um pouco mais sobre a nova linha de certificações Microsoft, e também ajudar a direcionar aquele profissional que pretende obter uma certificação mas não sabe por onde começar.

A Microsoft criou uma linha de certificações chamada MTA – Microsoft Technology Associate. Essas provas são a “base da pirâmide” para uma carreira nas tecnologias Microsoft. O objetivo dessas provas são fornecer um conhecimento sólido dos fundamentos na tecnologia em que você pretende se especializar. Fazendo uma prova MTA, você já é um MTA Certification e já possui os conhecimentos fundamentais para seguir em frente.

Dentro do nível MTA, o profissional deve escolher qual área pretende seguir carreira, podendo optar por uma das três áreas conforme figura 1.

Áreas Microsoft

Figura 1 – Áreas na plataforma Microsoft

Mais detalhes: http://www.microsoft.com/learning/en-us/mta-certification.aspx

Como já sabemos o nível MTA visa garantir o conhecimento necessário para as outras provas (MCSD e MCSA ou quem sabe um dia MCM), então essa prova é obrigatória? Não, você não precisa se tornar um MTA para fazer as outras provas. Se você já é um profissional que tem experiência na sua tecnologia, então você pode pular esse nível. Porém se você está começando agora, certamente esse é o seu ponto de partida na carreira.

Em resumo, agora temos o nível MTA (de cada área) para iniciar, e a partir desse nível, cada um escolhe a carreira que pretende seguir. Para compreender melhor como ficou o RoadMap das provas vamos ver a figura 2.

Provas Microsoft

Clique para Download em PDF.

Figura 2 – RoadMap das provas

Existem dois centros de testes que você pode agendar a sua prova, Certiport para quem é estudante e Prometric para quem não possui nenhum vínculo acadêmico. Para o caso dos estudantes, é necessário verificar se a sua instituição está registrada no Certiport, verifique com seu professor ou chefe do departamento.

Um caminho para aprender e ajudar na preparação para as provas no nível MTA é através do Microsoft Virtual Academy que oferece diversos treinamentos gratuitos para desenvolvedores, profissionais de infra e banco de dados.

Lembrando que o mercado está carente de profissionais qualificados, enquanto sobram ideias, planos de marketing, investimentos dos mais variados, profissionais com uma boa qualificação ainda são uma pequena parcela do mercado, portanto uma certificação será muito bem vinda!

 Abraços!

Padrão
.NET, Boas Práticas, Técnicas

String VS StringBuilder – O Coiote não pega o Papa Léguas!

O título desse post remete a dois personagens bem conhecidos de todos (principalmente das crianças) em que um deles sempre tenta capturar o outro, porém esse último é muito mais veloz e raramente se dá mal. A ideia por trás dessa analogia é que algumas vezes tentamos utilizar tipos de dados com limitações de desempenho em nossos códigos e então saímos fazendo mil coisas (“gambiarras”) para tentar se aproximar do melhor desempenho possível, nem preciso comentar o resultado final. Esse fato no leva ao problema de atualização de conhecimento, pesquisas, estudos sobre as novidades de uma linguagem e/ou uma ferramenta. Aquela famosa frase “Para quem só conhece o martelo como ferramenta, parafuso é prego” cabe perfeitamente aqui.
Quando precisamos trabalhar com strings, o primeiro tipo que vem a mente é o tipo String ou string (essa última é apenas um apelido). Legal, esse é o tipo mais conhecido, e naturalmente, mais usado. Acontece que um objeto do tipo String é imutável, o que isso significa? Significa que uma vez atribuído um valor a um objeto desse tipo, esse valor jamais mudará, isso mesmo, jamais mudará. Mas então como eu consigo fazer concatenações e o novo valor é atribuído ao objeto? O que ocorre por baixo dos panos é algo que talvez você nunca imaginasse, a cada nova atribuição de valor a um objeto String, é criado um novo objeto semelhante que agora contém o valor antigo mais o valor atual. Isso mesmo, um novo objeto é criado e isso é transparente aos desenvolvedores. Você simplesmente solicita o valor do objeto e lá está ele.
No momento em que um novo objeto é criado, o objeto antigo continua na memória heap a disposição do garbage collector. A figura 1 mostra esse cenário, podemos ver que ao final das concatenações sucessivas temos um único objeto que iremos trabalhar e mais quatro objetos aguardando para serem eliminados da memória.

StringVSStringBuilderFigura 1

A cada nova iteração criamos um novo objeto e descartamos o antigo, isso causa um overhead imenso nas aplicações e um péssimo aproveitamento da memória do computador. Ma então o que devemos fazer quando precisarmos utilizar strings em iterações? A solução presente no .NET chama-se StringBuilder. Essa classe foi especialmente desenhada para trabalhar com strings dinâmicas, strings em que o valor muda constantemente e garante uma performance excelente quando recebe grande quantidade de dados. Os métodos disponíveis para trabalhar com StringBuilder fazem uma referência a mesma instância e não a uma nova como no caso da String. Vamos ver na prática como isso funciona. A figura 2 mostra dois métodos, o primeiro faz um loop de 20000 iterações utilizando um objeto StringBuilder e ao final exibe em milissegundos o tempo gasto. O segundo método faz a mesma coisa porém utilizando um objeto String.

ExemploCodigo

Figura 2

ExemploStringBuilder_2

Figura 3

Ao compararmos os resultados da figura 3, podemos concluir a enorme diferença no tempo de execução. Quando chamamos o método que utiliza String, gastamos um tempo de 2637 milissegundos e o mesmo loop utilizando StringBuilder consumiu apenas 10 milissegundos.
Então o tipo de dados String é um tipo ruim de trabalhar? A resposta é que String não é um tipo de dados ruim para trabalhar, porém ela atende exatamente aquilo que ela se propôs a atender, trabalhar com strings estáticas ou com poucas mudanças.

Abraços!

Padrão
Boas Práticas, Fundamentos, Técnicas

Design Patterns – Singleton

Olá Pessoal,

No mundo da O.O. uma das  práticas que podemos aplicar em diversos cenários são os Design patterns (ou Padrões de Projeto), que por sinal são modos de resolver problemas recorrentes e que garantem boa reutilização e também expressam de uma forma elegante a resolução de um determinado problema.

Os Design Patterns são classificados em:

  • Padrões de Criação;
  • Padrões  de Estruturas e
  • Padrões de Comportamento.

Cada uma dessas classificações acima englobam diversos tipos de padrões. Nesse post abordaremos o Design Patterns chamado Singleton. Esse Pattern é caracterizado por permitir apenas uma instância de um objeto no sistema e fornecer um ponto de acesso a essa instância, sendo caracterizado como um padrão de criação.

Existem contextos em que poderá haver a necessidade de ter esse tipo de implementação. Por exemplo com classes que possuem dados sobre o sistema, sobre um determinado dispositivo. Imagine que você esta trabalhando em uma aplicação mobile e precisa capturar algum dado do aparelho, ou atualizar determinada informação. Outro exemplo seria configurações de um aplicativo que poderiam ser solicitadas em determinados momentos da execução. Diversos são os cenários que podemos aplicar essa técnica.

O padrão Singleton também é alvo de várias discussões, alguns acham que não há necessidade de utilizar dessa forma, outros preferem combinar padrão Factory, pois poderá limitar a herança e/ou polimorfismo. Enfim, essa é uma discussão para outro momento.

Para transformar uma classe em Singleton existem 3 modificações a serem feitas na classe.

1 – Criar uma instância privada e estática dessa classe;

2 – Criar um método que seja o ponto de acesso ao único objeto criado e

3 – Tornar o construtor padrão privado.

Abaixo temos uma classe chamada Dispositivo bem simples, vamos transformá-la num Singleton. A classe possui dois atributos (Marca e Modelo) e dois métodos chamados Ligar e Desligar além da sobrecarga do método ToString Conforme figura 1.

Singleton1Figura 1 – Classe Comum de Um Dispositivo

Com a nossa classe comum, vamos fazer as três alterações citadas acima para transformá-la num Singleton. As alterações podem ser acompanhadas na figura 2.

Singleton2

Figura 2 – Classe com as alterações necessárias para atender o padrão Singleton.

A partir desse momento, a forma de utilização dessa classe deixa de ser como já conhecemos, não podemos mais instanciar um objeto dessa classe usando o operador new, isso é feito internamente pelo método getInstance que passa a ser o nosso ponto de acesso ao objeto da classe Dispositivo. Na figura 3 podemos ver como deverá ser utilizada.

Singleton3Figura 3 – Exemplo de uso

Essa é a forma que deverá ser utilizada. O método getInstance, verifica se há alguma instância já criada, caso não haja, será criada uma nova instância senão, ele retornará a instância já existente. A Figura 4 mostra o exemplo em funcionamento.

Singleton4

Figura 4 – Exemplo em execução

Bom, essa é uma forma de tratar um tipo de situação num determinado contexto, porém isso exige cuidado na aplicação ou seja, quando aprendemos sobre Design Patterns, costumamos contrair uma doença chamada “Patternite” onde queremos aplicar sempre, seja qual for o pattern. Porém o ideal é deixar que a plicação “peça” o padrão mais adequado, o desenvolvedor perceberá que aquela situação será bem tratada se for aplicado o pattern X.

Quanto ao Singleton, existe um detalhe que será comentado num próximo post, ele não é thread safe, ou seja se mais de uma thread solicitar esse objeto, teremos problemas, e existem formas de contornar essa situação que serão vistas em breve!

Abraço!

Padrão
Processos, Técnicas

Agilidade X Qualidade de Software

 Olá pessoal, um dia desses, a Sara Barbosa colocou a seguinte questão no twitter: “Agilidade não é o mesmo que qualidade, Qualidade não é o mesmo que agilidade ?!” Preferi não responder na hora pois essa é uma questão que envolve muitos pontos de vista, e são inúmero os fatores que podem influenciar um projeto. A interpretação que dei a essa questão é se um produto desenvolvido de forma ágil sempre terá qualidade e se um produto de qualidade significa que foi desenvolvido de forma ágil.

Bom, primeiro precisamos ter uma definição sobre o que é qualidade de software. O primeiro ponto, sobre esse assunto é, qualidade para quem? Cliente ou desenvolvedor ou ambos? Claro que o ideal é que o produto tenha qualidade para o cliente e para o desenvolvedor, pois isso resultará em bons resultados na entrega, manutenção e evolução do software.

Os processos ágeis têm como principal objetivo a adaptação as mudanças, pois sabemos que elas são inevitáveis. A partir do momento em que começamos a parar de lutar contra as mudanças e passamos a utilizá-las para atingir o nosso objetivo, teremos como resultado um produto com maior qualidade para o nosso cliente e também para os desenvolvedores. Existem práticas ágeis de desenvolvimento que contribuem muito para obter um código mais limpo, mais legível e consequentemente mais fácil de manter e evoluir. Práticas da XP (Extreme Programming) como programação em par e TDD são bons exemplos que podemos utilizar. Portanto, quando trabalhamos com processos ágeis, estamos mais próximos dos objetivos e consequentemente da qualidade do produto.

Quando temos um produto de software de boa qualidade nas mãos, não necessariamente isso significa que ele foi desenvolvido por um processo ágil. Em primeiro lugar, vamos analisar a seguinte questão: Qual é a metodologia (ou processo) de desenvolvimento mais ágil que existe? Talvez muitas coisas venham em sua mente agora, mas a resposta a essa pergunta, é o famoso DEPENDE. Por que? Porque a agilidade empregada em uma organização pode variar, ela depende do tamanho do time de desenvolvimento, depende dos recursos disponíveis, do tamanho do projeto, da presença de alguém fornecendo feedback e acompanhando o desenvolvimento do produto, etc. Para uma organização envolvida em um projeto de grande porte, geograficamente distribuído e envolvendo dezenas de desenvolvedores, talvez um RUP seja o processo mais ágil que eles consigam trabalhar, ou até mesmo um Waterfall. Nesse cenário, o caminho até o objetivo final pode ser mais oneroso, mas isso não significa que o resultado não seja um produto de boa qualidade.

Portanto, adotando processos ágeis estamos caminhando para um resultado de qualidade, tanto para o cliente quanto para o desenvolvedor, porém a agilidade não é o único caminho para se atingir a qualidade esperada num produto de software, sendo assim, qualidade não necessariamente significa agilidade.

Recomendo fortemente dar uma lida no texto produzido por Klaus Wuestefeld entitulado:  O Círculo Vicioso do Software Retranqueiro, retrata bem o cenário que vivemos no desenvolvimento de softwares.

Padrão
Técnicas

Não testar x TDD

Olá pessoal, esse post foi sugerido por um amigo meu, Leonardo Cidral, ele indicou esse assunto, e é um tema bem interessante e que está cada vez mais em evidência no desenvolvimentos de softwares, então vamos lá.

Testar aplicações deve ser um item primordial do desenvolvimento de sistemas, faz parte do seu profissionalismo. Você não terá um sistema estável, fácil de modificar, com baixo custo de manutenção se você não realiza testes. Isso mais cedo ou mais tarde, acarretará grandes problemas.

Existem 2 tipos de desenvolvedores  que não realizam testes:

  •  Chuck Norris
  •  Desenvolvedor amador

Você é Chuck Norris? Provavelmente não, então já sabe qual sua classificação.

“Desenvolvedor que não testa, é como um cirurgião que não lava as mãos!” (Robert C. Martin “Uncle Bob”). 

Mas o que é TDD?

A sigla significa Test Driven Development – Desenvolvimento Dirigido por Testes. È uma técnica que visa escrever os testes antes mesmo de escrever o código fonte! Estranho? No começo pode parecer que sim, mas com o tempo você verá os benefícios que ele trará no seu dia a dia.

Essa prática foi popularizada por Kent Beck na eXtreme Programming (XP), ela parte da ideia que será escrito um código apenas para o teste falho passar. Não haverá linhas de códigos desnecessárias no seu sistema, cada parte do seu código será testada antes de entrar em produção.  

Como funciona?

TDD = Test First Desing (TFD) + Refactoring

A primeira coisa a se fazer é escrever um pequeno teste antes mesmo de o código existir.  O primeiro teste escrito irá falhar, claro, ainda não há código para testar, em seguida você escreve o código e testa novamente, se passar, o próximo passo é a refatoração. A partir daí esse é o ciclo que será seguido. É importante que você avance os testes seguindo os baby steps, ou seja, avance em passos bem curtos, para ter um bom controle do seu código, com o passar do tempo, você começa a adquirir segurança nessa técnica, pode ir um pouco além, mas é sempre prudente e recomendado que não avancemos muito na hora de escrever um teste.

Fluxo TDD

Um desing limpo e agradável.

Imagine a seguinte situação, você vai até a cozinha prepara o alimento, se alimenta e sai, você não lavou a louça. No dia seguinte repete a situação, e no outro também e assim vai fazendo…. Essa rotina de preparar se alimentar e sair, é a mais rápida nesse momento, você consegue ganhar tempo com isso, porém algum tempo depois você terá uma cozinha imunda, você não tem nem coragem de entrar nela, a sua vontade nesse momento seria eliminá-la do resto da sua casa e reconstruir uma nova, nem as baratas conseguem sobreviver mais lá.

Essa analogia, é exatamente o que ocorre com os códigos  criados de qualquer jeito, chega um momento que os programadores têm medo de fazer qualquer alteração, aquele fonte agora tem vida própria, é praticamente um hardware, é impossível alterar ele sem causar outros problemas. Durante  o seu desenvolvimento, as funcionalidades eram adicionadas sem o mínimo de cuidado, não havia refatoração nesse código, não havia o mínimo de boas práticas, havia muito CTRL+C e CTRL+V. Não podemos negar que há também outros fatores que contribuem para isso.

O TDD garante um desing limpo, ágil, produtivo no momento atual e no futuro também. Todo o seu código fonte é escrito na medida em que atende a especificação, nada além disso será necessário, em seguida você executa o teste e se ele passar, pronto, só refatorar . Quem está no comando agora são as especificações de testes que foram criadas, elas são quem guiarão o seu fonte para atingir o resultado.

Quando você usa TDD, seu resultado será um código bem testado, refatorado, limpo, onde  sua manutenção será extremamente rápida e produtiva hoje e no futuro, e não haverá funcionalidades surpresa para o usuário, o código está livre de bugs, o programador tem segurança no seu código, grandes alterações não afetarão o funcionamento do sistema.Precisamos deixar claro que o TDD não é de uso obrigatório, mas testes SÃO OBRIGATÓRIOS

Um ponto que merece ser destacado é que o TDD se utiliza dos testes para dirigir o desenvolvimento, mas o foco real é o design da aplicação, e não os testes, ou seja, no momento que você escreve um teste e o código ainda não existe, então não há testes nesse momento, o que há é uma especificação para atender um determinado requisito, no instante seguinte, você escreve o código, realiza o teste e ele passa, agora você tem um teste nas mãos, mas antes disso aquela especificação não testava nada, apenas especificava algo. 

No exato momento em que escrevo esse post (02:25 da manhã), vejo na tv uma reportagem sobre o sistema da Prodesp que está causando uma enorme dor de cabeça para unidades do DETRAN em São Paulo, o sistema trava, e não mais retorna, alunos são dispensados das aulas, outros aguardam um tempão para tentar fazer suas aulas, os funcionários estão no limite da paciência. A Prodesp se manifestou por telefone, informando que tem conhecimento do problema, e está trabalhando para corrigir. Alegam que o problema tem como causa, o grande número de instrutores que acessam o sistema simultaneamente.

Será que existe algum teste que poderia prever essa situação? Claro que sim! Será que tiveram o cuidado de fazer? Acho que a reportagem já respondeu!

Atenção! TESTES SÃO OBRIGATÓRIOS!

Referências:

 http://www.agiledata.org/essays/tdd.html

http://unplugged.giggio.net/unplugged/post/TDD-nao-existe.aspx

Abraços!

Padrão