Kent Beck - Extreme Programming. Desenvolvimento Orientado a Testes

Gênero:,

Series:
Restrições de idade: +
Língua:
Linguagem original:
Tradutor (es):
Editor:
Cidade de publicação: São Petersburgo
O ano de publicação:
ISBN: 978-5-496-02570-6 O tamanho: 382 Kb

Detentores de direitos autorais!

O fragmento da obra apresentado foi postado por meio de convênio com a distribuidora de conteúdo jurídico LLC "Litros" (no máximo 20% do texto original). Se você acredita que a postagem do material viola os direitos de alguém, então.

Leitores!

Você já pagou, mas não sabe o que fazer a seguir?

Atenção! Você está baixando um trecho permitido por lei e pelo detentor dos direitos autorais (não mais que 20% do texto).
Após a revisão, você será solicitado a acessar o site do detentor dos direitos autorais e comprar a versão completa da obra.

Descrição do livro

O retorno do famoso best-seller. Código elegante, flexível e compreensível, fácil de modificar, que funciona bem e que não traz surpresas desagradáveis aos seus criadores. Isso é realmente possível? Para atingir seu objetivo, experimente testar seu programa antes de escrevê-lo. É essa ideia paradoxal que fundamenta a metodologia TDD (Test-Driven-Development). Absurdo? Não se apresse em tirar conclusões precipitadas. Considerando o uso de TDD no exemplo de desenvolvimento de código de programa real, o autor demonstra a simplicidade e o poder desta técnica. O livro contém dois projetos de software, totalmente implementados usando TDD. Os exemplos são seguidos por um extenso catálogo de técnicas de estilo TDD e padrões e refatorações relacionados a TDD. O livro será útil para qualquer programador que deseja aumentar a produtividade de seu trabalho e gostar de programar.

Última impressão do livro

SharerSharpened:
16-12-2018, 02:17

Antes de ler este livro, tentei fazer testes para os artigos que li, mas só com isso comecei a ficar bom.

Eu li duas vezes. Na primeira vez, acabei de ler.

Não entendeu nada. Na segunda vez, escrevi o código enquanto lia o livro e, finalmente, percebi o que estava acontecendo e, o mais importante, senti o tamanho do meu passo pelo qual posso alterar o código e, ao mesmo tempo, não perder o controle sobre ele. Fiquei satisfeito com o segundo capítulo em que, junto com o autor, ele escreveu seu sistema de teste de unidade em Python, a sensação era como se você estivesse fazendo uma operação em seu próprio cérebro (na verdade, o próprio autor fez essa comparação) - um movimento descuidado e nada funciona, você precisa se mover em passos muito pequenos. Eu li o terceiro capítulo seletivamente, talvez um dia eu leia.

Colapso

⬇ Outros comentários

Este livro é sobre programação extrema. A programação extrema, geralmente chamada de "XP", é uma metodologia de produção simplificada para equipes de desenvolvimento de pequeno a médio porte. produto de software face a requisitos pouco claros ou que mudam rapidamente. Este livro tem como objetivo ajudá-lo a determinar se o XP é apropriado para sua situação ...

Sobre a série XP

Extreme Programming, muitas vezes referido como XP, é uma disciplina de desenvolvimento Programas e fazer negócios na área de criação de produtos de software, que concentra os esforços de ambas as partes (programadores e empresários) em objetivos comuns e bastante alcançáveis. As equipes XP estão produzindo software de qualidade em grande velocidade. As técnicas que fazem parte da disciplina XP descrita neste livro foram escolhidas porque são baseadas na criatividade humana e na aceitação de que uma pessoa é uma criatura instável e sujeita a erros.

O XP é frequentemente apresentado como uma coleção de técnicas, mas o XP em si não é uma linha de chegada. Você não precisa praticar e desenvolver XP cada vez melhor para obter a tão esperada estrela de ouro no final deste processo. Pelo contrário, o XP é a linha de partida. O XP faz a pergunta: "Até que ponto nossos esforços podem ser mínimos para que possamos continuar a produzir software de qualidade?"

O início da resposta à pergunta soa assim: se queremos desenvolver programas de qualidade sem desordem e confusão, devemos estar prontos para implementar total e completamente em nossa equipe várias técnicas, que vamos usar ao máximo. Se usarmos essas técnicas pela metade, os problemas permanecem e, para resolvê-los, será necessário passar ao uso pleno das técnicas. Se nos limitarmos a meias medidas, com o tempo ficaremos tão confusos com elas que não seremos capazes de entender que as principais coisas que são criadas pelo trabalho dos programadores nascem graças à programação.

Eu disse "comece a resposta para" porque a continuação realmente não existe. As pessoas que criaram e implementaram o XP também pensaram em resolver esse problema. Depois de tentar usar o XP, eles ultrapassaram o limite e foram para o desconhecido. Quando eles voltaram, eles contaram sua história. Seus pensamentos são placas colocadas ao longo da estrada: “Dragões vivem aqui”, “Depois de 15 km boa Vista"," Esta área é perigosa na chuva. "

Sinto muito, mas é hora de eu ir para o programa.

Prefácio

Programação extrema (

programação extrema

XP) define a codificação como uma atividade chave e fundamental ao trabalhar em um projeto de software. Pode estar errado!

Acho que vale a pena lembrar minha própria experiência em desenvolvimento de software. Eu trabalho em um ambiente onde o produto em desenvolvimento está constantemente em condição de trabalho e, ao mesmo tempo, mudanças estão constantemente sendo feitas nele. O cronograma de lançamento para a próxima versão funcional é monstruosamente apertado e, ao mesmo tempo, um enorme risco técnico paira sobre tudo isso. Em tal ambiente, a habilidade de consertar o companheiro de armas é uma arte sem a qual não se pode sobreviver. A troca de informações dentro de uma equipe e entre várias equipes, muitas vezes separadas geograficamente, é feita por meio de código. Lemos o código para entender a estrutura de interfaces de programação de sistema novas ou modificadas. Ciclo da vida e comportamento objetos complexos são definidos usando casos de teste, ou seja, novamente usando código. Os relatórios de problemas são acompanhados por casos de teste que demonstram o problema, novamente usando o código para isso. Finalmente, estamos constantemente ocupados melhorando o código existente, tornando-o mais produtivo, mais flexível e mais compreensível. É óbvio que em tais condições o desenvolvimento de um produto de software é quase inteiramente baseado na codificação, mas ao mesmo tempo conseguimos concluir com sucesso os projetos no prazo, portanto, esta abordagem bastante viável.

Não presuma que tudo que você precisa para implementar com sucesso um projeto de software é uma programação brutal imprudente. Desenvolver software é muito difícil, e desenvolver software de alta qualidade e fazer o trabalho dentro do prazo é ainda mais difícil. Para que a abordagem que descrevi funcione, você precisa aplicar de forma consistente regras e técnicas adicionais importantes. É aqui que Kent Beck começa seu livro instigante sobre XP.

Fiz uma parceria com Kent e usei os episódios XP em um projeto pequeno, mas infame, chamado JUnit.

Introdução

Este livro é sobre programação extrema (

programação extrema

XP). Extreme Programming é uma metodologia de produção simplificada para pequenas e médias equipes de profissionais envolvidos no desenvolvimento de software em um ambiente de requisitos pouco claros ou que mudam rapidamente. Este livro tem como objetivo ajudá-lo a determinar se o XP é apropriado para sua situação.

Para muitos, XP parece um conjunto de métodos de organização do trabalho bastante aceitáveis e justificados do ponto de vista do bom senso. Então, por que a programação XP é chamada de extrema? A questão é que o XP leva muitos dos princípios de programação amplamente aceitos e amplamente usados a níveis extremos.

Se a revisão do código for boa, então revisaremos o código constantemente (programação em pares);

Se o teste for bom, cada participante do projeto testará constantemente o código do programa (teste de unidade), até mesmo os clientes ( teste funcional);

Se o design for bom, então o design deve ser parte integrante do trabalho diário de cada um dos participantes do projeto (revisão do código);

Programação extrema

Dedicado ao meu pai e também obrigado a Cindee Andres, minha esposa e companheira, por exigir que eu a ignorasse e escrevesse. Agradeço a Bethany, Lincoln, Forrest e por não me distrair e me deixar escrever.

Sobre a série XP

A Extreme Programming, freqüentemente chamada de XP, é uma disciplina de engenharia de software e negócios de software que concentra os esforços de programadores e empresários em objetivos comuns e alcançáveis. As equipes XP estão produzindo software de qualidade em grande velocidade. As técnicas que fazem parte da disciplina XP descrita neste livro foram escolhidas porque são baseadas na criatividade humana e na aceitação de que uma pessoa é uma criatura instável e sujeita a erros.

Eu disse "comece a resposta para" porque a continuação realmente não existe. As pessoas que criaram e implementaram o XP também pensaram em resolver esse problema. Tendo tentado usar o XP, eles ultrapassaram o limite e foram para o desconhecido. Quando eles voltaram, eles contaram sua história. Seus pensamentos são placas colocadas ao longo da estrada: "Dragões vivem aqui", "Depois de 15 km, uma boa visão se abre", "Esta área é perigosa na chuva."

Sinto muito, mas é hora de eu ir para o programa.

Kent Beck, Consultor de Série

Prefácio

Programação extrema ( programação extrema, XP) define a codificação como uma atividade chave e fundamental ao trabalhar em um projeto de software. Pode estar errado!

Acho que vale a pena lembrar minha própria experiência em desenvolvimento de software. Eu trabalho em um ambiente onde o produto em desenvolvimento está constantemente funcionando e, ao mesmo tempo, mudanças estão constantemente sendo feitas nele. O cronograma de lançamento para a próxima versão funcional é monstruosamente apertado e, ao mesmo tempo, um enorme risco técnico paira sobre tudo isso. Em tal ambiente, a habilidade de consertar o próximo é uma arte sem a qual não se pode sobreviver. A troca de informações dentro de uma equipe e entre várias equipes, muitas vezes separadas geograficamente, é feita por meio de código. Lemos o código para entender a estrutura de interfaces de programação de sistema novas ou modificadas. O ciclo de vida e o comportamento de objetos complexos são definidos usando casos de teste, ou seja, novamente usando código. Os relatórios de problemas são acompanhados por casos de teste que demonstram o problema, novamente usando o código para isso. Finalmente, estamos constantemente ocupados melhorando o código existente, tornando-o mais eficiente, mais flexível e mais compreensível. Obviamente, em tais condições, o desenvolvimento de software é quase inteiramente baseado em codificação, mas ao mesmo tempo conseguimos concluir com sucesso os projetos no prazo, então essa abordagem é bastante viável.

Kent foi um dos executivos da Tektronix que reconheceu o enorme potencial da programação de par acoplado para o desenvolvimento de aplicativos de engenharia complexos em Smalltalk. Junto com Bard Cunningham (Ward Cunningham), Kent se tornou a inspiração para o desenvolvimento de técnicas de programação a partir de padrões (também é chamado de programação usando padrões - programação de padrões o que influenciou muito minha carreira. XP descreve uma abordagem para o desenvolvimento de software que combina técnicas usadas por vários desenvolvedores de sucesso que estudaram muita literatura sobre a organização do trabalho de programadores e experimentaram muitos métodos e procedimentos para desenvolver um produto de software. Como a programação por exemplo, o XP fornece um conjunto de melhores práticas, como teste de unidade, programação em pares e reescrita de código. No XP, essas técnicas são combinadas de forma a se complementar e freqüentemente controlar uma à outra. O objetivo principal deste livro é falar sobre a interação e o uso conjunto de várias técnicas. Todas as técnicas de programação têm um objetivo - a criação de um produto de software com uma determinada funcionalidade em um determinado prazo. O processo de software Just In Time altamente bem-sucedido da OTI não é XP em forma pura no entanto, há muito em comum entre as duas abordagens.

Eu colaborei com Kent e usei os episódios XP em um projeto pequeno, mas infame, chamado JUnit. Suas visões e abordagens para o desenvolvimento de software sempre me fizeram pensar sobre como eu pessoalmente me acostumei a trabalhar em um projeto de software. Sem dúvida, o XP desafia muitas das abordagens tradicionais usadas na indústria de programação. Depois de ler este livro, você pode decidir por si mesmo se precisa ou não usar XP em seu trabalho.

Programação extrema

Sobre a série XP

Sinto muito, mas é hora de eu ir para o programa.

Kent Beck, Consultor de Série

Prefácio

Programação extrema ( programação extrema, XP) define a codificação como uma atividade chave e fundamental ao trabalhar em um projeto de software. Pode estar errado!

Kent foi um dos executivos da Tektronix que reconheceu o enorme potencial da programação de par acoplado para o desenvolvimento de aplicativos de engenharia complexos em Smalltalk. Junto com Bard Cunningham (Ward Cunningham), Kent se tornou a inspiração para o desenvolvimento de técnicas de programação a partir de padrões (também é chamado de programação usando padrões - programação de padrões o que influenciou muito minha carreira. XP descreve uma abordagem para o desenvolvimento de software que combina técnicas usadas por vários desenvolvedores de sucesso que estudaram muita literatura sobre a organização do trabalho de programadores e experimentaram muitos métodos e procedimentos para desenvolver um produto de software. Como a programação por exemplo, o XP fornece um conjunto de melhores práticas, como teste de unidade, programação em pares e reescrita de código. No XP, essas técnicas são combinadas de forma a se complementar e freqüentemente controlar uma à outra. O objetivo principal deste livro é falar sobre a interação e o uso conjunto de várias técnicas. Todas as técnicas de programação têm um objetivo - a criação de um produto de software com uma determinada funcionalidade em um determinado prazo. O processo Just In Time Software altamente bem-sucedido da OTI não é puro XP, mas existem muitas semelhanças entre as duas abordagens.

Fiz uma parceria com Kent e usei os episódios XP em um projeto pequeno, mas infame, chamado JUnit. Suas visões e abordagens para o desenvolvimento de software sempre me fizeram pensar sobre como eu pessoalmente me acostumei a trabalhar em um projeto de software. Sem dúvida, o XP desafia muitas das abordagens tradicionais usadas na indústria de programação. Depois de ler este livro, você pode decidir por si mesmo se precisa ou não usar XP em seu trabalho.

Erich Gamma

Introdução

Este livro é sobre programação extrema ( programação extrema, XP). Extreme Programming é uma metodologia de produção simplificada para pequenas e médias equipes de profissionais envolvidos no desenvolvimento de software em um ambiente de requisitos pouco claros ou que mudam rapidamente. Este livro tem como objetivo ajudá-lo a determinar se o XP é apropriado para sua situação.

Se a revisão do código for boa, então revisaremos o código constantemente (programação em pares);

Se o teste for bom, cada participante do projeto testará constantemente o código do programa (teste de unidade), até mesmo os clientes (teste funcional);

Se o design for bom, então o design deve ser parte integrante do trabalho diário de cada um dos participantes do projeto (revisão do código);

Se a simplicidade for boa, então devemos manter o sistema o mais simples possível para fornecer o nível atual de funcionalidade necessário (a coisa mais simples que provavelmente funcionará); se a arquitetura é importante, então cada um dos participantes do projeto trabalhará constantemente na definição e revisão da arquitetura (metáfora);

Se o teste de integração for importante, será necessário coletar e testar o sistema desenvolvido várias vezes ao dia (integração contínua);

Se pequenas iterações são boas, você precisa torná-las muito, muito pequenas - segundos, minutos, talvez horas, mas não semanas e meses, e de forma alguma anos (jogo de planejamento).

Quando decidi articular a essência do XP para mim, imaginei um conjunto de alças no painel de controle. Cada alça correspondia a uma determinada técnica, sobre a qual a partir de seu experiência pessoal Eu sabia que era bastante eficaz. Cada alça permitia que uma ou outra técnica fosse usada até certo ponto, de 1 a 10. Tentei colocar todos os braços em sua posição máxima (10) e fiquei surpreso ao descobrir que toda a gama de técnicas que eu estava considerando permaneceu estável, previsível e flexível.

XP gera dois conjuntos de promessas:

O XP promete aos programadores que cada um deles trabalhará na solução de problemas realmente importantes todos os dias úteis. Cada um deles nunca se encontrará isolado. Cada um deles será capaz de fazer tudo ao seu alcance para tornar o sistema desenvolvido bem-sucedido. Cada um deles poderá tomar uma decisão exatamente na área em que for competente, e se em alguma área não for competente o suficiente, não participará da tomada de decisão.

O XP promete aos clientes e gerentes que eles tirarão o máximo proveito de cada semana de desenvolvimento do projeto. A cada poucas semanas, eles poderão ver o progresso em direção a seus objetivos. Eles poderão mudar a direção do projeto no meio do desenvolvimento, sem medo de custos extraordinários adicionais.

Resumindo, o XP promete reduzir o risco do projeto, melhorar a capacidade de resposta às mudanças nos negócios, melhorar a produtividade do projeto e tornar o desenvolvimento de software mais agradável - tudo ao mesmo tempo. Não estou brincando, pare de rir. Apenas leia este livro e você poderá verificar por si mesmo se estou louco.

Este livro

Este livro fala sobre coisas relacionadas ao método XP - suas raízes, filosofia, todos os tipos de histórias e mitos. O objetivo do livro é ajudá-lo a tomar uma decisão informada sobre o uso ou não do XP em seu próprio projeto. Se, depois de ler este livro, você decidir não usar XP ao trabalhar em seu projeto, considerarei o objetivo principal alcançado da mesma forma como se, depois de ler este livro, você tivesse decidido que XP é o que você precisa. . O segundo objetivo deste livro é ajudar aqueles de vocês que já estão usando XP. Após a leitura do livro, esses leitores poderão entender melhor essa técnica.

Este livro não contém instruções precisas sobre como exatamente o processo de programação extremo deve ser executado. Você não verá muitos exemplos, algoritmos ou histórias de programação nele. Para obter tudo isso, você pode pesquisar na Internet, conversar com alguns dos colaboradores do projeto, aguardar o aparecimento de livros sobre o assunto ou começar a criar esse tipo de material você mesmo.

O futuro destino da disciplina de desenvolvimento de software XP que descrevi está nas mãos de um grupo de pessoas (você pode ser uma delas) que estão insatisfeitas com o que existe em este momento métodos tradicionais de organização do trabalho dos programadores. Você precisa a melhor maneira desenvolvimento de software, você deseja construir relacionamentos mais produtivos e acolhedores com seus clientes, deseja que os programadores que trabalham sob sua direção sejam mais felizes, leais e produtivos. Em suma, você quer uma vantagem significativa e não tem medo de aproveitar novas ideias para obter essa vantagem. No entanto, antes de correr riscos, você quer ter certeza de que, pelo menos, não é um completo idiota.

O XP lhe diz para fazer seu trabalho de uma maneira muito diferente da que está acostumada. Em alguns casos, as recomendações do XP são completamente contrárias às normas geralmente aceitas. No este momento Eu acredito que o XP só pode ser usado por aqueles que têm um bom motivo para mudar a ordem existente das coisas. No entanto, se essas razões existem, você pode começar a usar o XP agora. Escrevi este livro para que você possa aprender mais sobre esses motivos.

O que é XP?

O que é XP? XP é uma maneira simplificada, eficiente, flexível, previsível, cientificamente sólida e altamente agradável de desenvolver software que inclui nível baixo risco. XP difere de outras técnicas nas seguintes maneiras.

Usando ciclos de desenvolvimento extremamente curtos, o XP oferece feedback rápido, real e permanente.

O XP usa planejamento incremental, resultando em um plano geral do projeto emergindo rapidamente, mas isso implica que esse plano evolui ao longo da vida do projeto.

O XP usa um cronograma flexível para fornecer funcionalidade para melhorar a capacidade de resposta às mudanças nos negócios e nos requisitos dos clientes.

XP é baseado em testes automatizados desenvolvidos por programadores e clientes. Graças a estes testes, é possível acompanhar o processo de desenvolvimento, garantir a correta evolução do sistema e detectar imediatamente os defeitos existentes no sistema.

XP é baseado em comunicação oral, testes e código-fonte. Essas três ferramentas são usadas para trocar informações sobre a estrutura do sistema e seu comportamento.

XP é baseado em um processo de design em evolução que dura tanto quanto o próprio sistema.

XP é baseado na interação próxima de programadores com as habilidades e capacidades mais comuns.

XP é baseado em técnicas que satisfazem os instintos de curto prazo de programadores individuais e os interesses de longo prazo do projeto como um todo.

XP é uma disciplina de desenvolvimento de software. Esta é uma disciplina porque há certas coisas dentro do XP que você deve fazer se pretende usar o XP. Você não tem que escolher se quer ou não escrever testes, porque senão, a programação que você está fazendo não é extrema: fim da discussão.

A metodologia XP é projetada para trabalhar em projetos que podem ser trabalhados por dois a dez programadores que não são limitados pela estrutura rígida do ambiente de computador existente e nos quais todo o trabalho necessário relacionado ao teste pode ser concluído em um dia.

O XP assusta ou irrita algumas pessoas que estão usando essa técnica pela primeira vez. No entanto, nenhuma ideia por trás do XP é nova. Em certo sentido, a metodologia XP é conservadora - todas as técnicas utilizadas em sua estrutura foram testadas por décadas (quanto à estratégia de implementação) e até séculos (quanto à estratégia de gerenciamento) de prática.

Novos no XP são os seguintes recursos:

Todas essas técnicas conhecidas estão reunidas sob o mesmo teto;

A intensidade com que essas técnicas estão sendo introduzidas no trabalho diário foi levada ao extremo;

As técnicas usadas apóiam-se mutuamente na medida do possível.

Adequação

Em suas obras O povo da floresta e a montanha o antropólogo Colin Turnbull descreve duas sociedades muito diferentes. Os recursos necessários para a vida são escassos nas montanhas e as pessoas estão sempre à beira da fome. A cultura que surgiu nessas condições parece assustadora. As mães abandonam seus filhos para sobreviverem por conta própria. A comida pode ser fatal. Crueldade, brutalidade e traição são comuns e cotidianas.

Ao contrário das montanhas, as florestas são ricas em recursos. Para se alimentar o dia todo, uma pessoa só precisa despender cerca de meia hora. A cultura da floresta é o oposto da cultura da montanha. Os adultos participam da criação e criação de filhos comuns, que crescem no amor e no cuidado até que sejam capazes de cuidar de si próprios. Se uma pessoa por engano mata outra (o assassinato deliberado não é familiar para essas pessoas), ela é expulsa da sociedade. Porém, neste caso, o exilado simplesmente tem que se retirar para a floresta e passar vários meses ali, e mesmo assim alguns membros da tribo lhe trazem alimentos e presentes.

XP é uma tentativa de responder à pergunta: Como você programaria pessoalmente se tivesse tempo suficiente? Na verdade, você não tem nenhum tempo extra, porque programar é um negócio, afinal. Em qualquer negócio, o vencedor é aquele que faz o trabalho mais rápido. No entanto, se você tivesse tempo, provavelmente prestaria atenção ao design do teste; você provavelmente faria uma nova arquitetura do sistema se chegasse à conclusão de que era necessário; você provavelmente se comunicaria mais com seus colegas programadores, bem como com o cliente.

Esse sentimento de suficiência parece mais humano em contraste com as situações em que os programadores estão lutando para permanecer dentro do prazo determinado, estão fora do cronograma, não têm tempo para concluir uma grande quantidade de trabalho extremamente importante apenas para ter tempo de concluir um projeto Tempo. A pressa impede que os programadores demonstrem totalmente seu talento e apreciem seu trabalho. No entanto, ao começar a aprender XP, você deve entender que a sensação de suficiência também é um bom negócio. Uma sensação de suficiência torna-se uma fonte de eficiência da mesma forma que uma sensação de falta dá origem a falhas no trabalho, leva ao aparecimento de defeitos e à diminuição da qualidade e, em última análise, à diminuição da produtividade do trabalho.

Plano de livro

O livro foi escrito como se você e eu estivéssemos juntos criando uma nova disciplina de desenvolvimento de software. Começamos explorando nosso conhecimento básico de desenvolvimento de software. Depois disso, nós realmente criamos uma nova disciplina. Em seguida, examinamos as implicações do que criamos - como pode ser implementado e usado na prática, quando não deve ser usado e que oportunidades abre para o negócio.

O livro está dividido em três partes.

Problema: nos capítulos começando com Risco: o principal problema e terminando Voltar à rotina, o problema que a programação extrema está tentando resolver é determinado e os critérios são estabelecidos pelos quais a qualidade da solução pode ser avaliada. Nesta parte, você terá uma visão geral da técnica de programação extrema.

Solução: nos capítulos começando com Breve revisão e terminando Estratégia de teste, as ideias abstratas apresentadas na primeira parte do livro se transformam em um conjunto de métodos de uma disciplina específica. Este capítulo não contém nenhuma informação sobre como exatamente você pode aplicar as técnicas descritas na prática. Em vez disso, trata-se da forma geral de cada uma das técnicas. À medida que discuto cada técnica, relaciono-a aos problemas e princípios discutidos na primeira parte do livro.

Implementação XP: nos capítulos começando com Implementação XP e terminando XP em ação, discute muitos problemas relacionados à implementação do XP - como implementar o XP, o que esperar das diferentes pessoas envolvidas em um projeto XP, que tipo de XP as pessoas têm no mundo dos negócios.

Agradecimentos

Estou falando aos leitores na primeira pessoa não porque o livro apresenta minhas próprias idéias, mas porque estou falando sobre minha própria percepção dessas idéias. A maioria das técnicas usadas no XP são tão antigas quanto toda a programação.

Ward Cunningham é minha principal fonte de material para o livro. De qualquer forma, passei os últimos quinze anos apenas tentando explicar a outras pessoas o que Ward vem fazendo na prática há muito tempo. Agradeço também a Ron Jeffries por tentar isso também e por fazer uma grande melhoria. Obrigado a Martin Fowler por explicar tudo isso em uma linguagem simples, suave e sem colapsos nervosos. Agradeço a Erich Gamma pelas longas conversas combinadas com a contemplação dos cisnes em Limm, e também por não me deixar deixá-lo com pensamentos ruins na cabeça. E, claro, nada disso teria acontecido na minha vida se eu não tivesse um modelo como meu pai, Doug Beck, que aprimorou suas habilidades de programação ao longo dos anos.

Agradeço à equipe C3 da Chrysler por me acompanhar em minha pesquisa. E também um agradecimento especial aos nossos gerentes Sue Unger e Ron Savage por terem a coragem de nos dar uma chance.

Agradeço à Daedalos Consulting por me ajudar a escrever este livro.

The Watching Champion vai para as mãos de Paul Chisholm por seus comentários abundantes, sucintos, escrupulosos e muitas vezes francamente irritantes. Sem a ajuda dele este livro não seria tão popular.

Eu realmente gostei de me comunicar com todos aqueles que realizaram antevisão do que escrevi.

Seu trabalho foi de grande ajuda para mim. Não encontro palavras de agradecimento pelo facto de terem tido a paciência de ler até ao fim toda esta prosa, muitas delas em língua estrangeira.

Agradecimentos a (listados aleatoriamente nos quais recebi comentários deles) Greg Hutchinson, Massimo Arnoldi, Dave Cleal, Sames Schuster, Don Wells, Joshua Kerievsky, Thorsten Dittmar, Moritz Becker, Daniel Gubler, Christoph Henrici, Thomas Zang, Dirk Koenig, Dierk Koenig Miroslav Novak, Rodney Rayan, Frank Westphal, Paul Trunz, Steve Hayes, Kevin Bradtke, Jeanine De Guzman, Tom Kubit, Falk Bruegmann, Hasko Heinecke, Peter Merel, Rob Mee, Pete McBreen, Thomas Ernst, Guido Guido Haechler, Dieter Holz , Martin Knecht, Dirk Crump ( Dierk Krampe, Patrick Lisser, Elisabeth Maier, Thomas Mancini, Alexio Moreno, Rolf Pfenninger e Matthias Ressel.

Da editora

Envie seus comentários, sugestões, dúvidas para o endereço E-mail [email protegido](editora Peter, edição para computador).

Adoraríamos ouvir de você!

Você pode encontrar todos os textos fonte no livro em http://www.piter.com/download.

No site da editora http://www.piter.com, você encontrará informações detalhadas sobre nossos livros.

Problema

Esta parte do livro prepara a cena em que a programação extrema deve aparecer no futuro. Ele descreve vários aspectos do problema a serem resolvidos pela formação de uma nova disciplina de desenvolvimento de software.

Esta parte discute as suposições básicas que precisamos ter em mente ao escolher nossa metodologia de desenvolvimento de software - a metáfora motriz, os quatro significados, os princípios formados a partir desses significados e as atividades que precisam ser estruturadas dentro da nova disciplina de desenvolvimento de software.

Risco: o principal problema

As disciplinas existentes de desenvolvimento de software não funcionam e não dão o efeito econômico desejado. Este problema tem um enorme significado econômico e humanitário. Precisamos de uma nova forma de desenvolvimento de software.

O principal problema no desenvolvimento de software é risco.

Aqui estão alguns exemplos de risco.

Gráficos de compensação- chega o dia da entrega da obra e você é obrigado a informar ao cliente que o sistema em desenvolvimento só estará pronto nos próximos seis meses.

Fechando um projeto- após vários turnos de cronograma e adiamentos da data de entrega, o projeto é encerrado, mesmo sem ser levado à fase de teste em condições de trabalho.

O sistema perde sua utilidade- o software desenvolvido é instalado com sucesso em um ambiente de trabalho de produção real, mas depois de alguns anos de uso, o custo de fazer alterações nele e / ou o número de defeitos aumenta tanto que fica mais barato substituir o sistema por um novo desenvolvimento.

- o sistema de software está instalado em um ambiente de trabalho de produção real, mas o número de defeitos e deficiências é tão grande que o sistema não é utilizado.

- o sistema de software é instalado em um ambiente de produção real, mas na verdade ele não resolve o problema de negócios que originalmente pretendia resolver.

Mudando a natureza dos negócios- o sistema de software está sendo instalado em um ambiente real de produção, mas nos últimos seis meses, o problema que o sistema pretendia resolver perdeu sua relevância e, em vez disso, o negócio se depara com um problema novo, ainda mais sério.

Falta de oportunidades- o sistema de software tem muitos recursos potencialmente interessantes, cada um dos quais era muito agradável de programar, mas nenhum desses recursos não traz muitos benefícios para o cliente.

Rotatividade de pessoal- dentro de dois anos de trabalho, todos bons programadores que trabalhou no projeto, um a um, odiou o sistema de software desenvolvido e saiu para outro emprego.

Nas páginas deste livro, você lerá sobre programação extrema ( programação extrema, XP) é uma disciplina de desenvolvimento de software que se concentra na redução de riscos em todos os níveis do processo de desenvolvimento. O XP ajuda a aumentar significativamente a produtividade e a melhorar a qualidade dos programas desenvolvidos, além disso, é uma prática muito divertida que proporciona muito prazer a todos os seus participantes.

Como o XP atenua os riscos acima?

Gráfico de deslocamento- O XP propõe o uso de tempos de lançamento muito curtos para cada versão seguinte. Presume-se que cada próxima versão pronta para uso do sistema seja desenvolvida em no máximo vários meses. Assim, a quantidade de trabalho dentro de cada versão é limitada, o que significa que se houver um deslocamento, é menos significativo. Cada versão incluirá várias iterações dos recursos solicitados pelo cliente, cada uma delas levando de uma a quatro semanas para ser desenvolvida. Isso fornece feedback flexível e responsivo ao cliente, para que ele tenha uma ideia do andamento atual do trabalho. Dentro de cada iteração, o planejamento de acordo com o XP é executado em termos de várias tarefas que precisam ser resolvidas para obter a próxima iteração. Um a três dias são alocados para a solução de cada uma das tarefas. Como resultado, a equipe pode detectar e corrigir problemas mesmo durante a iteração. Finalmente, o XP assume que os recursos de maior prioridade serão implementados primeiro. Portanto, quaisquer recursos que não possam ser implementados na estrutura desta próxima versão do produto de software têm uma prioridade mais baixa.

Fechando um projeto- no XP, o cliente deve determinar o menor conjunto permitido de recursos que a versão mínima viável do programa deve ter e que faça sentido do ponto de vista da resolução de problemas de negócios. Assim, os programadores precisarão fazer um esforço mínimo para que o cliente entenda se ele precisa ou não desse projeto.

O sistema perde sua utilidade- dentro do XP, é criado e mantido um grande número de testes, que são iniciados e reiniciados após qualquer alteração no sistema (várias vezes ao dia), graças a isso é possível monitorar atentamente a qualidade do programa que está sendo desenvolvido . O XP mantém o sistema em excelentes condições o tempo todo. Os defeitos simplesmente não podem se acumular.

Número de defeitos e deficiências- no XP, o sistema que está sendo desenvolvido é testado tanto por programadores que criam testes para cada função individual sendo desenvolvida, quanto por clientes que criam testes para cada recurso individual do sistema implementado.

Inconsistência com o problema sendo resolvido- no XP, o cliente é parte integrante da equipe que trabalha no projeto. A especificação do projeto é constantemente revisada ao longo de todo o período de trabalho no projeto, pelo que quaisquer esclarecimentos e descobertas que o cliente informe a equipe de desenvolvimento são imediatamente refletidos no programa desenvolvido.

Extreme Programming: Test Driven Development

Dedicado a Cindy: as asas da minha alma

Direitos de publicação obtidos por acordo com Addison-Wesley Longman. Todos os direitos reservados. Nenhuma parte deste livro pode ser reproduzida em qualquer forma sem a permissão por escrito dos detentores dos direitos autorais.

As informações contidas neste livro foram obtidas de fontes consideradas confiáveis pelo editor. No entanto, tendo em vista possíveis erros humanos ou técnicos, a editora não pode garantir a exatidão e integridade absoluta das informações fornecidas e não se responsabiliza por possíveis erros associados ao uso do livro.

ISBN 978-0321146533 Inglês.

ISBN 978-5-496-02570-6

Prefácio

Limpe o código que funciona(código limpo que funciona), nesta frase curta, mas vigorosa, cunhada por Ron Jeffries, é o ponto principal do Desenvolvimento Orientado a Testes (TDD). Um código limpo que funciona é uma meta pela qual vale a pena lutar porque

Esta é uma forma previsível de desenvolver programas. Você sabe quando o trabalho pode ser considerado concluído e não se preocupa com uma longa série de erros;

Dá a você a chance de aprender as lições que o código ensina. Se você usar a primeira ideia que lhe vier à mente, não terá a chance de implementar a segunda ideia melhor;

Melhora a vida dos usuários de seus programas;

Permite que seus colegas contem com você e você conte com eles;

É mais agradável escrever um código como este.

Mas como você consegue um código limpo que funciona? Muitas forças nos impedem de obter um código limpo e às vezes nem conseguimos obter um código que simplesmente funcione. Para nos livrarmos de muitos problemas, desenvolveremos o código com base em testes automatizados. Esse estilo de programação é chamado de desenvolvimento orientado a testes. De acordo com esta técnica

O novo código é escrito somente depois que o teste automatizado é escrito e falha;

Qualquer duplicação é eliminada.

Dois regras simples, não é? No entanto, eles geram um comportamento individual e de grupo complexo com muitas implicações técnicas:

Durante o processo de design, constantemente executamos o código e temos uma ideia de seu trabalho, o que ajuda a tomar as decisões certas;

Nós mesmos escrevemos testes, porque não podemos esperar que outra pessoa faça testes para nós;

Nosso ambiente de desenvolvimento deve responder rapidamente a pequenas modificações de código;

O design do programa deve ser baseado no uso de muitos componentes independentes e fracamente acoplados para facilitar o teste do código.

As duas regras TDD mencionadas ditam a ordem das etapas de programação.

1. Vermelho - escreva um pequeno teste que não funciona e pode nem mesmo compilar.

2. Verde - faça o teste rodar o mais rápido possível, sem pensar no design correto e código limpo. Escreva código suficiente para fazer o teste funcionar.

3. Refatoração - elimine qualquer duplicação do código escrito.

Vermelho - verde - refatoração é o mantra do TDD.

Se assumirmos que este estilo de programação é possível, podemos supor que, graças ao seu uso, o código conterá significativamente menos defeitos, além disso, o objetivo do trabalho será claro para todos os que dele participam. Nesse caso, desenvolver apenas o código necessário para passar nos testes também tem implicações sociais:

Com uma densidade de defeitos suficientemente baixa, a equipe de Garantia de Qualidade (QA) será capaz de passar da resposta aos erros para evitá-los;

Ao reduzir o número de surpresas desagradáveis, os gerentes de projeto serão capazes de estimar com mais precisão os custos de mão de obra e envolver os clientes no processo de desenvolvimento;

Se os tópicos das discussões técnicas forem claramente definidos, os programadores podem interagir uns com os outros regularmente, em vez de uma vez por dia ou uma vez por semana;

Mais uma vez, com uma densidade de defeitos suficientemente baixa, poderemos ter um produto de trabalho integrado todos os dias com novas funcionalidades adicionadas, para que possamos entrar em um tipo de relacionamento comercial completamente novo com nossos clientes.

Então a ideia é simples, mas qual é o nosso interesse? Por que um programador deve assumir a responsabilidade extra de escrever testes automatizados? Por que um programador daria pequenos passos à frente quando seu cérebro é capaz de pensar em uma estrutura de design muito mais complexa? Bravura.

Bravura

TDD é uma forma de gerenciar o medo no processo de programação. Não me refiro ao medo de cair da cadeira ou de um chefe. Refiro-me ao medo de um problema "tão difícil que ainda não tenho ideia de como resolvê-lo". Dor é quando a natureza nos diz: "Pare!", E o medo é quando a natureza nos diz: "Cuidado!" Ser cauteloso não é uma coisa ruim, mas além de ser benéfico, o medo tem alguns efeitos negativos sobre nós:

O medo nos força a pensar com antecedência e cuidadosamente no que esta ou aquela ação pode levar;

O medo faz com que nos comuniquemos menos;

O medo nos deixa intimidados com as análises de nosso trabalho;

O medo nos torna irritáveis.

Nada disso é útil para o processo de programação, especialmente se você estiver trabalhando em um problema complexo. Então, nos deparamos com a questão de como sair de uma situação difícil e

Não tente prever o futuro, mas comece imediatamente o estudo prático do problema;

Não isolando do resto do mundo, mas aumentando o nível de comunicação;

Não evite respostas, mas, ao contrário, estabeleça um feedback confiável e, com sua ajuda, monitore cuidadosamente os resultados de suas ações;

(você tem que lidar com o aborrecimento sozinho).

Compare a programação com o levantamento de um balde de um poço. O balde está cheio de água, você gira a alavanca, enrolando a corrente ao redor do portão e levantando o balde. Se o balde for pequeno, um colar regular de rotação livre é suficiente. Mas se o balde for grande e pesado, você se cansará antes de pegá-lo. Para poder descansar entre as voltas da alavanca, uma catraca é necessária para manter a alavanca no lugar. Quanto mais pesada a caçamba, mais freqüentemente os dentes da engrenagem da catraca devem seguir.

Os testes em TDD são os dentes da engrenagem da catraca. Ao fazer o teste funcionar, sabemos que o teste agora funciona, agora e para sempre. Estamos um passo mais perto de concluir o trabalho do que estávamos antes de o teste começar a funcionar. Depois disso, forçamos o segundo teste a funcionar, depois o terceiro, o quarto e assim por diante.Quanto mais complexo for o problema que o programador enfrenta, menos funcionalidade cada teste deve cobrir.

Leitores de livros Extreme Programming Explaine deve ter notado a diferença de tom entre Extreme Programming (XP) e Test-Driven Development (TDD). Ao contrário do XP, o TDD não é absoluto. O XP diz "você tem que dominar isso e aquilo para seguir em frente." TDD é uma técnica menos específica. O TDD assume que existe um intervalo entre a tomada de decisão e os resultados e oferece ferramentas para controlar a duração desse intervalo. “E se, por uma semana, eu projetar um algoritmo no papel e, em seguida, escrever o código usando uma abordagem de teste inicial? Será compatível com TDD? " Claro que vai ser. Você conhece a duração do intervalo entre a tomada de decisão e a avaliação dos resultados e controla conscientemente esse intervalo.

A maioria das pessoas que dominam o TDD afirmam que sua prática de programação mudou para melhor. Infectado por testes(teste infectado) é a definição que Erich Gamma cunhou para descrever essa mudança. Depois de dominar o TDD, você se pega escrevendo muito mais testes do que costumava fazer e avançando em pequenos passos que antes pareciam inúteis. Por outro lado, alguns programadores, tendo se familiarizado com o TDD, decidem voltar às práticas antigas, reservando o TDD para casos especiais em que a programação convencional não leva ao progresso desejado.

Certamente, existem problemas que não podem (pelo menos por enquanto) ser resolvidos apenas com testes. Em particular, o TDD não permite demonstrar mecanicamente a adequação do código desenvolvido em termos de segurança de dados e confiabilidade de operações paralelas. Claro, a segurança é baseada em um código que deve estar livre de defeitos, mas também se baseia na participação humana nos procedimentos de proteção de dados. Os problemas sutis de simultaneidade não podem ser reproduzidos com certeza simplesmente executando algum código.