BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

O Programador Artista

por Saulo Arruda em  18 Jun, 2010 1

Muito têm se falado sobre a atividade de software se tratada como Artesanato, ao contrário uma tendência de Manufatura prometida pelas famosas "Fábricas de Software". Desta tendência surgiram livros como Software Craftsmanship, de Pete McBreen, Clean Code, de Robert Martin (Uncle Bob) e também um Manifesto do Artesão de Software.

Qual a cor é o seu Backlog?

por Shane Hastie , traduzido por Andrew Kurauchi   em  04 Mai, 2010

Na recente SDC conference em Sydney e Wellington, Philippe Kruchten realizou uma palestra entitulada "Que cor é o seu Backlog". Em sua palestra ele fala sobre colocar em foco aspectos arquiteturalmente significativos do software em projetos ágeis, juntamente com a entrega dos componentes funcionais do sistema.

Código Temporário, Código Sustentável e tudo entre eles

por Vikas Hazrati , traduzido por José Donizetti   em  26 Mar, 2010

Existe código que é bem testado, bem refatorado e escrito por último. Também existe código que é planejado para ser jogado fora em poucos dias. Entre esses dois extremos, existe um grande meio termo. O código na área intermediária é escrito com o objetivo de ser melhorado depois, o que nunca acontece.

CINTEQ - International Conference on Software Testing and Quality

por Gisela Nogueira em  10 Mar, 2010

Na última semana desse mês vai ocorrer um grande evento na área de qualidade de software em São Paulo, o CINTEQ - International Conference on Software Testing and Quality organizado pelo ISQTB. Saiba as principais palestras e o que você pode esperar desse evento.

Comentar ou não comentar?

por Abel Avram , traduzido por Pedro Mariano   em  05 Mar, 2010 3

A maioria dos desenvolvedores já escreveu pelo menos uma linha de comentário em seu código. Alguns chegam até a escrever várias linhas de comentário com o intuito de tornar o explicar melhor o que tal implementação faz. Esse artigo reúne algumas práticas usadas na hora de escrever comentários, além de opiniões internacionais e nacionais sobre comentar o seu código.

Sprints de Estabilização, um Mal Necessário ou um Puro Desperdício?

por Mark Levison , traduzido por Marcelo Andrade   em  23 Dez, 2009 1

Dushy tem ouvido falar sobre Sprints de Estabilização e ficou pensando se elas eram a norma no mundo ágil. Sprints de Estabilização são uma porção de sprints adicionais ao final do ciclo normal de desenvolvimento e antes da entrega do produto. Como o nome sugere, elas costumam ser incluídas como uma última oportunidade de explorar o produto numa última busca por bugs.

Analisando a Dívida Técnica

por Vikas Hazrati , traduzido por Rodrigo Branas   em  26 Out, 2009 2

O termo "dívida técnica" foi definido por Ward Cunningham e descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de implementar no curto prazo mas com grande impacto negativo no longo prazo. Alguns agilistas opinaram sobre o que deve ser considerado dívida técnica e como poderia ser classificada.

EU Software Liability lawsuit: a metade diz que teste unitário é a resposta

por Mike Bria , traduzido por Gisela Nogueira   em  26 Ago, 2009

52% dos desenvolvedorres de .NET, questionados pela Typemock, pensam que teste unitário pode ajudar empresas a evitar processos relacionados à proposta do projeto de lei de responsabilidade do software na EU (União Européia). O que eles dizem?

Deficiências de software Crescem em Custos Substantivos

por Shane Hastie , traduzido por Rafael Riberto   em  17 Ago, 2009

No recente artigo entitulado "Entrega Continua de Ganhos na Evolução do Sistema", Chris Sterlin discute o conceito de Deficiências de Software – "A deficiência do software se acumula quando o foco permanece na finalização imediata, enquanto flexibilidade de mudanças do sistema é negligenciada no decorrer do tempo".

Lidar com Bugs em um Projeto Ágil/Scrum

por Mark Levison , traduzido por Fernanda Stringassi de Oliveira   em  22 Jul, 2009 1

Uma pergunta freqüentemente questionada é como Scrum recomenda que a equipe trate os bugs? Eles devem ser colocados no product backlog? Ou em uma lista de bugs separada? Se eles estão no backlog, o Product Owner deve definir as prioridades ou eles são automaticamente os itens mais importantes? Deve existir um sprint em separado para a correção de bugs?

Resgatando seu Projeto Ruby on Rails

por Robert Bazinet , traduzido por Alberto Souza   em  07 Jul, 2009

Ruby on Rails já está aí há cerca de 5 anos, e durante todos esses anos diversas aplicações foram desenvolvidas. Várias dessas aplicações foram criadas enquanto os desenvolvedores estavam aprendendo Ruby e Ruby on Rails, e por consequência, não utilizaram as melhores práticas de desenvolvimento. Apesar disso, as aplicações continuam online.

Código de Qualidade nas Equipes

por Niclas Nilsson , traduzido por Samuel Carrijo   em  03 Jul, 2009

Malik Jaibeer postou uma introdução de como endereçar e introduzir código de qualidade dentro de uma equipe. Sua série de posts podem ser úteis pra quem estiver em uma situação na qual se queira aprender mais para si mesmo ou apresentar essas idéias para outros. A série oferece uma visão geral breve do tema e aponta várias direções para se estudar mais.

Economizando com Programação em Par

por Mike Bria , traduzido por Hildebrando Furlan Neto   em  02 Jul, 2009

Porque alguém utilizaria duas pessoas para fazer o trabalho de uma? Esta é uma reação comum quando as pessoas são apresentadas a ideia da programação em par. Eles concluem programação em par como duplicar o custo de escrever um segmento de código. Dave Nicollete demonstra algumas ideias quantitativas para ajudar a mostrar como a programação em par pode salvar dinheiro, ao invés de desperdiça-lo.

Kent Beck Sugere Pular os Testes em Projetos de Curto Prazo

por Mark Levison , traduzido por Wagner R. Santos   em  02 Jul, 2009

Kent Beck, autor de “Extreme Programming Explained” e “Test Driven Development: By Example” sugere que um projeto de software, assim como golf, pode ser um jogo longo ou curto. JUnit é um exemplo de projeto longo, muitos usuários, rentabilidade estável (a $0 é triste para qualquer envolvido), onde o objetivo principal é proporcionar funcionalidades além das necessidades dos usuários.

Top 10 Motivos para Amar Teste Ágil

por Mark Levison , traduzido por Gisela Nogueira   em  09 Jun, 2009

Quais são as dez razões para os testadores amarem testes Ágeis? Kay Johansen recentemente fez esta pergunta e obteve algumas respostas dos principais testadores.

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT