Encontrei este tópico no AccessVBA.com, achei interessante e gostaria de ver as suas respostas.

quote:

Gostaria de abrir uma discussão sobre a diferença entre Código que funciona e Código que funciona BEM. Temos milhares de truques para otimizar desempenho, assegurar níveis mais altos de confiabilidade, produtividade e padronização. Mas a maioria dos desenvolvedores está interessada, primariamente, em fazer a coisa funcionar e não tiveram o benefício da exposição a normas, metodologias e práticas de desenvolvimento mais restritivas.

Por favor, responda a este tópico com suas idéias sobre o assunto e quais as práticas que você utiliza para assegurar a qualidade de seus códigos.

Tomara que isto gere um bom assunto para discussão.

Esta é realmente uma discussao muito benvinda. Pena que teve que ser trazida de fora, pois questionamentos a respeito de "detalhes" como "desempenho, ... confiabilidade, produtividade e padronização", qualidade de software, enfim, via de regra não são muito benvindos neste forum, parece que ferem a autoestima dos membros

Com certeza um código otimizado é melhor para todos, na minha opinião o maior problema é falta de tempo do desenvolvedor de fazer um código otimizado, pois a pressão é grande para a resolução dos problemas.

Na minha opinião a questão depende exclusivamente da capacidade do desenvolvedor (não é porque esteja sob contrato que você vai se jogar do décimo-terceiro andar).

Complementando...

Costuma documentar (comentar) seu código?
Tem um banco onde estão salvas as rotinas que são sempre usadas, tipo uma biblioteca?
Usa padronização ao nomear variáveis?
Seus aplicativos tem manual para usuário?
Seus aplicativos tem ajuda on-line?
Seus aplicativos tem controle de versão?

Olá Osmar e colegas do fórum,

Segue aqui algumas práticas que gosto de adotar:

1) Faço um levantamento detalhado das necessidades junto ao usuário /requisitante, procurando extrair o máximo de informação possível das especificações;
2) Faço uma análise das informações obtidas no primeiro passo e gero um documento a partir (às vezes apenas um documento com as especificações e requisitos, outras com um digrama do fluxo de informações), e sento novamente com o requisitante para averiguar se não esquecemos de nenhum “pequeno detalhe” (que pode me dar uma “grande” dor de cabeça no futuro);
3) Feito isto, parto para a modelagem do banco de dados, aplicando as formas de normalização cabíveis (não consigo imaginar uma tabela com mais de 20 campos que não possa ser normalizada), que eu considero uns dos pontos chaves para qualquer sistema, seja em Access ou não, e pode influenciar e muito no desempenho de mesmo.
4) Depois destas três fases, que demandam um certo, que com certeza você ira recuperar daqui para frente, que começo a construção do sistema propriamente dito, tenho um “template” com as funções e classes que utilizo em quase todos os sistemas, como gosto de trabalhar com classes, desenvolvi um gerador de classes, que escreve a maioria do código que utilizo, deixando apenas as regras de negócios a serem implementadas, ou seja eu consegui isto graças a uma padronização do meu código, todas as variáveis são declaradas e seguem normas de nomenclaturas, o mesmo para funções, sub, forms, relatórios e tabelas, todos tem uma um norma de nomenclatura, além disso utilizo o vbeTools que ajuda em muito na documentação, principalmente para quem tem o hábito de colocar comentários no código. Acho muito importante também a inclusão de rotinas para tratamento de erro.
5) Após o término, faço alguns testes, uns dos pontos que preciso estudar para criar uma rotina de testes, sinto a necessidade conhecimento de técnicas mais estruturadas para teste de sistemas, crio um manual básico para o usuário e gero um setup da aplicação com o InnoSetup.

Pontos que gostaria de conhecer para poder implementar:
1) Gerar help on-line para o usuário, ainda não consegui estudar a ferramenta de help da Microsoft;
2) Técnicas de testes;
3) Técnicas para controle de versão.

Espero ter colaborado com a discussão.

Considero esta leitura importante (usabilidade, testes, ...). Muitas das vezes prefiro me concentrar no contexto e não no conteúdo.

Sucesso para todos
...

This message has been edited. Last edited by: Avelino Sampaio,

Coloco aqui minha forma de trabalho:


Costuma documentar (comentar) seu código?
Documento apenas o necessário, pois existem muitas rotinas que são totalmente claras, dispensando assim o comentário excessivo.
Sempre que crio uma rotina única, procuro documentá-la, pois essa fatalmente cairá em esquecimento, tornando-se assim alvo de comentário e/ou documentação específica, a fim de evitar-se perder tempo numa eventual consulta a esse procedimento.

Tem um banco onde estão salvas as rotinas que são sempre usadas, tipo uma biblioteca?
Sim. Baixei um aplicativo no site http://www.vbmania.com.br que achei interessante e procuro atualizá-lo constantemente.
Entrei no site para colocar o link aqui, mas ví que o aplicativo que utilizo não está mais disponível, mas tem outros 2 em seu lugar. Pesquise no site por library.
Coloquei o que utilizo para download AQUI.

Usa padronização ao nomear variáveis?
Sim, preferencialmente.

Para Variaveis locais:

Boolean : começam sempre com bln
Byte : começam sempre com byt
Currency: começam sempre com cur
Date : começam sempre com dat
Double : começam sempre com dbl
Integer : começam sempre com int
Long : começam sempre com lng

Para variaveis públicas, acrescento na frente a letra p

para variáveis globais, acrescento na frente a letra g

Tudo sempre em minúsculo, com a primeira letra do nome da variavel em maiúsculo. ex : pstrVariavel


Seus aplicativos tem manual para usuário?
Seus aplicativos tem ajuda on-line?
Hoje em dia envio meu aplicativo com um manual básico, pois ele possui uma ajuda on-line com mais de 200 pgs.
Porém, a prática me mostrou que é unânime: 100% dos clientes não utilizam a ajuda on-line, preferem ligar diretamente para o suporte.( pelo menos na minha área )
Em função disso, estou desenvolvendo um manual mais completo.

Seus aplicativos tem controle de versão?
Sim, para cada alteração no aplicativo, eu tenho um controle do que foi alterado e também qual é a versão.

Agora, para complementar essa matéria, gostaria de expor alguns erros básicos cometidos, acredito, pela grande maioria, inclusive por mim:

Não conhecer o perfil e o mercado do cliente.
Não planejar o Banco de Dados com o máximo de cuidado.
Não padronizar a programação.
Não escutar as necessidades do cliente.
Querer impor as suas regras ao negócio do cliente.
Não estar atento as limitações, sejam elas tecnológicas ou humanas.
Não cumprir prazos.
Falta de organização.
Prometer mais do que deve.
Relaxar com o passar do tempo.
Querer ganhar demais em pouco tempo.
Não saber cobrar o preço correto, enquanto alguns cobram muito outros cobram pouco.
Achar que sabe mais do que os outros.

Bom, para quem acha que isso não tem nada a ver com o tópico, isso é um engano.
Para um software RODAR BEM, precisamos obter exito em várias etapas e processos, e não simplemente escrever um código limpo.

A humildade é um dos grandes dons do ser humano, pena que seja utilizada por tão poucos.

Gostaria também de parabenizar a todos que contribuem para esse forum, pois isso mostra o que eu sempre tive convicção, que não precisamos esconder o que sabemos, pois, não importa se a pessoa sabe o que vc sabe, mas sim qual vai ser a forma com que ela vai utilizar esaa sabedoria, esse é o segredo do sucesso!!!
Quanto mais conhecimento adiquiro, maior fica a necessidade de compartilhá-lo, pois é muito gratificante saber que vc pode colaborar com outras pessoas que estão com dificuldades.
Peço desculpas a todos por não postar uma quantidade maior de msg, pois realmente o fator tempo, hoje, para mim é crucial.

Antes de julgar esse tópico, faça uma reflexão.... Será que em algum momento vc já não passou por uma dessas situações ?

Boa sorte a todos...