Quais são os princípios de comunicação das práticas de engenharia de software?

A princ�pio sup�e-se que todos desejam construir o melhor software poss�vel escrevendo o melhor c�digo poss�vel. Mas desejar � uma coisa e por em pr�tica � outra.

Neste artigo eu apresento os 7 princ�pios b�sicos do desenvolvimento de software como descritos por David Hooker, a partir do qual realizei uma tradu��o livre, acrescentei alguns id�ias baseado-me em minha experi�ncia.

O objetivo � fornecer um  material de consulta e reflex�o sobre a arte de desenvolvimento de software, sim , arte, pois programar qualquer um programa mas desenvolver software de qualidade � para poucos.

N�o encare estes princ�pios como absolutos mas medite sobre cada um deles, examine-os, e retenha o que for proveitoso para voc�.

Primeiro Princ�pio - A raz�o pelo qual tudo existe

Problema : A tomada de decis�es durante o desenvolvimento de software � dif�cil.

Um sistema de software existe por uma raz�o: para fornecer valor aos seus usu�rios.

Todas as decis�es devem ser tomadas com isso em mente.

Antes de especificar um requisito do sistema, antes de implementar uma nova funcionalidade no sistema, antes de determinar a plataforma de hardware ou o processo de desenvolvimento a ser usado, fa�a para si mesmo  a seguinte pergunta:

"Ser� que isso acrescenta valor real ao sistema ? "

Se a resposta for "n�o", n�o fa�a.

Todos os outros princ�pios se ap�iam neste princ�pio.

Todas as decis�es devem ser 'decis�es corretas' , e, somente aquelas que acrescentam valor ao sistema dever�o estar presentes no sistema.

Obs: A quest�o de quais ferramentas e metodologias que devem ser usadas, est�o afetadas a organiza��o que vai desenvolver o sistema. Antes de adotar uma ferramenta ou metodologia talvez a pergunta que deve ser feita � : "Isso vai me ajudar a acrescentar e manter valor ao sistema ?"

Segundo Princ�pio - Mantenha as coisas simples (KISS - Keep It Simple ! Stupid)

Problema : Temos dificuldade em entender os sistemas quando eles se tornam mais complexos

O desenvolvimento de software n�o � um processo aleat�rio ou casual. H� muitos fatores a considerar em qualquer esfor�o de desenvolvimento.

Todo o projeto deve ser o mais simples poss�vel, isso n�o significa ser desprovido de recursos no sentido de n�o usar os recursos necess�rios.

Um projeto simples � f�cil de compreender e de manter. Isso n�o quer dizer que os recursos essenciais para que o projeto tenha sucesso sejam  descartados em nome da simplicidade.

Os modelos mais elegantes s�o geralmente os mais simples. Simples tamb�m n�o significa "r�pido e sujo." Na verdade, muitas vezes simplificar implica em muito trabalho que inclui v�rias itera��es e muita discuss�o.

A recompensa � um software que � mais f�cil de manter e menos suscet�vel a erros.

Terceiro Princ�pio - Mantenha a vis�o (Maintain the Vision)

Problema : Um sistema em constru��o esta se degradando em uma miscel�nea de projetos e subsistemas incompat�veis, amea�ando assim n�o cumprir o objetivo do projeto.

Uma vis�o clara e bem definida do sistema � essencial para o sucesso de um projeto de software.

Sem isso, um projeto quase infalivelmente acaba sendo concebido pela iniciativa de uma ou duas mentes restrito � sua pr�pria vis�o.

Se n�o existir uma integridade conceitual um sistema amea�a tornar-se uma multiplicidade de modelos incompat�veis unidas pelo tipo errado de parafusos.

Comprometer a vis�o arquitet�nica de um sistema de software enfraquece o projeto e acabar� por quebrar mesmo os sistemas mais bem projetados.

Ter um arquiteto com poderes que pode manter a vis�o e garantir o seu cumprimento ajuda a garantir um projeto de software de sucesso.

Quarto  Princ�pio - O que voc� produzir algu�m vai consumir (What you produce they  will consume)

Problema: Um monte de software que � produzido � dif�cil ou imposs�vel de usar, compreender, manter, ampliar, etc.

De alguma forma ou de outra algu�m vai usar, manter, documentar ou depender de ser capaz de compreender o seu sistema.

Assim, sempre especifique, projete e implemente tendo em mente que algu�m vai ter que entender o que voc� esta fazendo.

Especifique pensando nos usu�rios finais. Projete tendo em mente os desenvolvedores. Ao codificar preocupe-se com aqueles que devem manter e ampliar o sistema.

Algu�m pode ter que depurar o c�digo que voc� escreve, e isso faz dele um usu�rio de seu c�digo.

Tornar mais f�cil o trabalho de quem vai consumir o que voc� produziu agrega valor ao sistema.

Quinto  Princ�pio - Esteja aberto para o futuro (Build for today Design for tomorrow)

Problema : Como voc� lida com exig�ncias atuais de forma eficiente em face das necessidades futuras ?

Um sistema com uma longa vida tem mais valor.

No ambiente de desenvolvimento de software atual onde as especifica��es mudam em um piscar de olhos e onde as plataformas de hardware se tornam obsoletas com meses de uso, o tempo de vida de um produto de software geralmente � medido em meses ao inv�s de anos.

Por�m sistemas de softwares robustos e bem projetadas tendem a durar por mais tempo em produ��o.

Para fazer um produto de software com esse perfil de sucesso um projeto deve estar apto a se adaptar �s necessidades em constantes mudan�as do usu�rios. Isso somente � poss�vel para projetos que foram concebidos desde o princ�pio levando isso em conta.

Sempre pergunte : "O que acontece se...?"

E prepare-se para todos os tipos de respostas poss�veis de forma a criar sistemas que resolvam n�o um problema espec�fico mas um problema geral.

Sempre escreva o c�digo necess�rio na implementa��o e assegure-se sempre de que a arquitetura do projeto seja flex�vel e extens�vel de modo a ser capaz de envolver cen�rios futuros.

Adotando essa postura um projeto de software se torna mais reutiliz�vel.

Sexto  Princ�pio - Planeje com anteced�ncia para Reutiliza��o (Plan ahead for Reuse)

A reutiliza��o economiza tempo e esfor�o.

Alcan�ar um elevado n�vel de reutiliza��o � sem d�vida o objetivo mais dif�cil de alcan�ar no desenvolvimento de um sistema de software.

A reutiliza��o de c�digo e de projetos, foi proclamada como um dos principais benef�cios do uso de tecnologias orientadas a objeto. No entanto, o retorno sobre este investimento n�o � autom�tico.

Para alavancar as possibilidades de reutiliza��o que oferece a programa��o Orientada a Objetos � necess�rio planejamento e premedita��o.

Existem v�rias t�cnicas para realizar a reutiliza��o em todos os n�veis do processo de desenvolvimento de sistemas, e , aquelas relacionadas ao projeto detalhado e ao n�vel de c�digo s�o bem conhecidas e documentadas.

Embora exista uma grande quantidade de  literatura que aborda a reutiliza��o de projetos na forma de padr�es de software, � preciso mais que isso; � preciso comunicar as oportunidades de reuso para outras pessoas na organiza��o, isso � fundamental.

Como voc� pode reutilizar algo que voc� n�o sabe que existe ?

Planejar adiante para reutiliza��o reduz o custo e aumenta o valor dos componentes e dos sistemas que est�o incorporados.

Obs: Este princ�pio precisa ser examinado com cuidado pois segundo Kent Beck ele ignora a for�a mais importante no projeto de software:  o risco;  e ainda  sugere: Programe para hoje pois amanh� pode nunca chegar. ( Program for Today, for Tomorrow May Never Come.)

S�timo  Princ�pio - Pense ! (Think!)

Este �ltimo princ�pio � provavelmente o mais negligenciado.

Colocando o pensamento antes da a��o quase sempre se produz os melhores resultados.

Quando voc� pensa sobre algo, esta mais propenso a faz�-lo direito. Voc� tamb�m ganha conhecimento sobre como faz�-lo.

Se voc� pensa em algo e ainda assim a coisa sai errado,  isso � incorporado a sua base de experi�ncia e torna-se experi�ncia valiosa.

Al�m disso pensar � aprender a reconhecer quando voc� n�o sabe algo, e a que ponto voc� pode pesquisar a resposta.

Quando o pensamento claro entra em um sistema, o valor sai.

Aplicar os seis primeiros princ�pios requer um grande esfor�o de pensamento, mas as recompensas potenciais s�o enormes.

Com diz o ditado popular : "Bom senso e canja de galinha n�o fazem mal a ningu�m..."

"N�o se turbe o vosso cora��o;crede em Deus, crede tamb�m em mim." (Jo�o 14:1)

Refer�ncias:

• Padr�es de Projeto
• Padr�es de Projeto - O modelo MVC - Model View Controller
• O padr�o Singleton
• VB.NET - Permitindo uma �nica inst�ncia da sua aplica��o
• Design Patterns - o padr�o Factory
• Conceitos sobre projetos - Decomposi��o
• Usando o padr�o Strategy
• SRP - O princ�pio da responsabilidade �nica
• Boas Pr�ticas - O padr�o invers�o de controle (IoC)
• Se��o Padr�es de Projeto do site Macoratti.net

Jos� Carlos Macoratti

Quais são os princípios da engenharia de software?

Qual dos 12 princípios da engenharia de software deve ser desenvolvido com passos definidos e com precisão e ainda seguidos de maneira efetiva?

O que são práticas de engenharia de software?

Qual a principal característica da engenharia de software?