O que é Code Smell?

Este post é um conjunto de trechos extraídos da Wikipedia.

Em programação, code smell é qualquer sintoma no código fonte que indica um problema mais profundo.

O problema sugerido por um code smell sempre ser descoberto quando o código está sujeito a um pequeno ciclo de feedback, onde é refatorado em etapas pequenas e controladas, e o design resultante é examinado para verificar se há mais code smells que indiquem a necessidade de mais refatoração.

Do ponto de vista de um programador encarregado de realizar a refatoração, code smells são heurísticas que indicam quando refatorar, e quais técnicas específicas de refatoração devem ser usadas.

Determinar o que é ou não um code smell é sempre um julgamento subjetivo, e sempre irá variar de acordo com a linguagem de programação, o desenvolvedor e a metodologia de desenvolvimento.

Existem ferramentas que detectam certos tipos de code smells, como:
Java: Checkstyle, PMD e FindBugs.
Dot Net: ReSharper.

Code smells comuns:

Código duplicado: código idêntico ou muito similar existe em mais de um local.
Método longo: um método, função ou procedure muito extenso.
Classe extensa: uma classe que acabou ficando muito extensa (God Object).
Feature envy (sem tradução): uma classe que utiliza em excesso métodos de outra classe.
Intimidade inapropriada: uma classe que possui dependência de detalhes de implementação de outra classe.
Legado recusado: uma classe que sobrepõe (override) o método da classe genérica de forma que o contrato da classe genérica não é cumprido pela classe derivada.
Classe preguiçosa: classe que faz muito pouco.
Complexidade artificial: uso forçado de design patterns extremamente complicados, onde um design simples seria suficiente.
Identificadores excessivamente longos: em particular, o uso de convenções de nomes para evitar ambigüidades, o que deveria estar implicito na arquitetura do software.

Princípios SOLID: O que são?

SOLID são cinco princípios básicos de programação e design orientados a objeto, introduzidos por Robert C. Martin no início dos anos 2000:

SRP: Single Responsibility Principle (Princípio da Responsabilidade Única). Noção de que um objeto deve possuir uma única responsabilidade.

OCP: Open/Closed Principle (Princípio Aberto / Fechado). Noção de que o software deve ser aberto para extensão, mas fechado para modificação.

LSP: Liskov Substitution Principle (Princípio da Substituição de Liskov). Noção de que objetos devem ser substituídos por instâncias de seus subtipos, sem afetar a correção do programa.

ISP: Interface Segregation Principle (Princípio de Segregação da Interface). Muitas interfaces específicas são melhores do que uma interface de uso geral.

DIP: Dependency Inversion Principle (Princípio de Inversão da Dependência). Noção de que se deve depender de interfaces abstratas e não de classes concretas, uma vez que implementações concretas são mais propensas a mudanças.

Princípios SOLID podem ser aplicados no desenvolvimento de software:

- A fim de remover Code Smells. Desta forma, o desenvolvedor refatora o código fonte do software até que esteja legível e extensível.
- Em conjunto com TDD (Test-Driven Development: desenvolvimento orientado a testes).
- É parte de uma estratégia global de programação ágil e adaptativa.
- Quando os princípios são aplicados em conjunto, aumentam bastante as chances de que o sistema criado seja simples de manter e estender.

Esta foi uma introdução a SOLID. Nos próximos posts farei uma explicação simples de cada um dos princípios aqui mencionados.

Scrum com Team Foundation Server 2010

Uma dica para os amantes do Scrum e do Dot Net é ler o slide abaixo, publicado por Aaron Bjork:

Scrum With Team Foundation Server 2010

View more presentations from Aaron Bjork.

As 10 melhores práticas para se construir software.

Estas são As 10 melhores práticas para se construir software, post escrito por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet:

1 - Desenvolva uma visão do produto.
2 - Trabalhe de modo iterativo e evolutivo.
3 - Envolva o cliente no processo.
4 - Gerencie requisitos.
5 - Acolha mudanças.
6 - Construa o design e a arquitetura incrementalmente.
7 - Diminua o tempo de feedback.
8 - Gerencie riscos.
9 - Aplique técnicas de engenharia.
10 - Confie na equipe.

Clique aqui e leia este e outros posts na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Como trabalham os desenvolvedores profissionais?

O post Como trabalham os desenvolvedores profissionais?, publicado por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet, lista as características inerentes aos bons desenvolvedores da seguinte forma:

Estudam muito, sempre;
Gostam de compartilhar conhecimento;
Escrevem seus próprios testes;
Escrevem código para pessoas e não para máquinas;
Refatoram de forma disciplinada e habitualmente;
Evoluem com o design tendo o business em mente.

Clique aqui e leia este post na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Verdades e Mitos sobre a Programação Orientada a Objetos

O post Verdades e Mitos sobre a Programação Orientada a Objetos, publicado por Vinicius Morgado, Professor do curso de Pós Graduação em Engenharia de Software do Instituto Infnet, divide idéias sobre a programação orientada a objetos em:

Verdades:
O Desenvolvimento OO é mais lento;
Programadores mais antigos têm dificuldades com OO;
A programação OO favorece a reutilização.

Mitos:
Objetos são "abstrações" do mundo real;
Programar em Java ou C# gera automaticamente software OO;
Para aprender OO é preciso antes aprender UML;

Para saber o porquê destas verdades e mitos, clique aqui e leia o post na íntegra no Blog do Professor Vinicius Morgado (http://viniciusmorgado.blogspot.com/).

Scrum e as práticas de engenharia de software

O Scrum é uma metodologia adaptativa e voltada à gestão. Deixa lacunas em termos de riscos e engenharia. Por isso, o Scrum, de acordo com o contexto de cada projeto, deve ser combinado com outras práticas como, por exemplo, a gerência de riscos do PMI e práticas de engenharia de software. Neste post cito 2 práticas de engenharia do XP (Extreme Programming):

- Refactoring (refatoração): muito importante para que o código tenha um design cada vez mais limpo, elegante e flexível. Como o Scrum é um processo ágil, ocorrem vezes em que, devido ao prazo de entrega do release ao final do Sprint, um determinado código é entregue sem estar de acordo com o ideal. Isto gera um débito técnico (tech debt). Ou seja, quem entregou o código mentaliza que assim que houver a possibilidade, este código será melhorado, se tornará mais semântico, que aquele dado método que está muito grande será quebrado em métodos menores etc. E implementa estas melhorias! Para o usuário do software, o refactoring não muda nada, já que as mesmas funcionalidades serão mantidas. Porém, para o Time que desenvolveu o software, é um grande ganho de qualidade e, também, de tempo quando for necessário atender a requisitos de evolução relativos à manutenção, adaptação ou adição de novas funcionalidades.

- Pair Programming (programação em pares): visa a propriedade coletiva do código. Tem como meta a melhoria contínua do código e a idéia de que, em casos onde haja alguma dificuldade de imaginar a implementação de alguma estória, 2 cabeças pensem melhor que uma. Devido à questão da propriedade coletiva do código, a sugestão é que não se utilizem sempre os mesmos pares. O piloto deve trocar com o co-piloto e, também, as pessoas devem formar pares diferentes. Ao mesmo tempo, ninguém é obrigado a trabalhar em par o dia inteiro. Pode, por exemplo, trabalhar em par na parte da manhã e individualmente na parte da tarde. Ou vice versa! Pode trabalhar individualmente e, quando sentir a necessidade, devido a algum bloqueio de inspiração, programar em par. A programação em pares não deve ser imposta, mas uma atitude de convencimento através da conversa e da pontuação de seus benefícios.

Muitas empresas ainda não entendem a utilidade da programação em pares, com a mentalidade “pago o salário individualmente, não em par”. E muitos desenvolvedores dizem que é uma prática “furada”, sem nunca tê-la experimentado. Não se pode dizer que algo é ruim sem antes experimentar.