The Power of Proper Planning and Practices/pt

│ English (en) │ français (fr) │ português (pt) │

Planejar diretamente para cross-plataforma

Existem muitas vantagens em fazer o seu desenvolvimento de maneira cross-plataforma. Provavelmente a mais importante é que pode dar um resultado melhor e mais confiável. Isto acontece porque o desenvolvimento cross-plataforma requer que você gaste mais tempo planejando o seu software antes de começar a escrevê-lo. Também o força a desenvolver bons hábitos de progrmação para testar mais o seu software e desenvolver uma abordagem mais disciplinada em relação ao que você está fazendo. Estas coisas (planejar, testar, disciplina) tendem a contagiar outros aspectos do seu desenvolvimento, resultando em um ainda melhor design e confiabilidade.

Outra vantagem do desenvolvimento cross-plataforma é que ele o expõe a outras plataformas. Por exemplo, muitos desennvolvedores para Windows e provavelmente todos os desenvolvedore para Linux poderiam se beneficiar de algum tempo gasto simplesmente usando o Mac como modo de desenvolver uma apreciação para software em facilidade de uso e estética. E muitos desenvolvedores Windows poderiam se beneficiar de como o Linux tende a usar arquivos-texto e scripts para muitas coisas sem perda de performance nas aplicações.

Uma terceira vantagem do desenvolvimento cross-plataforma é que ela é por definição inclusiva, o que o força a considerar seus usuários mais que a maioria dos programadores de plataforma única fazem.

A melhor maneira de fazer uma aplicação cross-plataforma é desenhá-la para ser assim. Se você planejar para adicionar suporte cross-plataforma mais tarde, você pode precisar reescrever partes do programa ou, pior, encontrar-se em um beco-sem-saída "Windows-only" que torne o suporte cross-plataforma difícil ou impossível.

Se você já desenvolveu uma aplicação para Windows com Delphi, é possível em algumas situações convertê-la para cross-plataforma sem recomeçar. Se você quiser fazer uma conversão de mão-única do seu código e formulários Delphi para Lazarus, você pode usar alguns dos comandos de conversão do menu Ferramentas do Lazarus. Se você também quer converter para Lazrus, mas reter a compatibilidade com Delphi, [discussion needed].

Código separado para unidades UI e não-UI

Provavelmente uma das mais importantes práticas de programação que você pode empregar com qualquer aplicação, seja cross-plataforma ou não, é dividir seu código entre unidades de interface de usuário (UI) e não-interface-de-usuário. Em geral, isto quer dizer que as suas unidades não-usuário não devem implementar algo da interface de usuário e as unidades de interface de usuário não devem conter nada da parte computacional ou de banco de dados do programa. Na prática , uma boa forma de forçar esta separação é requerer que as unidades que você desenvolve somente use unidades do seu próprio lado desta divisão. Por exemplo, suas unidades não-usuário não devem usar unidades da LCL ou unidades como Forms, Dialogs, StdCtrls, Button, Graphics, Controls, LMessages, etc, ou qualquer das suas unidades que usem essas unidades. E suas unidades-usuário não devem usar unidades como Math, Dbf, MySQLDB4, etc. Siga o exemplo do Free Pascal e do Lazarus, em que unidades de propósito geral como SysUtils, Classes e Variants não usam unidades LCL e unidades LCL como Forms e Controls não provêem rotinas de propósito geral.

Existem muitas vantagens de dividir o seu código assim. Por exemplo, isso significa que você será capaz de usar as suas unidades não-usuário em qualquer tipo de programa, biblioteca, console, até uma aplcação Web, sem fazer qualquer modificação no código. E isto também significa que você pode desenvolver uma interface de usuário completamente diferente se necessário ou mudar para uma biblioteca ou controle sem modificar o código não-usuário remanescente. Também é decisivo que esta partição seja feita em projetos grandes de modo que múltiplos desenvolvedores possam trabalhar em diferentes partes do programa sem pisar nos pés uns dos outros.

Você também pode achar isso útil para futuramente subdividir seu código não-UI. Por exemplo, você pode querer pôr todo o código de acesso a banco de dados em um grupo de unidades e todo o código de lógica de negócios e nnúmeros em outro grupo de unidades. Mais, pode querer pôr todo o código dependente de plataforma (shelling, registry, clipboard, etc.) em seu próprio grupo de unidades para isolar este código e tornar mais fácil portar para outras plataformas.

Usar arquivos de lote e arquivos shell

Mesmo que o Lazarus permita editar e compilar código e configurar a maioria das switches sem deixar a IDE, você vai provavelmente achar útil criar muiitos arquivos de lote para cada projeto. Arquivos de lote são só arquivos de texto contendo comandos de console; você os cria com um editor de texto. Com Windows, arquivos de lote tem uma extensão .BAT ou .CMD; com OS X e Linux, arquivos de lote tem extensões .SH. Você tipicamente executa o arquivo de lote entrando o seu nome em uma janela de console, como segue:

Com Windows:

 mybatch.bat

Note que você pode omitir a extensão .BAT se não existir nenhum arquivo .EXE com a mesma extensão.

Com Unix:

 ./mybatch.sh

Existem muitas maneiras em que arquivos de lote podem ser usados em desenvolvimento. Por exemplo, você deve ter um grupo de opções de compilador que você usa durante o desenvolvimento e outro grupo que você usa para criar o executável que você distribui. Aqui está um exemplo de comando que você pode pôr em um arquivo de lote que executa o comppilador Free Pascal:

Com Windows:

 c:\lazarus\pp\bin\i386-win32\fpc.exe -Sda -Cirot -gl %1

Com Unix:

 /usr/local/bin/fpc -Sda -Cirot -gl $@

O comando acima compila a unidade ou programa não-GUI especificado na linha de comando com compatibilidade Delphi, assertions, I/O checking, range checking, overflow checking, stack checking, and line number tracing ligadas. Note que você pode adicionar pre ou pós-comandos do compilador em um arquivo de lote. Por exemplo, você pode executar o utilitário strip.exe para diminuir o tamanho do seu executável ou copiar o executável para uma pasta diferente para testar.

Aqui está um comando similar que você pode pôr em um arquivo de lote para compilar um programa GUI que você especificar na linha de comando:

Com Windows (tudo numa única linha):

 c:\lazarus\pp\bin\i386-win32\fpc.exe -dLCL -WG -Sda -Cirot -gl
  -Fuc:\lazarus\lcl\units\i386-win32;c:\lazarus\lcl\units\i386-win32\win32 %1

Com OS X (tudo numa única linha):

 /usr/local/bin/fpc -dLCL -WG -Sda -Cirot -gl -Fu/usr/local/share/lazarus/lcl/units/powerpc-darwin
  -Fu/usr/local/share/lazarus/lcl/units/powerpc-darwin/gtk -Fl/usr/X11R6/lib/ -Fl/sw/lib/ $@

Como evitar de usar um depurador

Usar um depurador raramente é divertido. Aqui estão algumas técnicas simples que você vai empregar que vão minimizar o seu uso do depurador:

Desenvolver com todos os run-time checks ligados. Você pode desligar alguns ou todos quando criar um executável para distribuição, pois o ganho o ganho no tamanho do código e na performance ao desligá-los é pequeno. Mais, deixar as checagens ligadas pode ajudar a localizar bugs que aparecem mais tarde.

• Usar assertions. Como para run-time checks, assertions podem ser desligadas depois, pois deixando-os ligados podem ajudar a localizar bugs que os seus usuários encontrarem.
• Compilar com line number tracing ligado. Você pode desligar quando publicar seu programa para diminuir o tamanho do executável.
• Se o seu código maneja excessões, você pode até determinar o número da linha e nome do fonte onde a excessão ocorreu usando line number tracing e a função FPC BackTraceStrFunc , como neste exemplo de código:

   try
     raise Exception.Create('Exception here');  
   except
 // Handle exception here.
 {$IFDEF FPC}
     WriteLn(BackTraceStrFunc(ExceptAddr));
 {$ENDIF}
     end;

As linhas {$IFDEF} e {$ENDIF} garantem que você possa compilar este código com Delphi também.

• Inicialize variáveis. Mesmo que o Delphi e o FPC inicializem variáveis globais e campos de objetos, variáveis locais para rotinas não são inicializadas. É uma boa idéia inicilizar todas as variáveis só para ficar claro quais são os valores iniciais.
• Ligue os compiler warnings e preste atenção a eles.
• Use "with" esparçamente. Mesmo que o estamento Pascal "with" possa economizar bastante digitação, ele pode esconder referências de campo incorretas se você os usar aninhados ou se um campo com o mesmo nome no seu estamento "with" é adicionado algum dia a uma classe ancestral.
• Execute o seu código através de múltiplos compiladores. Sempre vai haver diferenças em como diferentes compiladores processam seu código. Às vezes elas são ditadas pelo sistema operacional ou pelo hardware. Tente compilar seu programa (ou pelo menos a parte não-UI) com dois ou três compiladores.

Por exemplo, se o eu código compilar e executar corretamente com Delphi e pelo menos duas plataformas do FPC, você vai estar mais perto não só de um programa estável em cross-plataforma como de ter um programa que você sabe que vai funcionar.