Introduction à la programmation informatique

Bernard Amade

Chapitre 1. Qu’est-ce qu’un programme ?

1.1. Un exemple du degré zero

texte

1.2. Plus sophistiqué

texte

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.4. Qu’est-ce qu’un programme? Premières approximations …

texte

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!

Table of contents

previous page start next page