I-2.2.2. Règles de développement
par
, 01/04/2020 à 11h00 (392 Affichages)
L’objectif n’est rien d’autre que de concevoir un AGL de développement simple, non contraignant pour optimiser, standardiser la programmation, pour organiser la synergie des investissements.APL-AML est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.
■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■
- Les écrans
- Structure d’accueil
- Convivialité
- Ergonomie
- Les états
- Structure d’accueil
- Formulaires
- Commandes HP PCL 5 et GPL/2
- Les shells
- Adoption d’un standard
- Exemple de shell invoqué via un item du menu ou depuis le prompt
- Exemple de shell avec une fonction récursive
- Le système de menus
- Beauté du logiciel
Un exercice intéressant consiste à demander à un groupe de développeurs (ou d’étudiants) de concevoir l’écran répondant aux besoins exprimés par des gestionnaires à partir d’une description des données utiles de la base de données. Il est étonnant de constater la diversité et la complexité des propositions alors que l’on pourrait s’attendre à une convergence des réflexions et que les écrans proposés soient sinon identiques, du moins très ressemblants.
1. Les écrans
■ Structure d'accueil
La structure d’accueil d’un écran est relativement simple et peut se résumer en :
- Définition des écrans
- Liste des tables utilisées
- Définition des attributs de chaque table
- Instructions
Les sources de quelques écrans, spécifiques du SGBD/R « Informix ESQL », n’apporteront rien aux adeptes d’autres langages, ce n’est pas l’objectif.
Ce n’est même pas du 4GL, il n’y a pas de boîtes de dialogue qui transforment les gestionnaires en assistés-cliqueurs. Tout est dans l’épure ergonomique du mode caractère et la convivialité, concernant la fonctionnalité de l’IHM ; dans les règles de mise en page et les commentaires, concernant sa programmation.
NB : Des programmes écrans sont proposés dans les « Annexes ». Ils montrent la cohérence, la qualité, la rigueur, la lisibilité des développements pourtant réalisés dans un contexte APL-AML.
■ Convivialité
La convivialité s'intéresse au dialogue Logiciel <-> Terminaliste, donc au contenu :
- regroupement des informations de même nature,
- titres et messages explicites,
- codification mnémonique,
- conventions,
- symbolisme,
- logos,
- etc.
■ Ergonomie
(du grec ergon, travail), l'ergonomie a pour objectif d'optimiser la productivité.
En informatique, l'ergonomie des écrans concerne leur contenant, à savoir leur aspect physique (équilibré, structuré), leur charte graphique, leur esthétique, leur dynamique (enchaînements, déplacement du curseur, raccourcis).
L'enchainement des fonctionnalités et leurs positionnements graphiques doivent permettre un parcours logique et fluide pour les utilisateurs.
Bien que l'on évoque moins l'ergonomie des états, les choix du format (A3/A4), du mode d'impression (portrait/paysage), de l'impression (recto/recto-verso), sont autant de critères ergonomiques auxquels il convient d'associer l'adoption de la même charte graphique, la même esthétique que celle des écrans.
À partir d’un écran (ou d’un état, d’ailleurs), on peut estimer le degré de réflexion du développeur et déceler, par exemple, s’il tient compte ou non des difficultés visuelles de beaucoup d’utilisateurs, de leur éventuelle fatigue mentale, ou du fait que la plupart des gens ne lisent pas (états). La simple conception d’un écran met en évidence l’esprit d’analyse et de synthèse, la créativité, la technicité, la simplicité, la qualité du message, la personnalité, l’humanité.
On peut certainement dire qu’il y a autant de versions d’écrans que de développeurs. Pourtant, à partir des mêmes besoins utilisateur, il ne devrait y avoir qu’une version idéale.
Au même titre que la graphologie est une technique d'analyse de l'écriture qui affirme pouvoir déduire systématiquement des caractéristiques psychologiques de la personnalité d’un individu à partir de l’observation de son écriture manuscrite, l’analyse d’un écran ou d’un état (Conceptologie ?) devrait pouvoir déduire la technicité et la personnalité du développeur.
Anecdote :
2. Les états
■ Structure d'accueil
Même les langages structurés ne peuvent pas empêcher de programmer sans rigueur. Il appartient à chacun de créer ses propres bonnes pratiques de programmation. Ça n’est pas vraiment de la documentation mais des règles de mise en page à l’instar des règles de mise en page des livres. Personnellement, j’ai besoin d’au moins deux mois de pratique pour apprivoiser un nouveau langage, pour créer ce que j’appelle ma « Structure d’accueil ».
La « Structure d'accueil » standardise les conventions adoptées, les règles d'écriture et de présentation des programmes d’édition créés avec le générateur d’état ace (Informix) :
- squelette du programme, canevas,
- identification du programme,
- méthodologie de programmation,
- utilisation des majuscules et des minuscules,
- indentation,
- noms de variables communs à tous les programmes de l'application,
- règle d'écriture des paramètres et variables spécifiques,
- shell d'exécution, sous forme de commentaire, en fin de programme.
Discussion : Documentation sur la documentation
IFA2377 :
Discussion : Qu’est-ce qu’un bon code ?Une fois définie pour un langage, la difficulté réside dans son adaptation aux spécificités d'un nouveau langage. Une structure d'accueil n'a rien de contraignant car chaque nouveau programme s'écrit à partir d'une copie de programme(s) existant(s), et les éditeurs permettent de faire facilement des copier-coller. Certains développeurs pourraient cependant y voir un frein à leur créativité. Concevoir une structure d'accueil, n'est-ce pas précisément faire preuve d'imagination ? Certes, il s'agit de s'investir sur l'esthétique, la présentation, la lisibilité plutôt que sur les astuces de programmation, mais quel est l'intérêt de réinventer l'eau chaude à chaque nouveau programme ?
L'objectif de la structure d'accueil est de rendre le programme aussi lisible qu'un document écrit afin d'éviter le recours à tout dossier d’analyse ou de programmation, à tout organigramme. Tous les programmes étant construits d'après la même architecture, il suffit à une tierce personne de saisir le fil conducteur, de comprendre la logique qui a régi l'un des programmes de l'application pour qu'elle « décode » tous les autres sans difficulté. Rien n'est plus décevant, angoissant, déprimant que d'intervenir dans un programme sans personnalité, sans repères, sans la moindre trame décelable, susceptible d'en guider la lecture.
Certains artifices de forme ne sont pas à négliger. WINDEV, Delphi, les éditeurs utilisent la couleur pour distinguer instructions, données et variables. Dans le même esprit, sous UNIX, le seul fait d'utiliser des majuscules pour les instructions et des minuscules pour les données ou variables améliore considérablement la lecture des programmes (le compilateur Informix traite indifféremment les majuscules et les minuscules). En rendant les instructions suffisamment compréhensibles, les traitements se passent de commentaires. En résumé, un programme est un tout, pas seulement un cocktail de codes commentés, mais un véritable document lisible, digeste qui se suffit à lui-même.
IFA2377 :
yahiko :Je ne sais pas si tous les compilateurs l’acceptent, mais personnellement j’utilise les MAJUSCULES pour les INSTRUCTIONS et les minuscules pour les données. Ce n’est pas grand-chose mais cela apporte un peu de relief et je lis mieux mon code. Évidemment, toutes les données que je manipule sont préfixées.
J’exploite également les caractères début/fin de commentaire, pas forcément pour commenter mais pour structurer visuellement, pour habiller le programme afin de le rendre le plus lisible et le plus compréhensible possible. Je parle de structure d’accueil, de canevas, de squelette ou encore de skin.
Lorsque je m’initie à un nouveau langage, il me faut bien deux mois de développement pour créer et affiner mon environnement de développement. Je ne pense pas que cette démarche soit enseignée, en tout cas elle ne l’était pas dans les années 80.
La réaction de yahiko illustre bien l’incompréhension de ma démarche. L’apprentissage procédural demande du temps. Ensuite, l’acquisition des automatismes s’entretient et se bonifie. Lorsque je parle d’affiner mon environnement de développement, il ne s’agit pas seulement des seuls développements mais également de ma mémoire procédurale. Je dois corréler mon nouveau langage avec les automatismes déjà « imprimés » sur mon petit disque dur, notamment ma démarche algorithmique. Et cela demande beaucoup de concentration, la volonté de trouver le meilleurs compromis.…/… Je ne pense pas qu'il soit nécessaire de gaspiller un mois de temps de développeur pour concevoir un environnement de développement à chaque nouveau langage appris.
Ainsi, le compilateur « ace » d’Informix ne nécessite pas de programmer les lectures et ne propose pas d’instruction « GO TO » ni « PERFORM ». Cela impose de s’adapter, d’utiliser des instructions de substitution. La démarche ne gaspille pas de temps de développement, le temps ne s’arrête pas, le nouvel environnement se construit en pratiquant le nouveau langage.
Structure d’accueil, canevas, squelette ou skin :
La structure d’accueil ci-après est en fait un programme tout-à-fait opérationnel, sans doute le plus minimaliste des programmes de l’application, déjà évoqué dans le Billet « Manuel utilisateur ».
Les informations « ACE », « Objet » et « Date » correspondent aux informations de l’IDENTIFICATION DIVISION du COBOL. Contrairement au COBOL, ces informations ne sont que des commentaires mais ont une certaine importance, surtout dans leur forme. La raison, c’est qu’avec une seule instruction unix, il est possible de créer un fichier de toutes les lignes « Objet » des programmes d’édition, par exemple, d’éditer le fichier créé pour alimenter par une requête SQL, une table spécifique dédiée à la gestion d’un atelier de génie logiciel.
Les clauses « BEFORE GROUP », « ON EVERY ROW » et « AFTER GROUP » ne sont rien d’autres que les « DÉBUT TRAITEMENT », « TRAITEMENT » et « FIN TRAITEMENT » de la structure itérative d’un algorithme LCP.
Les clauses « BEFORE GROUP » et « AFTER GROUP » sont ici en commentaires. Les structures itératives se déduisent de la clause « ORDER BY », laquelle figure également en commentaire dans ce petit programme.
Skin
■ Formulaires
Les démarches administratives des particuliers se font soit par internet, soit via un formulaire CERFA, c’est-à-dire un imprimé officiel dont le modèle est fixé par arrêté et téléchargeable en ligne sous forme de fichier PDF à imprimer puis à remplir. L'appellation "CERFA" provient du nom de l'organisme public chargé d'éditer ces formulaires : le centre d'enregistrement et de révision des formulaires administratifs (CERFA).
Dans une administration, il n’existe pas d’entité spécialisée dans la conception des états ou formulaires servant à la communication interne voire avec d’autres administrations. Certains de ces états peuvent être de véritables pièces comptables.
Le développeur est force de proposition et dans une démarche d’informatisation de type bottom-up, donc en situation d’urgence, il doit être performant, pertinent, administratif. Un programme d’édition se réalise entre quelques heures et quelques jours. L’état doit être soigné dans sa présentation, son orthographe, sa lisibilité, sa compréhension, etc.
Certains programmes d’édition peuvent être très complexes en termes de traitement d’informations fixes (tableaux, texte aligné/justifié, par exemple) et d’informations variables.
L’instruction « PRINT FILE "chemin_formulaire" » simplifie la programmation en traitant l’ensemble des informations fixes d’un état sous forme d’un fichier-formulaire imprimable.
Un simple traitement de texte mode caractère permet de créer sous MS/DOS un tel formulaire de qualité bureautique très convenable qui peut d’ailleurs éviter dans certains cas l’utilisation d’un pré-imprimé. Imprimer avec Informix des tableaux complexes, du texte aligné/justifié en différentes polices de tailles différentes, en variant l’interligne… devient facile.
SPRINT 1.5
Sprint a été le dernier traitement de texte en mode caractère des années 80. Il était capable d’imiter 4 ou 5 traitements de texte dont Word. Borland l’appelait « Le traitement de traitement de texte ». L’apparition du WYSIWYG l’a vite condamné.
Sa fonctionnalité géniale est de produire un fichier source « .prn » en langage HP PCL 5, éditable par lui-même. Il suffit d’ajouter une commande PCL 5 « Mémorisation de la position du curseur » en début de fichier puis de remplacer les deux dernières commandes « Saut de page » et « Initialisation de l’imprimante » par une commande « Rappel de la position du curseur » pour transformer le source en formulaire utilisable sous Unix.
- Sous MS/DOS : Tout d’abord, il faut ajouter un Carriage-return à la fin de chaque ligne du fichier .prn car sinon le fichier transféré sous Unix ne fera qu’un seul item. Il peut alors dépasser la taille maxi et surtout il devient ingérable sous l’éditeur Vi. L’opération peut se faire de différentes façons, soit avec le traitement de texte lui-même qui joue alors le rôle d’un excellent éditeur de texte, soit en convertissant le fichier MS/DOS en fichier Unix (en deux clics avec Notepad++).
- Sous MS/DOS ou Unix : Il convient d’intervenir en début de fichier pour dire à l’imprimante de mémoriser la position du curseur « [Esc]&f0S » et lui signifier un interligne nul « [Esc]&l0C » de façon à annihiler les Carriage-return ajoutés qui se traduiraient par des sauts de ligne. Les sauts de ligne sont déjà assurés par des commandes PCL de mouvement de l’index vertical « [Esc]&a+nnV »
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 [Esc]&l8c0e69F[Esc]&aR9[Esc]&l0O[Esc]&l0C [Esc]&f0S(10U(s0p12h10v0s0b3T[Esc]&a+190V(10U(s0p12h10v0s0b3T[Esc]&a2820H╔(10U(s0p12h10v0s3b3TFournisseur[Esc] (10U(s0p12h10v0s0b3T══════════════════════════════════╗ [Esc]&a+20V(10U(s0p12h10v0s0b3T [Esc]&a266H(10U(s1p14v0s0b4148TXXXXXXXXXXXXXXXXXXX [Esc]&a+80V(10U(s1p14v0s0b4148T[Esc]&a2820H(10U(s0p12h10v0s0b3T║[Esc]&a5580H║ [Esc]&a+60V(10U(s0p12h10v0s0b3T …/…- Toujours sous MS/DOS ou Unix : Il reste en fin de fichier à remplacer les commandes PCL de saut de page et réinitialisation de l’imprimante (générées par le traitement de texte) par la commande « Rappel de la position du curseur « [Esc]&f1S ».
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 …/… [Esc]&f1S
Après l’exécution de l’instruction « PRINT FILE "chemin_formulaire" », le formulaire est donc imprimé et le curseur de l’imprimante repositionné au point d’origine du formulaire. Il ne reste plus au programme qu’à imprimer les variables éventuellement mises en forme par quelques commandes PCL de base (gras, italique, souligné, etc.) et pourquoi pas, à apporter quelques raffinements esthétiques simples grâce au langage GPL/2, comme griser ou encadrer une zone de texte.
Le principe peut bien sûr se sophistiquer pour imprimer en recto-verso sur format A4 ou A3.
Exemple de formulaire créé avec Sprint 1.5
Les caractères Escape (Alt/027) qui ne se voient pas ont été remplacés par « [Esc] » :
■ Commandes HP PCL 5 et GPL/2
Petit mémo du langage HP PCL 5 :
3. Les shells
■ Adoption d'un standard
Adopter un affichage standard comprenant :
- La liste commentée des paramètres à renseigner
- L’affichage éventuel d’un commentaire pour les gestionnaires
- La saisie des paramètres
- L’éventuel SQL sollicité en commentaire
# Le signe typographique croisillon « # » (appelé hash en anglais) indique que le texte qui suit est du commentaire.
■ Exemple de shell invoqué via un item du menu ou depuis le prompt
L’affichage du shell pour les gestionnaires ne se fait que sur 73 caractères sur les 80 possibles car la commande d’affichage d’une ligne prend 7 caractères : « echo "" ». Afficher une ligne de 80 caractères pour les gestionnaires pénaliserait le développement en affichant chaque ligne de 80 + 7 caractères sur deux lignes… Trop compliqué à gérer.
■ Exemple de shell avec une fonction récursive
Il s’agit de la convocation de stagiaires par mailing. La fonction s’exécute autant de fois qu’il y a de stagiaires inscrits au stage.
Outre sa fonction récursive, ce shell est un exemple réel d’utilisation des deux logiciels pcl2pdf et mutt. Ces deux logiciels sont décrits dans le Billet « Environnement de Développement Intégré (EDI) »
Les convocations sont envoyées par courriel au secrétariat de l’établissement dont dépendent les stagiaires. À charge au secrétariat d’imprimer ces convocations et au chef d’établissement de les signer puis de les transmettre aux intéressés.
4. Le système de menus
5. Beauté du logiciel
Ole Lensmar évoque la beauté du logiciel mais cette beauté n’a pas seulement un sens esthétique, ergonomique et convivial :
- c’est cette complicité, cette osmose constructive entre utilisateur et développeur,
- c’est cette écoute, cette attention du développeur à l’égard de l’utilisateur,
- c’est cette pulsion créatrice du développeur,
- c’est cette valeur ajoutée indicible que le développeur attentif crée :
- en synthétisant, en structurant le savoir-faire de l’utilisateur,
- en révélant le non-dit, en découvrant ce que l’utilisateur ne sait pas qu’il sait,
- en informatisant judicieusement les vrais besoins de l’utilisateur,
- en ouvrant de nouveaux horizons, en suscitant de nouveaux besoins,
- en comprenant les rouages de la problématique,
- en connectant des entités périphériques confinées dans leur bulle de compétences,
- en rendant l’utilisateur autonome,
- en faisant de l’outil un véritable support de formation au métier de l’utilisateur et non en réinventant son métier,
- en insufflant aux gestionnaires la confiance, l’optimisme, l’enthousiasme, la sérénité, la complicité, l’humour…
- en stimulant leur communication, leur imagination…
- c’est ce concentré invisible :
- de poulpe attitude (utiliser son intuition pour prendre les bonnes décisions),
- de positive attitude (vivre en mode chance, savoir lire la vie),
- d’impulse attitude (se mettre en danger pour être performant).
- de running attitude (Défier, s’adapter, maîtriser, être libre, autonome…)
Il n’existe pas de mot pour exprimer tout cela. Il faut seulement comprendre tout ce que recouvre le mot « beauté » ou utiliser plusieurs mots comme : sublime, ingénieux, inventif, pratique, pertinent, subtile, intelligent, judicieux, etc.
Ole Lensmar dit encore : « Une exigence clé pour créer une belle application est une véritable vision du produit, nourrie par son créateur, le propriétaire du produit et l'équipe produit, et cela ne peut pas être exprimé dans un carnet de commandes ou traduit par une expression de besoins des utilisateurs ». Le développeur doit aimer ses utilisateurs et investir dans leur interaction avec le logiciel.
Cette valeur ajoutée qui émane de la perception de l’indicible, suppose une vision élargie, débridée, disponible, de la problématique à informatiser. Et cette valeur ajoutée peut fort bien se concrétiser par autre chose que du code source, comme par exemple la refonte d’un document administratif, un changement de procédure, etc.
Comprendre les rouages d’une problématique, structurer le savoir-faire de l’utilisateur, découvrir ce qu’il ne sait pas qu’il sait, saisir une opportunité, exploiter une coïncidence, faire communiquer les entités administratives entre-elles, inventer « en live » avec la participation des gestionnaires une solution informatisée, tout cela procure bien des satisfactions. Cela n’exclue pas de réaliser… de beaux programmes mais c’est une autre histoire.
1ère anecdote :
2ème anecdote :
3ème anecdote :
L’aspect technique est une composante de la qualité de la communication mais ce n’est pas la plus importante, l'ergonomie et la convivialité sont l'art et la manière de savoir composer (signifiant) et transmettre (signifié) qui se manifestent dans toutes les composantes perceptibles par l'utilisateur :
- les écrans,
- les shells,
- les états,
- le système de menus.
Le logiciel doit être agréable, intuitif et facile d’utilisation.
Il y a lieu de différencier le "signifié" du "signifiant", le "signifié" désigne la représentation mentale du concept associé au signe, tandis que le "signifiant" désigne la représentation mentale de la forme et de l'aspect matériel du signe.
De même qu’en linguistique, le signifié et le signifiant sont les deux faces complémentaires du concept de signe linguistique, la convivialité et l’ergonomie sont les deux faces complémentaires du concept d’écran. La convivialité sollicite la compréhension, l’ergonomie sollicite l’utilisation.
Les bonnes pratiques de programmation
▲ I-2.2.1. Règles de nommage
► I-2.2.2. Règles de développement
▼ I-2.2.3. Méthodologie de programmation LCP