1.3. Programmation "périphérique" §§
Autour du "coeur de métier" on peut trouver des codes pour :
-
les interactions "directes" avec l’utilisateur: saisies, interfaces graphiques, courbes,…
-
les accès à l’administration, la gestion des droits
-
les systèmes de persistance : fichiers, bases de données
-
les interactions en réseau , client/serveur, etc…
-
…
Point important à ne pas perdre de vue: ne pas mélanger ces différentes couches logicielles!
(Exemple: un code qui réalise les saisies passera ensuite ces données à un autre code qui les traitera. Un mélange
des deux est, dans la plupart des cas, une violation de la modularité - ce point sera repris plus tard.)
Qu’est ce qui nous permet de réaliser ces codes?
-
bibliothèques de codes: livrées avec le langage, tierces parties (standard, produits,…), codes internes à l’organisation (codes spécifiques ou codes généralistes non liés à une application particulière)
-
services "câblés" dans le langage et paradigmes (en gros: manières de formaliser les problèmes)
1.5. Qu’est-ce qu’un programme? Premières règles … §§
Il existe des cas où le programmeur réalise rapidement un "code à jeter" qui va lui permettre de rechercher un résultat unique
ou de prouver un concept. Mais ce n’est pas le cas le plus courant: un programme est fait pour durer.
Outre le fait que le programme doive exécuter des tâches précises sans commettre d’erreur, dans un temps raisonnable, sans épuiser des ressources …
il y a d’autres éléments constitutifs de la qualité intrinsèque d’un code.
-
Le code doit être "lisible". Clair, explicite, bien documenté: il permet la relecture par d’autres programmeurs (et aussi par l’auteur qui a oublié depuis longtemps
les détails de ce qu’il a écrit!)
-
Le code doit être ciblé: faire des choses précises et bien délimitées (les programmeurs disent souvent qu’un code "ne doit faire qu’une seule chose … et encore!").
Toujours pour la même raison: un code avec un objectif clair et bien délimité est plus facile à maintenir.
-
L’application doit être modulaire. C’est un corollaire des recommandations précédentes: une application facile à maintenir (et à "déboguer"!) est constituée
de petits éléments qui communiquent entre eux. Ces éléments sont généralement écrits pas des programmeurs différents. Cette notion
d'équipe de programmation est fondamentale!