Desenvolvimento de Software com qualidade

(O Diabo mora nos detalhes — Provérbio Alemão)

Uma breve História

No final da década de 60, mais de 10 anos após o primeiro transistor de silício ser desenvolvido pela Bell Labs(EUA), o desenvolvimento de software começava a ocupar um importante papel no mundo da computação. A “Crise do software” termo mais comumente utilizado a partir da década de 70, remetia às dificuldades da criação de software em um cenário de exponencial crescimento da demanda por software, aumento da complexidade dos problemas a serem solucionados e a ausência de técnicas para auxiliar nesta tarefa.

Em 1968, em Gramisch(Alemanha), ocorreu a conferência que hoje muitos consideram como o nascimento da disciplina “Engenharia de Software”, a NATO Software Engineering Conference, com o objetivo de estabelecer técnicas e ferramentas, criando processos mais consistentes para o desenvolvimento de sistemas computacionais.

Após dois parágrafos sem nenhum valor técnico você(leitor) deve estar se perguntando: “motherfucker”, o que eu tenho a ver com uma conferência da época da criação do cobol ou com transistor de silício?

Os computadores necessitam dos transistor de silício até hoje, mas foi somente um citação para ilustrar o texto(não trataremos deste assunto), sobre a conferência que deu origem a Engenharia de software, se você já trabalha com desenvolvimento de software a algum tempo não ficará surpreso com a informação de que grande parte dos projetos nos dias de hoje ainda continuam com os mesmos problemas daquela época:

· Produtividade não acompanha a demanda

· Custos acima do previsto

· Facilidade de manutenção não é devidamente considerada na concepção do software

· Não atendimento dos requisitos funcionais

De certa forma podemos dizer que a “Crise do Software” ainda não foi mitigada.

Técnicas para um desenvolvimento de qualidade

De acordo com Robert C. Martin (Uncle Bob) e Micah Martins, no livro Princípios, Padrões e Práticas Ágeis em C#, são sinalizadores de que o software está em putrefação:

· Rigidez: Software difícil de alterar

· Fragilidade: Alteração em um lugar faz o software estragar em vários (Jogo de varetas)

· Imobilidade: Dificuldade em desacoplar partes do sistema uteis para outros sistemas

· Viscosidade: Alto custo para manter o padrão de desenvolvimento do software, esta característica atraí o desenvolvedor a fazer alterações “malfeitas”

· Complexidade desnecessária: Elementos inutilizados e feitos de forma a dispensar a “simplicidade”

· Repetição desnecessária: Não recorte e cole trechos de código(!)

· Opacidade: Dificuldade de leitura de um módulo

Se eu fosse dar um conselho, e somente um para desenvolvedores que estão começando sua carreira agora eu diria: Escreva seu código pensando no próximo desenvolvedor que irá fazer a manutenção nele.

Robert C. Martin (Uncle Bob), no livro Clean Code, demonstra através de experimentos práticos que passamos mais tempo lendo o código de uma determinada classe do que escrevendo nela, sendo assim a clareza do código é de suma importância, escreva o código com carinho pois o próximo programador a lê-lo agradecerá. O código limpo minimiza a probabilidade de “Esconder Bugs”, facilitando assim sua manutenção.

Princípios SOLID

Solid é a reunião de 5 padrões consolidados de POO, estes padrões foram descritos de forma conjunta por Robert C. Martin(Uncle Bob) em seu artigo “The Principles of OOD” (http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod). A reunião destes padrões é um forte indício de software de qualidade, flexível, extensível e desacoplado.

Single Responsibility Principle (Responsabilidade única)

Open Closed Principle (Aberto/Fechado)

Liskov Substitution Principle (Substituição de Liskov)

Interface Segregation Principle (Segregação de Interface)

Dependency Inversion Principle (Inversão de Dependência)

Princípio da responsabilidade única (SRP):

Uma classe deve ter apenas um motivo para mudar.

Princípio do aberto/Fechado (OCP)

As entidades de software devem ser abertas para ampliação, mas fechadas para modificação.

Princípio da Substituição de Liskov (LSP)

Os subtipos devem ser substituíveis pelos seus tipos de base.

Princípio da Segregação de Interface (ISP)

Crie interfaces refinadas e específicas do cliente.

Princípio da Inversão de Dependência (DIP)

As abstrações não devem depender dos detalhes, os detalhes devem depender das abstrações.

Conclusão

Nós programadores, somos células fundamentais no meio técnico científico Informacional (Milton Santos), que rege a vida contemporânea. Cada módulo, classe, método que escrevemos leva nossa marca individual. É nossa obrigação codificar com carinho, elegância e qualidade, preocupando-se com o próximo leitor de nosso código. A longevidade de nossos sistemas reflete nossa qualidade em quanto programadores, e se ao olhar nosso próprio código escrito a 6 meses ou 1 ano atrás a percepção for de “mediocridade”, é um sinal de que estamos no caminho certo.

Bibliografia

Clean Code — 2008, Robert C. Martin.

Princípios, Padrões e Práticas ágeis em C# — 2011, Robert C. Martin, Micah Martin.

The Principles of OOD, disponível em : http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Escrito por:

Carlos Yuri

Bacharel em Sistemas de Informação

Desenvolvedor na Rumo Soluções e profissional Certificado pela Microsoft

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade