VoidByte

Programar é pensar, muito mais que codificar

Verificando a Versão do Compilador

1372276943_malicious_codeA solução incômoda

As versões do DELPHI tem evoluído com o tempo, acrescentando novos recursos e avanços. A evolução é boa, mas há situações em que o código só funciona com as versões mais recentes.

As funções de API do WINDOWS, por exemplo, tiveram alterações nos tipos dos argumentos. Os tipos dos argumentos mudaram de PCHAR para PWIDECHAR. O que fazer então? Muitos usam a sintaxe abaixo:

{$IFDEF VER220}// Delphi XE
{$DEFINE ARG_PWIDECHAR}
{$ENDIF}

{$IFDEF VER230} // Delphi XE2
{$DEFINE ARG_PWIDECHAR}
{$ENDIF}

A correção funciona, mas tem seus inconvenientes. O fato é que as diretivas VERXXX,  que variam conforme a versão do DELPHI, tem que ser verificadas individualmente, como no exemplo acima.

O código fica estranho, parece estar duplicado. Quando a versão mudar para VER240 OU VER250 a verificação deixará de funcionar, exigindo manutenção do código.

A solução elegante

A solução anterior funciona,  mas está propensa a falhas,  Ao fazer uma  pesquisa mais detalhada a respeito destas diretivas, fiquei surpreso ao  descobrir um recurso útil para resolver a questão das versões:

{$IF COMPILERVERSION > 21}
{$DEFINE ARG_PWIDECHAR}
{$IFEND}

 

O par $IF . . .  $IFEND  tem a mesma função do $IFDEF . . . $ENDIF. A versão  do compilador do DELPHI, COMPILERVERSION,  é uma constante numérica, o que permite fazer comparações usando os operadores ‘=’, ‘<‘  e ‘ >’.

Com a verificação da versão do compilador, o código acima definirá a condicional ARG_PWIDECHAR. A condicional será usada para indicar o uso de argumentos tipo PWIDECHAR apenas se a versão do DELPHI for superior ao DELPHI 2010. Abaixo a lista de valores com a versão de cada compilador e com o símbolo de  diretiva correspondente.

Compilador Versão Símbolo
Delphi XE4 25 VER250
Delphi XE3 24 VER240
Delphi XE2 23 VER230
Delphi XE 22 VER220
Delphi 2010 21 VER210

Essa é a dica, use o método elegante, mantenha seu código limpo e claro.

Bom código!

Requisitos : programe com um destino

1372188386_Sign_directionSem rumo

Já se sentiu perdido, sem saber pra onde ir ?  A sensação é a mesma quando estamos desenvolvendo software  sem ter  os requisitos bem especificados.  O projeto que é iniciado sem requisitos claros resulta em perda de tempo e desgaste profissional.

Talvez até digam que o seu trabalho está demorando demais. Talvez digam que suas soluções para os desafios propostos são muito  complicadas.  O fato é que programar sem ter requisitos funcionais e não funcionais definidos é como dirigir na neblina, sem visibilidade alguma. Como evitar situações como esta? É preciso estar atento a algumas armadilhas.

A falta de gerenciamento dos requisitos é um fator muito comum em projetos que fracassam. Estive lendo um artigo que mencionou o método ‘codifica-remenda’. Este método é usado quando o desenvolvedor não tem uma ideia clara do que o produto tem que fazer. A cada nova definição, ou falta de definição, o produto é modificado até ser entregue ou  mesmo abandonado.

 Distorções

Os requisitos  também podem ser distorcidos por problemas de comunicação.  A questão é que muitas vezes os requisitos existem, mas não são levantados e documentados de forma correta. Nada é mais perigoso do que passar requisitos apenas oralmente, sem uma validação formal.

O resultado da falta de documentação  é:  o gerente do projeto passa para o líder de equipe de uma forma, o analista entende de outra. O analista passa para  o programador e este implementa de outra forma. A confusão só vai aparecer quando o testador  verificar se o requisito foi cumprido, ou pior, quando o cliente for usar.

 Registre!

Outro descuido perigoso é documentar e não atualizar o documento quando há mudanças  ou são acrescentados novos requisitos. Reuniões periódicas são importantes para manter  o rumo correto do desenvolvimento. Mas é preciso gerar um  documento que formalize as decisões tomadas sobre os requisitos e  prioridades. O sintoma comum deste descuido é um conjunto de decisões tomadas a  dois ou três anos atrás que nunca foram aplicadas.

A verdade é que os requisitos são a base essencial para um software de qualidade.  Cuidar bem do levantamento  e  gerenciamento destes é vital para o sucesso dos projetos de software. Sem as especificações claras e registradas não há como saber o que testar ou mesmo o que é prioritário.

O ponto é : trabalhe com uma especificação decente antes de programar. Assim ninguém poderá dizer que ou seu trabalho é mediano.

É requisito de um bom trabalho.

Boa codificação!

Erros comuns

Inspiração zero.

1369856793_horrorTem dias em que não deveríamos sair de casa.
Tem outros em que deveríamos bem longe de qualquer pedaço de código.

O motivo é que quando estamos cansados ou sem  inspiração ocorrem deslizes estranhos.

Abaixo alguns exemplos:

1. No principio da string…

var
i : Integer;
s : string;
begin
  s := EmptyStr;
  for i := 0 to Length(edt1.Text) do
    begin
      s := edt1.Text;
      s[i] := '*';
      edt1.Text := s;
    end;
end;

Notaram o erro? A posição 0 da string é alterada para ‘*’
Lembrando que o  tipo String sempre começa na posição 1 .
Ativando a diretiva de compilação Range Check o erro se torna evidente.

2. Exceção excepcional…

try
	{...}
except
  on E: EDudeException do
    begin
      Result := False;
    end;

on E: Exception do //
     raise E;
end;

Aqui ocorre um EACCESSVIOLATION, pois o compilador
libera a memória da variável E após o tratamento

//O correto seria utilizar:

Else  // não criar a variável E, pois não será usada.
    raise;
end;

Quando estiver se sentindo cansado,  sem inspiração, o melhor é tomar um café ou andar um pouco pra relaxar.

Tenha cuidado, se estiver em um dia difícil,  códigos como  acima  podem acontecer!
É isso aí, bom código!

Desenvolvimento ágil, saindo da estaca zero

Saindo da estaca zero

Este é um artigo de opinião, baseado no que já vi no mundo afora. O ponto de vista  pode ter ou não a sua aprovação, pois vivemos no mesmo mundo, mas cada um o enxerga do seu próprio  jeito. Gostaria apenas de fazer o caro leitor PENSAR.

1369262984_i_have_no_ideaIndiferença

O principal obstáculo para o crescimento dos indivíduos e da qualidade de uma equipe é a indiferença.
Esta doença é visível quando as decisões são baseadas na conveniência ou na comodidade.
Equipes e líderes acomodados fazem o que for necessário para se poupar de desafios.

Um princípio que considero legal é: para descobrir como algo funciona precisamos descobrir primeiro como NÃO funciona. As técnicas ágeis de desenvolvimento muitas vezes não funcionam ou  são abandonadas por causa da falta de empenho em aprender.

A refatoração do código, testes unitários e o  controle de versão são ferramentas essenciais para um bom trabalho. No entanto, estas atividades exigem esforço e disciplina que precisam ser cultivados e estimulados.

A equipe precisa desenvolver perícia em usar as  ferramentas de trabalho. Um bom trabalhador é aquele que sabe usar bem suas ferramentas. O mesmo pode ser dito do programador. A falta de um espírito inovador pode ser o principal obstáculo para o aprimoramento da equipe de desenvolvimento.

Liderar para mudar

A empresa, a diretoria ou a gerência podem  e devem incentivar, mas não é delas a responsabilidade principal. A equipe, principalmente o líder,  é quem deve buscar metas de qualidade em seu trabalho.

O líder é quem deve estabelecer o modelo para o comportamento de sua equipe. O líder deve valorizar o esforço e a disciplina para gerar um trabalho bem feito. A liderança estagnada  prejudica a equipe tomando decisões que favorecem a comodidade.

O caso não é que o líder deva dizer como cada um deve fazer ou seu trabalho. O seu papel envolve se certificar que cada um entenda os princípios das boas práticas de programação e que todos estejam capacitados para aplicá-los no dia a dia.

A visão de que tudo é muito complicado, que não vale a pena se esforçar em conhecer uma nova ferramenta ou metodologia deve ser evitada . A manutenção deve ser vista como  uma atividade necessária para manter a qualidade do produto, em vez de ser vista como um pesadelo.

A equipe que quer evoluir deve fugir das desculpas comuns:   falta de  tempo, prazos apertados, pressão do comercial, muitas tarefas acumuladas. O fato é que quem se justifica não muda. Mudar exige esforço e adaptação, e o partidário do menor esforço não muda,  nem mesmo as suas desculpas mudam.

Assine sua obra

Um sintoma da falta de esforço é a ausência da assinatura no código. Os artistas fazem questão de assinar um trabalho bem feito, que levou muito tempo e esforço.Programadores devem fazer o mesmo. Importe-se em escrever um bom código.  Um código bem escrito e reaproveitável deve ser motivo de satisfação e mesmo orgulho. A questão não é alcançar um código bonito, mas código limpo e fácil de entender. Código é uma forma de comunicação, e deve passar uma mensagem clara e objetiva.

Quem não fica contente quando descobre uma maneira de reduzir e simplificar um código, usando novas ou velhas técnicas? Quem não fica  feliz quando reaproveita um código que escreveu a mais de cinco anos atrás. O bom profissional  valoriza tais coisas.

Faça valer

O resultado da indiferença com seu trabalho é  um código medíocre. Não que este não funcione ou que não atenda as necessidades imediatas. O resultado é medíocre por que poderia ter sido feito melhor, poderia ter uma eficácia e uma qualidade melhor. O código fica parecendo um rascunho que não foi passado a limpo.

Fuja da lei do menor esforço, cresça pessoalmente como programador ou líder. Não faça código apenas pensando no agora, programe pensando no futuro.Tenha orgulho do seu trabalho.

A equipe, a empresa e os clientes agradecem.

Comparando horários

Está na hora?

Revisando uma rotina de verificação de horários, acabei descobrindo a função CompareTime declarada em DateUtils. A rotina abaixo traz a vantagem de fazer a comparação apenas do horário, desconsiderando a data.

// Verificar se uma data está dentro
// de um intervalo de horário passado.
function VerIntervalo( aIni, aFim: TTime): Boolean;
 begin
 Result :=
    (CompareTime(time, aIni) = GreaterThanValue) and
    (CompareTime(time, aFim) = LessThanValue);
 end;

O exemplo usa as constantes GreaterThanValue e LessThanValue, as duas estão  declaradas na unit Types.

A vantagem é deixar o código mais legível. O benefício provém da dispensa dos operadores ‘>’ , ‘<‘, ‘>=’ e ‘<=’ que podem causar certa confusão em uma rotina mais complexa. O efeito de uma distração e de um sinal trocado por engano pode causar um erro difícil de diagnosticar.

É isso, bom código!
Engenharia de Software

Este blog tem como meta apresentar algumas discussões e opiniões relacionadas a engenharia de software.

Roberto Schneiders

A blog about experiences on software development

Testando Software

Aprendizado sobre técnicas, processos, ferramentas e adversidades do teste de software.

Meu mundo - Carlos Eduardo

Just another WordPress.com weblog

Delphi, Delphi Prism, Visual Studio, C#, ASP.NET

Para todos aqueles amantes da arte do desenvolvimento de Software.

andersonoliveirasilva

Tecnologia da informação pra quem gosta de TI

reGIFELix

Alimentando o vicio pela informação e conhecimento em Java e Web Design

Diego Garcia

Delphi, Scrum, Arquitetura de Software e um pouco mais...

Ricardo Boaro

Embarcadero MVP

Blog do Fusco

Visões sobre Tecnologia da Informação

Leandro Cunha facts

Meu mundo virtual

simasware blog

Desenvolvimento e Software Livre

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

%d blogueiros gostam disto: