Quais são algumas das razões por que um único desenvolvedor deve usar TDD? [fechadas]

StackOverflow https://stackoverflow.com/questions/157717

  •  03-07-2019
  •  | 
  •  

Pergunta

Eu sou um programador do contrato com muita experiência. Estou acostumado a ser contratado por um cliente para entrar e fazer um projeto de software de uma forma ou outra em meu próprio, geralmente a partir do nada. Isso significa uma ardósia limpa, quase todas as vezes. I pode trazer em bibliotecas que eu desenvolvi para obter um início rápido, mas eles são sempre opcional. (E dependem recebendo as cláusulas IP corretas no contrato) Muitas vezes posso especificar ou até mesmo projetar o hardware plataforma ... então estamos falando sério liberdade aqui.

Eu posso ver usos para a construção de testes automatizados para determinado código: Bibliotecas com mais de funcionalidade trivial, funcionalidade central com um elevado número de referências, etc. Basicamente, como o valor de um pedaço de código sobe através do uso pesado, eu pode ver que seria mais e mais valioso para automaticamente testar esse código para que eu sei que eu não quebrá-lo.

No entanto, na minha situação , acho que é difícil para racionalizar nada mais do que isso. Eu vou adotar as coisas como elas revelar-se útil, mas eu não estou prestes a seguir cegamente qualquer coisa.

I encontrar muitas das coisas que eu faço em 'manutenção' são realmente pequenas alterações de design. Neste caso, os testes não teria me salvou nada e agora eles teriam que mudar também. A abordagem de design altamente iterativa, topo-primeiro funciona muito bem para mim. Eu não posso ver realmente salvar a mim mesmo que muito tempo com testes mais extensos.

projetos de hobby são ainda mais difíceis de justificar ... eles são geralmente nada de weekenders até um mês digamos longa. erros Edge-de casos raramente importa, é tudo sobre o jogo com alguma coisa.

Leitura perguntas como esta , o mais votado na resposta parece dizer que no que é cartaz experiência / opinião TDD realmente desperdiça tempo, se você tem menos de 5 pessoas (mesmo assumindo um certo nível de competência / experiência com TDD). No entanto, isso parece estar cobrindo o tempo de desenvolvimento inicial, não manutenção. Não está claro como TDD pilhas ao longo de todo o ciclo de vida de um projeto.

Eu acho que TDD pode ser um bom passo no objetivo de valor de melhorar a qualidade dos produtos da nossa indústria como um todo. Idealismo, por si própria não tudo é que eficaz em me motivar, no entanto.

I do acho TDD seria uma abordagem bem em equipes grandes ou equipes de qualquer tamanho contendo pelo menos um programador não confiável. Isso não é a minha pergunta.

Por que um único desenvolvedor com um registro bom caminho adotar TDD?

Eu adoraria ouvir de qualquer tipo de métricas feito (formalmente ou não) no TDD ... com foco em desenvolvedores individuais ou pequenas equipes.

Na falta deste, anedotas de suas experiências pessoais seria bom também. :)

Por favor, evite afirmando opinião sem experiência para apoiá-la. Não vamos fazer isso uma guerra ideologia. Também a pular argumento maiores opções de emprego. Isto é simplesmente uma questão de eficiência.

Foi útil?

Solução

Eu não estou prestes a seguir cegamente qualquer coisa.

Essa é a atitude certa. Eu uso TDD o tempo todo, mas eu não aderir a ela como estritamente como alguns.

O melhor argumento (em minha mente) em favor do TDD é que você recebe um conjunto de testes que você pode executar quando você finalmente chegar a refatoração e manutenção fases de seu projeto. Se esta é sua única razão para usar TDD, então você pode escrever os testes qualquer hora que quiser, em vez de seguir cegamente a metodologia.

A outra razão que eu uso TDD é que escrever testes me deixa pensando na minha API na frente. Eu sou forçado a pensar em como eu vou usar uma classe antes de escrevê-lo. Recebendo minha cabeça no projeto neste alto nível funciona para mim. Há outras maneiras de fazer isso, e se você encontrou outros métodos (há uma abundância) para fazer a mesma coisa, então eu diria que continuar fazendo o que funciona para você.

Outras dicas

Eu encontrá-lo ainda mais útil quando voando solo. Sem ninguém por perto para trocar idéias de e ninguém por perto para realizar análises pelos pares, você vai precisar de alguma garantia de que você está código é sólida. TDD / BDD irá fornecer essa garantia para você. TDD é um pouco contraversial, no entanto. Outros podem discordar completamente com o que estou dizendo.

EDIT: devo acrescentar que, se feito corretamente, você pode realmente gerar especificações para o seu software, ao mesmo tempo que você escrever testes. Este é um grande efeito colateral de BDD. Você pode fazer você olhar como desenvolvedor de super se você está produzindo o código sólida, juntamente com especificações, tudo por conta própria.

Ok minha vez ... eu faria TDD mesmo em meu próprio (para não-pico / experimental / código de protótipo) porque

  • Pense antes de saltar : forças-me a pensar o que eu quero para ficar pronto antes de eu começar a pôr em marcha código. O que estou tentando fazer aqui .. "Se eu supor que eu já tinha esta peça .. como eu ia esperar que ele funcione? Incentiva interface em design de objetos.
  • mais fácil mudar : Eu posso fazer modificações com confiança .. 'Eu não quebrei nada em step1-10 quando eu mudei step5' testes de regressão é instantânea
  • melhores desenhos surgem : Eu encontrei melhor projeta emergente sem me investir esforço em uma atividade de design. teste-primeiro + Refatorando chumbo para baixo acoplamento, classes mínimas com métodos mínimas .. não overengineering .. nenhum código YAGNI. As aulas têm interfaces melhor públicas, métodos pequenos e são mais legíveis. Este é um tipo de coisa zen .. você só percebe que você tem quando você 'entrar'.
  • O depurador não é a minha muleta mais : Eu sei que o meu programa faz .. sem ter que gastar horas pisar através do meu próprio código. Hoje em dia Se eu gastar mais do que 10 minutos com o depurador .. alarmes mentais começar a tocar.
  • Ajuda-me ir para casa no horário Tenho notado uma diminuição acentuada no número de bugs no meu código desde TDD .. mesmo que o assert é como um traço Console e não um tipo xUnit AT.
  • Produtividade / Fluxo : isso me ajuda a identificar o próximo baby-passo discreto que vai me levar para a feito ... mantém o rolamento de bola de neve. TDD me ajuda a entrar em um ritmo (ou o que XPers chamar fluxo) mais rápido. Eu recebo uma fatia maior de um trabalho de qualidade feito por unidade de tempo do que antes. As voltas-refactor vermelho-verde de ciclo em ... uma espécie de máquina de movimento perpétuo.
  • eu posso provar que meu código funciona com o toque de um botão
  • A prática faz perfeito eu encontro-me aprender e manchar dragões mais rápido .. com mais tempo TDD sob a minha cintura. Talvez dissonância .. mas eu sinto que TDD me fez um programador melhor, mesmo quando eu não for primeiro teste. Spotting oportunidades de refatoração se tornou uma segunda natureza ...

Vou atualizar se eu pensar em mais nada .. é isso que eu vim com nos últimos 2 minutos de reflexão.

Eu também sou um programador do contrato. Aqui estão minha 12 razões pelas quais eu amo testes de unidade .

Meu melhor experiência com TDD é centrado em torno da href="http://code.google.com/p/pyftpdlib/" rel="nofollow noreferrer"> projeto . A maior parte do desenvolvimento é feito pelo autor original, e eu fiz algumas pequenas contribuições, mas é essencialmente um projeto solo. O conjunto de testes para o projeto é muito completo, e testa todos os principais recursos da biblioteca FTPd. Antes de verificar em mudanças ou liberar uma versão, todos os testes são verificados, e quando um novo recurso é adicionado, o conjunto de testes é sempre atualizado também.

Como resultado desta abordagem, este é o único projeto que eu já trabalhei em que não têm bugs showstopper aparecer após uma nova versão, tem mudanças verificadas no que quebrou uma das principais características, etc. O código é muito sólida e eu tenho sido constantemente impressionado com a forma como alguns relatórios de bugs foram abertos durante a vida do projeto. I (e o autor original) atributo muito deste sucesso para o conjunto de testes abrangente e a capacidade de testar todas as grandes caminho de código à vontade.

Do ponto de vista lógico, qualquer código que você escreve tem que ser testado, e sem TDD, então você vai estar testando-lo sozinho manualmente. Por outro lado a pyftpdlib, o pior código, número de erros e frequência das grandes questões, é o código que é / foi apenas sendo testada pelos desenvolvedores e QA experimentar novos recursos manualmente. As coisas não são testados por causa da falta de tempo ou cair através das rachaduras. caminhos de código velhos são esquecidos e até mesmo os recursos mais antigos estáveis ??acabar quebrando, grandes lançamentos acabar com características importantes não-funcional. etc. teste manual é criticamente importante para a verificação e alguns randomização de testes, mas com base na minha experiência eu diria que é essencial ter tanto o teste manual e uma estrutura de teste de unidade cuidadosamente construída. Entre as duas abordagens as lacunas na cobertura são menores, e sua probabilidade de problemas só pode ser reduzida.

Não importa se você é o único desenvolvedor ou não. Você tem que pensar nisso a partir do ponto de vista da aplicação. Todas as aplicações necessidades para funcionar corretamente, todos os aplicativos precisam ser mantidas, todas as necessidades de aplicações a ser menos buggy. Há, naturalmente, determinados cenários onde uma abordagem TDD pode não atender você. Isto é, quando o prazo está se aproximando muito rápido e não há tempo para executar testes de unidade.

De qualquer forma, TDD não depende de um solo ou um ambiente de equipe. Depende da aplicação como um todo.

Eu não tenho uma enorme quantidade de experiência, mas eu tive a experiência de ver abordagens fortemente contrastadas do teste.

Em um trabalho, não havia testes automatizados. "Testing" consistia em picar ao redor na aplicação, tentando tudo o que estalou em sua cabeça, para ver se ele quebrou. Escusado será dizer que foi fácil para código de flat-out quebrado para chegar ao nosso servidor de produção.

No meu trabalho atual, há muita testes automatizados, e um sistema de CI completa. Agora quando o código é quebrado, é imediatamente óbvio. Não só isso, mas como eu trabalho, os testes realmente documentar o que recursos estão trabalhando no meu código, e que ainda não têm. Isso me dá grande confiança para ser capaz de adicionar novos recursos, sabendo que se eu quebrar os já existentes, não vai passar despercebida.

Assim, para mim, não depende tanto do tamanho da equipe, mas o tamanho do aplicativo. você pode manter o controle de todas as partes do aplicativo? Cada requisito? Cada teste que você precisa executar para garantir que o aplicativo está funcionando? O que ele mesmo quer dizer que a aplicação está "trabalhando", se você não tem provas para provar isso?

Apenas meus $ 0,02.

testes permitem que você refatorar com confiança que você não está quebrando o sistema. Escrever os testes primeiro permite que os testes para definir o que é comportamento trabalhando para o sistema. Qualquer um comportamento que não é definida por meio do teste é, por definição, um sub-produto e deixou-se a mudança quando refatorando. escrever testes primeiro também dirigir o projeto em boas indicações. Para testability apoio que você achar que você precisa para aulas de dissociar, interfaces de uso, e siga bom padrão (inversão de controle, por exemplo) para tornar seu código facilmente testáveis. Se você escrever testes mais tarde, você não pode ter certeza que você cobriu todo o comportamento esperado de seu sistema nos testes. Você também descobrir que algumas coisas são difíceis de teste por causa do projeto - desde que foi provavelmente desenvolvido sem testar em mente -. E somos tentados a poupam em ou testes omitir

Eu geralmente trabalho a solo e na maior parte do TDD - os casos em que não são simplesmente onde eu deixar de viver de acordo com minhas práticas ou ainda não encontraram uma boa maneira que funciona para mim fazer TDD, por exemplo com interfaces web.

TDD não é sobre o teste é sobre a escrita de código. Como tal, ela fornece uma série de benefícios até mesmo para um único desenvolvedor. Para muitos desenvolvedores é uma mudança de mentalidade para escrever código mais robusto. Por exemplo, quantas vezes você pensa "Agora como pode este código falhar?" depois de escrever código sem TDD? Para muitos desenvolvedores, a resposta a essa questão é ninguém. Para praticantes de TDD ele muda a mentalidade para a fazer as coisas como verificar se os objetos ou cordas são nulos antes de fazer algo com eles, porque você está escrevendo testes para especificamente fazer isso (quebrar o código).

Outra razão importante é a mudança. Sempre que você lidar com um cliente, eles nunca consigo fazer as suas mentes. A única constante é a mudança. TDD ajuda como uma "rede de segurança" para encontrar todas as outras áreas que poderiam break.Even em pequenos projectos isso pode mantê-lo a partir da queima-se um tempo precioso no depurador.

Eu poderia ir e sobre, mas acho que dizer que TDD é mais sobre como escrever código que tudo deve ser suficiente para justificar a sua utilização como um único desenvolvedor.

Eu tendo a concordar com a validade do seu ponto sobre a sobrecarga de TDD para 'um desenvolvedor' ou projectos 'hobby' não justificando as despesas.

Você tem que considerar, porém, que a maioria das melhores práticas são relevantes e úteis se forem aplicadas de forma consistente por um longo período de tempo.

Por exemplo TDD está poupando-lhe testar / correções de código tempo em um longo prazo, e não dentro de 5 minutos depois de ter criado o primeiro teste de unidade.

Você é um programador do contrato que significa que você vai deixar seu projeto atual quando ele será concluído e vai mudar para outra coisa, provavelmente em outra empresa. Seu cliente atual terá de manter e apoiar o seu pedido. Se você não deixar a equipe de suporte uma boa estrutura para trabalhar com eles vai ser preso. TDD vai ajudar o projeto seja sustentável. Ela vai aumentar a estabilidade da base de código para que outras pessoas com menos experiência não vai ser capaz de não fazer muito dano tentar mudá-lo.

O mesmo se aplica para os projetos de hobby. Você pode estar cansado disso e vai querer passá-lo para alguém. Você pode se tornar bem sucedido comercialmente (pense Craiglist) e terá mais 5 pessoas a trabalhar além de você.

O investimento em processo adequado sempre paga-off, mesmo que seja apenas ganhou experiência. Mas a maior parte do tempo você vai ser grato que quando você iniciou um novo projeto que você decidiu fazê-lo corretamente

Você tem que considerar outros as pessoas ao fazer alguma coisa. Você tem que pensar no futuro, o plano para crescimento , o plano para sustentabilidade .

Se você não quer fazer isso -. Vara para o cowboy codificação, é muito mais simples desta forma

P.S. A mesma coisa se aplica a outras práticas:

  • Se você não comentar o seu código e você tem memória ideal você vai ficar bem, mas alguém ler o seu código não vai.
  • Se você não documentar suas discussões com o alguém cliente pessoa não vai saber nada sobre uma decisão crucial que você fez

etc ad infinitum

Eu já não refatorar qualquer coisa sem um conjunto razoável de testes de unidade.

Eu não faço full-on TDD com testes de unidade primeiro e segundo código. Eu faço CALTAL - código um pouco, Teste A Little - desenvolvimento. Geralmente, o código vai em primeiro lugar, mas nem sempre.

Quando eu achar que eu tenho que refatorar, eu faço testes suficientes certeza que eu tenho e então eu cortar fora a estrutura com total confiança que eu não tenho que manter todo o old-arquitetura-becomes- plano de nova arquitetura na minha cabeça. Eu só tenho que começar os testes para passar novamente.

Eu refatorar os bits importantes. Obter o conjunto existente de testes para passar.

Então eu percebo que eu esqueci alguma coisa, e eu estou de volta para o desenvolvimento CALTAL sobre o novo material.

Então eu vejo coisas que eu esqueci de apagar - mas eles são realmente não utilizado em todos os lugares? Excluir 'em e ver o que falha no teste.

Ainda ontem - no meio de uma grande refatoração - eu percebi que eu ainda não tinha o design exato direita. Mas os testes ainda tinha que passar, então eu estava livre para refatorar meu refatoração antes de eu mesmo feito com o primeiro refatoração. (Ufa!) E tudo funcionou muito bem porque eu tinha um conjunto de testes para validar as alterações contra.

Para voar TDD de solo é o meu co-piloto.

TDD permite me definir mais claramente o problema na minha cabeça. Isso me ajuda a concentrar na implementação apenas a funcionalidade que é necessário, e nada mais. Ele também me ajuda a criar um melhor API, porque eu estou escrevendo um "cliente" antes de eu escrever o código em si. Eu também pode refatorar sem ter que se preocupar em quebrar nada.

Eu vou responder a essa pergunta muito rapidamente, e esperamos que você vai começar a ver algum do raciocínio, mesmo se você ainda discordar. :)

Se você é bastante afortunado ser em um projeto de longa duração, em seguida, haverá momentos em que você quer, por exemplo, escrever a sua camada de dados em primeiro lugar, então talvez a camada de negócios, antes de passar para cima da pilha. Se o seu cliente, em seguida, faz uma mudança requisito que exige re-trabalho em sua camada de dados, um conjunto de testes de unidade sobre a camada de dados irá garantir que seus métodos não falham de maneiras indesejáveis ??(supondo que você atualizar os testes para refletir as novas exigências ). No entanto, é provável que seja chamado o método de camada de dados da camada de negócios, bem como, e, possivelmente, em vários lugares.

Vamos supor que você tem 3 chamadas para um método na camada de negócios, mas você só modificar 2. No terceiro método, você ainda pode estar ficando para trás os dados de sua camada de dados que aparecem para ser válido, mas pode quebrar alguns dos os pressupostos você codificou meses antes. Os testes de unidade, a este nível (e acima) deveria ter sido projetado para detectar suposições quebrados, e em não devem destacar-lhe que há uma seção de código que precisa ser revisitado.

Eu estou esperando que este exemplo muito simplista será suficiente para você pensar sobre TDD um pouco mais, e que pode criar uma faísca que faz você pensar em usá-lo. Claro, se você ainda não vê o ponto, e você está confiante em suas próprias habilidades para manter o controle de muitos milhares de linhas de código, então eu não tenho lugar para dizer-lhe que você deve começar TDD.

O ponto de escrever os testes primeiro é que ele impõe os requisitos e decisões de design que você está fazendo. Quando eu mod o código, eu quero ter certeza de que ainda são impostas e é fácil o suficiente para alguma coisa "break" sem obter um compilador ou run-time error.

Eu tenho uma abordagem de teste-primeiro porque eu quero ter um alto grau de confiança em meu código. Concedido, os testes precisam ser bons testes ou não impor nada.

Eu tenho alguns grandes bases de código bonitas que eu trabalho em e há um monte de coisas não-trivial acontecendo. É fácil o suficiente para fazer as mudanças que ondulação e de repente X acontece quando X nunca deve acontecer. Meus testes me salvou em várias ocasiões de cometer um erro crítico (mas sutil) que pode ter passado despercebido pelos testadores humanos.

Quando os testes falham, eles são oportunidades para olhar para eles e o código de produção e certifique-se que ele está correto. Às vezes as mudanças de design e os testes terá de ser modificado. Às vezes eu vou escrever algo que passa 99 de 100 testes. Que um teste que não passou é como um colega de trabalho revendo meu código (em um sentido) para se certificar de que eu ainda estou construindo o que eu deveria estar edifício.

Eu sinto que como um desenvolvedor de solo em um projeto, especialmente um maior, você tende a se espalhar muito fina.
Você está no meio de um grande refactoring quando, de repente, um par de bugs críticos são detectados que por algum motivo não apareceu durante os testes de pré-lançamento. Neste caso, você tem que largar tudo e corrigi-los e depois de ter passado duas semanas arrancando os cabelos você pode finalmente voltar ao que estava fazendo antes.
Uma semana depois, um de seus maiores percebe clientes que absolutamente deve ter este fresco novo recurso brilhante ou de outra forma eles não vão colocar a ordem para as unidades 1M eles devem ter já ordenou um mês atrás.
Agora, três meses depois, você não se lembrar por que você começou a refatoração em primeiro lugar e muito menos o que o código que você está refatoração era suposto fazer. Graças a Deus que você fez um bom trabalho de escrever esses testes de unidade, porque pelo menos eles dizer-lhe que o seu código refatorado ainda está fazendo o que deveria fazer.
Ensaboe, enxague, repita.

.. história da minha vida nos últimos 6 meses. : - /

desenvolvedor Sole deve usar TDD em seu projeto (track record não importa), uma vez que, eventualmente, este projecto poderia ser passado para algum outro desenvolvedor. Ou mais desenvolvedores poderiam ser trazidos.

Novas pessoas terão extremamente tem trabalho momento difícil com o código sem os testes. Eles vão quebrar as coisas.

O seu cliente possuir o código fonte quando você entregar o produto? Se você pode convencê-los que entregar o produto com testes de unidade agrega valor, então você está up-vendendo seus serviços e entregar um produto melhor. Da perspectiva do cliente, a cobertura do teste não só garante a qualidade, permite futuros mantenedores de entender o código muito mais facilmente uma vez que os testes de isolar a funcionalidade da interface do usuário.

Eu acho que TDD como metodologia não é apenas sobre "fazer exames ao fazer alterações", portanto, não depende em equipa, nem do tamanho do projeto. Trata-se de anotar as expectativas de um sobre o que um pice de código / uma aplicação faz antes de um começa a realmente pensar sobre como o comportamento observado é implementado. O foco principal do TDD não é só ter teste no local para o código escrito, mas escrever menos código, porque você acabou de fazer o que fazem o verde de teste (e refatorar mais tarde).

Se você é como eu e encontrá-lo muito difícil pensar sobre o que uma parte / todo o aplicativo faz sem pensar sobre como implementá-lo, eu acho que é bom para escrever o seu teste após o seu código e permitindo, assim, o código " conduzir" os testes.

Se a sua pergunta não é tanto sobre o teste-primeiro (TDD) ou teste depois de (boa codificação?) Eu penso que o teste deve ser uma prática padrão para qualquer desenvolvedor, o tempo sozinho ou em uma grande equipe, que cria o código que estadias na produção superiores a três meses. Na minha experiencia que é o período de tempo após o qual mesmo o autor original tem que pensar muito sobre o que esses vinte linhas de código complexo, super-otimizado, mas pouco documentada realmente código de fazer. Se você tem testes (que cobrem todos os caminhos throughth o código), há menos de pensar - e menos errar sobre, mesmo anos mais tarde ...

Aqui estão alguns memes e minhas respostas:

"TDD me fez pensar em como ele seria um fracasso, o que me um programador melhor feito"

Dada a experiência suficiente, sendo higly preocupado com modos de falha deve, naturalmente, tornar-se parte de seu processo de qualquer maneira.

"Os aplicativos precisam funcionar corretamente"

Isso pressupõe que você é capaz de testar absolutamente tudo. Você não vai ser melhor a cobrir todos os testes possíveis corretamente do que você estava em escrever o código funcional corretamente em primeiro lugar. "Os aplicativos precisam trabalho melhor " é um argumento muito melhor. Eu concordo com isso, mas é idealista e não o suficiente bastante tangível para motivar tanto quanto eu gostaria que fosse. Métricas / anedotas seria ótimo aqui.

"Trabalhou ótimo para o meu "

Eu disse no valor de serra pergunta que, nestes casos, mas obrigado pela anedota.

"Pense na próxima desenvolvedor"

Este é provavelmente um dos melhores argumentos para mim. No entanto, é bastante provável que a próxima desenvolvedor não iria praticar TDD, quer, e, portanto, seria um desperdício ou possivelmente até mesmo um fardo nesse caso. Back-door evangelismo é o que equivale a lá. Tenho certeza um desenvolvedor TDD realmente appeciate-lo, no entanto.

Quanto é que você vai apreciar projetos feitos em obsoleto must-fazer metodologias quando você herda um? RUP, qualquer um? Pense o que significa TDD a próxima desenvolvedor se TDD não é tão grande como todo mundo pensa que é.

"A refatoração é muito mais fácil"

A refatoração é uma habilidade como qualquer outro, e desenvolvimento iterativo certamente exige essa habilidade. I tendem a jogar fora uma quantidade considerável de código se eu acho que o novo design vai economizar tempo, a longo prazo, e parece que não haveria um sem-número de testes jogados fora também. Que é mais eficiente? Eu não sei.

...

Eu provavelmente recomendar algum nível de TDD para alguém novo ... mas eu ainda estou tendo problemas com os benefícios para qualquer um que tem sido em torno do bloco algumas vezes já. Eu provavelmente irá começar a adicionar testes automatizados para bibliotecas. É possível que depois de fazer isso, eu vou ver mais valor em fazê-lo em geral.

auto-interesse motivado.

No meu caso, único desenvolvedor traduz em pequeno empresário. Eu escrevi uma quantidade razoável de código da biblioteca de (aparentemente) facilitar a minha vida. Muitas dessas rotinas e classes não são ciência do foguete, para que eu possa ter certeza de que eles funcionem corretamente (pelo menos na maioria dos casos), revendo o código, alguns alguns testes local e depuração para os métodos para se certificar de que eles se comportam da forma Eu acho que eles fazem. força bruta, se você quiser. A vida é boa.

Com o tempo, esta biblioteca cresce e se acostuma em mais projetos para clientes diferentes. Teste fica mais demorado. Especialmente casos onde estou (espero) corrigir bugs e (ainda mais espero) não quebrar alguma coisa. E isso não é apenas para bugs no meu código. Eu tenho que ter cuidado adicionando funcionalidade (clientes continuam a pedir mais "coisas") ou certificando-se de código ainda funciona quando se mudou para uma nova versão do meu compilador (Delphi!), Código de terceiros, o ambiente de tempo de execução ou sistema operacional.

Levado ao extremo, eu poderia gastar mais tempo analisando código antigo do que trabalhar em novo (leia-faturáveis) projetos. Pense nisso como o ângulo de repouso de software (o quão alto você pode empilhar software não foi testado antes de cair sobre:)

.

Técnicas como TDD me dá métodos e classes que são mais cuidadosamente concebido, mais exaustivamente testado (antes que o cliente recebe-los) e precisam de menos manutenção daqui para frente.

Em última análise, isso se traduz em menos tempo fazendo manutenção e mais tempo para passar a fazer coisas que são mais rentáveis, mais interessante (quase nada) e mais importante (como família).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top