The Power of Proper Planning and Practices/fr

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

Planifiez en prévoyant la multiplateforme

Il y a plusieurs avantages à développer en prévoyant d'être multiplateforme. Probablement le plus grand avantage est que vous pouvez un meilleur résultat et un logiciel bien plus fiable. Cela est dû fait que le développement multiplateforme requiert que vous passiez plus de temps à planifier votre logiciel avant de commencer à écrire le code. Cela vous force aussi à développer de bonnes habitudes de programmation, à tester de manière plus approfondie votre logiciel, et de développer une approche plus disciplinée envers ce que vous faites. Ces choses (planification, tests, discipline) tendent à influencer certains aspects de votre développement, générant des améliorations toujours plus grande dans le design et la fiabilité.

Un autre avantage du développement multiplateforme est le fait qu'il vous expose aux autres plateformes. Par exemple, de nombreux développeurs Windows et probablement tous les développeurs Linux devraient bénéficier du temps passé simplement à utiliser un Mac de manière à développer une appréciation pour la facilité d'utilisation des logiciels et l'esthétique. Et de nombreux développeurs Windows pourraient bénéficier de voir comment Linux tend à utiliser les fichiers textes et les scripts pour beaucoup de choses, sans perte de performances des applications.

Un troisième avantage du développement multiplateforme est qu'il est par définition inclusif, ce qui vous force à prendre plus en considération vos utilisateurs que le font la plupart des programmeurs mono-plateforme.

La meilleure façon de faire une application multi-plateforme est de la concevoir pour être multiplateforme. Si vous prévoyez d'ajouter un support multiplateforme plus tard à votre application terminée, vous pourriez trouver que vous avez à réécrire certaines portions ou pire, découvrir que vous êtes dans un cul-de-sac Windowsiens qui fait que l'ajout du support multiplateforme est difficile ovoire impossible.

Si vous avez déjà développé une application Windows pour Delphi, il est possible dans certains cas de la convertir en application multiplateforme sans avoir à tout reprendre. Si vous voulez réaliser une conversion à sens unique de votre code et fiches Delphi vers Lazarus, vous pouvez utiliser quelques commandes de conversion du menu Outilsde Lazarus. Vous pouvez également convertir votre application Delphi vers Lazarus, mais prenez en compte la compatibilité avec Delphi [discussion needed].

Separate code into UI and non-UI units

//Séparez le code en Unités UI et non-UI (Interface Utilisateur)//

C'est probablement l'une des pratiques de programmation les plus importantes et que vous pouvez utiliser avec n'importe quelle application, que ce soit entre plates-formes ou non. Elle consiste à diviser votre code en unités d'interface utilisateur (UI - User Interface) et unités d'interface non-utilisateur (non - UI). En général, cela signifie que vos unités "non UI" ne doivent pas implémenter une interface utilisateur du programme et que vos unités d'interface utilisateur ne contiennent aucune des parties de calcul ou de base de données du programme. Dans la pratique, une bonne façon d'appliquer cette séparation consiste à exiger que les unités que vous développez utilisent uniquement des unités appropriées à chacune des parties de cette «division». Par exemple, vos unités non-UI ne doivent pas utiliser d'unités LCL telles que les formulaires, les boîtes de dialogue, les StdCtrls (contrôles standards), les boutons, les graphiques, les contrôles, les "LMessages", etc., ou l'une de vos unités qui utilisent ces unités. Et vos unités UI ne devraient probablement pas utiliser des unités telles que Math, Dbf, MySQLDB4, etc. Suivez l'exemple des unités Free Pascal et Lazarus elles-mêmes, où les unités à usage général comme "SysUtils", Classes et Variantes n'utilisent pas d'unités LCL Et les unités LCL comme "Forms" et "Controls" ne fournissent pas de routines générales.

Il existe plusieurs avantages à diviser votre code de cette manière. Par exemple, cela signifie que vous pourrez utiliser vos unités "non-UI" dans n'importe quel type de programme, que ce soit une application GUI, une bibliothèque, une application console, même une application Web, sans apporter de modifications au code. Et cela signifie également que, si nécessaire, vous pouvez développer une interface utilisateur complètement différente pour votre programme ou passer à une autre bibliothèque ou contrôle "UI" sans modifier le code sous-jacent "non-UI". Il est également essentiel que ce partitionnement soit effectué dans de grands projets afin que plusieurs développeurs puissent travailler sur différentes parties du programme sans se gêner les uns des autres.

Vous pouvez également trouver utile de subdiviser davantage votre code "non-UI". Par exemple, vous voudrez peut-être mettre tout le code d'accès à la base de données dans un ensemble d'unités et toutes les logiques métier et code de cryptage dans un autre ensemble d'unités. De plus, vous voudrez mettre tout le code dépendant de la plate-forme (shelling, registre, presse-papiers, etc.) dans son propre ensemble d'unités pour isoler ce code et faciliter le portage sur d'autres plates-formes.

Use batch files and shell files

// Utiliser les fichiers de traitement par lots (Batch) et les fichiers shell//

Même si Lazarus vous permet de modifier et de compiler le code et de définir la plupart des commutateurs de compilation sans jamais quitter l'IDE, il sera probablement utile de créer plusieurs fichiers de traitement par lots (batch) pour chaque projet. Les fichiers de traitement par lots ne sont que des fichiers texte spéciaux contenant des commandes de console. Vous les créez avec un éditeur de texte. Avec Windows, les fichiers de traitement par lots (batch) ont une extension .bat ou .cmd. Avec OS X et Linux, les fichiers batch ont une extension .sh. Vous exécutez généralement un fichier batch en entrant son nom dans une fenêtre de console, comme suit :

Avec Windows :

 mybatch.bat

Notez que vous pouvez omettre l'extension .bat s'il n'y a pas de fichier .exe avec le même nom.

Avec Unix :

 ./mybatch.sh

Il existe de nombreuses façons d'utiliser les fichiers batch dans le développement. Par exemple, vous pouvez avoir un ensemble d'options de compilation que vous utilisez pendant le développement et un autre ensemble que vous utilisez pour créer l'exécutable que vous distribuez. Voici un exemple de commande que vous pouvez mettre dans un fichier batch qui exécute le compilateur Free Pascal :

Avec Windows :

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

Avec Unix:

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

La commande ci-dessus compile l'unité ou le programme non-graphique spécifié sur la ligne de commande avec la compatibilité Delphi, les assertions, la vérification des E/S, la vérification de la portée, la vérification des débordements, la vérification de la pile et le suivi du numéro de ligne activé. Notez que vous pouvez ajouter des commandes supplémentaires avant et après la compilation à un fichier batch. Par exemple, vous pouvez exécuter l'utilitaire "strip.exe" pour réduire la taille de votre fichier exécutable ou copier l'exécutable dans un autre dossier pour les tests.

Voici une commande similaire que vous pouvez mettre dans un fichier batch pour compiler un programme GUI que vous spécifiez sur la ligne de commande :

Avec Windows (tout sur une seule ligne) :

 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

Avec OS X (tout sur une seule ligne):

 /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/ $@

How to avoid using a debugger

//Comment éviter d'utiliser un débogueur//

L'utilisation d'un débogueur est rarement très amusante. Cela signifie souvent que vous avez renoncé à essayer de comprendre ce qui ne va pas avec votre programme et que vous avez invité le débogueur en dernier recours. Voici quelques techniques simples que vous pouvez employer et qui vous aideront à minimiser l'utilisation d'un débogueur :

- Développez avec tous les contrôles d'exécution activés. Vous pouvez en désactiver certains ou tous les contrôles lorsque vous créez un exécutable pour la distribution, bien que les améliorations de la taille du code et de la performance soient négligeables en désactivant les contrôles d'exécution. De plus, laisser ces contrôles activés peut vous aider à localiser des bogues qui surviendraient plus tard.

- Utilisez les assertions. À l'instar des vérifications d'exécution, les assertions peuvent être désactivées plus tard, même si elles peuvent vous aider à diagnostiquer les bugs rencontrés par vos utilisateurs.

- Compilez avec le suivi du numéro de ligne activé. Vous pouvez éteindre cette option lorsque vous terminez et livrez votre programme pour réduire la taille de l'exécutable.

- Si votre code gère les exceptions, vous pouvez toujours déterminer le numéro de ligne et le nom du fichier source où l'exception s'est produite en utilisant le traçage des numéros de ligne et la fonction FPC BackTraceStrFunc, comme dans ce code d'exemple :

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

Les lignes {$ IFDEF} et {$ ENDIF} vous permettent de compiler aussi ce code avec Delphi.

- Initialiser les variables. Bien que Delphi et FPC initialisent les variables globales et les champs d'objet, les variables locales liées aux routines ne sont pas initialisées. C'est une bonne idée d'initialiser toutes les variables simplement pour être clair sur leurs valeurs initiales.

- Activez les avertissements du compilateur et faites attention à eux. - Utilisez "with" avec parcimonie. Bien que l'instruction Pascal puisse vous enregistrer beaucoup de saisie, elle peut également cacher des références de champs incorrectes si vous utilisez des instructions imbriquées ou si un champ avec le même nom qu'un champ dans la cible de votre cible est ajouté un jour à une classe d'ancêtre.

- Exécutez votre code via plusieurs compilateurs. Il y aura toujours des différences dans la façon dont les différents compilateurs traitent votre code. Parfois, ces différences sont dictées par le système d'exploitation ou le matériel sous-jacent. Essayez de compiler votre programme (ou au moins les unités non-UI) avec deux ou trois compilateurs. Par exemple, si votre code se compile et fonctionne correctement avec Delphi et sur au moins deux des plates-formes de FPC, vous serez presque certain, non seulement d'avoir une application plate-forme stable, mais aussi d'avoir un programme qui fonctionne correctement.