Início Qualidade no InfoQ Brasil
Notícias
Feed RSS-
Qual é a nomenclatura ideal para os nosso métodos?
Recentemente Anderson Fraga, no fórum Tectura, iniciou uma discussão onde ele faz um questionamento familiar para muitos desenvolvedores, ele comparou a declaração de métodos e classes do projeto Restfulie e viu que no projeto foi usado nomes curtos e expressivos. Mas qual o impacto disso? Qual é a nomenclatura ideal para os nossos métodos?
-
Big Ball of Mud, ainda é o projeto de software dos mais populares
Big Ball of Mud, é um código bagunçado que é mal estruturado, desleixado e muitas vezes amarrado com fita adesiva. Com o passar dos anos tentamos introduzir vários guidelines tais como SOLID, GRASP e KISS, alta coesão e baixo acoplamento. Entretanto, a situação parece continuar e ainda vemos que a "Grande Bola de Lama" parece ser o jeito mais popular de fazer o design de um software.
-
Rails 3 Lançado: Modularidade, Performance, Estabilidade e Simplicidade
Depois de ser comparado com Duke Nuke Forever devido a constante mudança da sua data do lançamento oficial o Rails 3 versão final foi lançado dia 23 desse mês (23/08/2010). Com diversas mudanças enumeradas e discutidas por toda a comunidade e com mais de 16000 contribuintes no total, o Rails provou que uma comunidade unida pode ser a chave para o sucesso.
-
W3C lança o Unicorn, uma ferramenta para a validação dos padrões Web
A W3C lançou o Unicorn, um ferramenta que visa ajudar as pessoas a melhorar a qualidade das suas páginas Web. O Unicorn combina quatro ferramentas populares, incluindo validação de HTML, validação de CSS, mobileOk checker, e validação de Feeds, em apenas uma interface. Isso significa que você pode verificar sua página Web visitando apenas uma url ao invés de quatro.
-
O Programador Artista
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?
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
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
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?
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?
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
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
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
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
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
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.