Reprendre une ancienne base FileMaker (1)

La semaine dernière, je vous présentais une petite vidéo postée par FileMaker sur les « développeurs-autodidactes ».

J’en ai alors profité pour développer un peu ce que cette appellation sous-entend, la comparant à une autre expression, toujours de FileMaker, les « développeurs-citoyens ». J’y ai ajouté celle qu’à Editomac, nous préférons : les « personnes-ressources FileMaker »…

Et voilà que Bertrand, en commentant cet article, en ajoute une quatrième : les « apprenti-sorciers » 😉

Bon, je ne pense pas qu’il souhaitait l’additionner aux trois autres, mais c’est un fait qu’une personne mal préparée au développement logiciel peut jouer le rôle d’ « apprenti-sorcier » avec toutes les conséquences que l’on peut aisément imaginer.

Mais le problème qu’évoquait Bertrand n’est pas uniquement lié aux compétences du développeur occasionnel, même si celles-ci sont bien entendu requises…

Pour comprendre ce qu’il en est, essayons d’analyser un peu les choses.

Bertrand se trouve face à une solution développée il y a quelques temps, voire plusieurs années, solution mal conçue et dont il ne sait que faire : faut-il l’actualiser ou la reprendre complètement à zéro ?

Il n’existe pas de réponse a priori et je ne répondrais donc pas à la place de Bertrand.

Je voudrais juste nuancer le propos de Bertrand concernant le savoir-faire du développeur, en restituant les choses dans un contexte historique plus large.

Nous sommes en 2017 et pour ma part, je connais FileMaker depuis 1991. Cela fait donc 26 ans : une éternité dans la vie de l’informatique et surtout au rythme où les choses vont…

Dans le cas d’une reprise d’une solution existante, surtout si cette solution est très ancienne, les difficultés d’adaptation à un contexte actuel sont liées à plusieurs facteurs. Je m’intéresse aujourd’hui à celui concernant l’évolution de FileMaker.

Au fil des versions, FileMaker a gagné en puissance et nous a apporté de nombreuses fonctionnalités. Prenons un exemple très simple. Dans les fiches Astuces 111 et 112, je vous propose toute une astuce pour trier à la volée une table externe, ce que FileMaker ne permet pas de faire par défaut. Dans ces fiches, je prends la peine d’expliquer des variantes pour chacune des versions 12, 13 et 14 en fonction de leurs possibilités respectives. Par exemple, pour masquer un objet, il faut toute une procédure tant que cette option n’est pas proposée par FileMaker. Lorsqu’elle l’est, à partir de la version 13, alors masquer un objet devient un jeu d’enfant !

On va donc, dans ce cas, vers une simplification. Si une base développée en FileMaker 12 est utilisée dans une version plus récente, tout ce processus qui était nécessaire, devient trop lourd et inutile, on a tout intérêt à la remplacer par l’option apparue depuis.

Dans le sens inverse, une nouveauté, qui représente un réel apport, devient un surcroît de complexité. Par exemple, l’apparition de la barre de boutons simplifie certes la copie des boutons d’un modèle à l’autre. Mais elle apporte aussi de la complexité par toutes les possibilités qu’elle draine avec elle : gestion des segments et divers éléments de la barre des boutons, états des segments, calcul pour déterminer quel est le segment actif, etc.

Un jour, dans la version N… de FileMaker, peut-être que le tri à la volée des tables externes sera proposé par défaut par FileMaker. Dans la définition de la table externe, il sera peut-être possible de créer un tri par calcul, comme il est possible désormais de masquer un objet de modèle. Dans ce cas, tout ce que nous avons imaginé, toutes les solutions que nous avons mises en place dans les fiches Astuces n°109 à 112 deviendront d’un coup caduques !

À Editomac, dans les années 90, nous avions dans l’équipe un excellent développeur. Il a développé des solutions inimaginables pour l’époque, faisant preuve d’une ingéniosité hors du commun pour pallier aux insuffisances du FileMaker d’alors, et notamment au manque de relationnel… Nous sommes maintenant confrontés au problème de la reprise de ces solutions. Et pourtant, ses compétences ne sont en rien remises en cause.

Dans notre travail, nous sommes très dépendants des décisions techniques prises par les éditeurs de logiciels ou de systèmes d’exploitation. Ils ne nous demandent généralement pas notre avis… ou si peu… À nous donc de nous adapter. Mais si votre solution FileMaker est trop ancienne et qu’elle a besoin d’être réactualisée, un bon conseil : demandez-nous notre avis ! Car vous n’apprendrez pas dans les livres ce que l’expérience et la formation spécialisée en informatique nous a appris en 20 ans de vie avec FileMaker. Et nous ne vous l’apprendrons pas non plus, car nous n’aimons pas transmettre ce qui ne servirait qu’une seule fois 😉

Marie-Charlotte Potton

 

Article suivant : à venir

Tags: ,

Merci de laisser un commentaire (déjà 2 commentaires )

Désolé, les commentaires des articles réservés sont eux-mêmes réservés


  1. Bertrand
    7 ans ago

    Merci Marie-Charlotte d’avoir pris en compte ma réaction.

    Dans la solution dont je parlais, il n’y a que 11 bases différentes, 94 tables, 5343 rubriques, 289 listes de valeurs, 629 modèles, 1561 scripts et 360 liens entres les 11 bases. Dans les 11 bases, j’ai trouvé 43 tables complètement inutilisées et des tables dupliquées mais avec un nombre de rubriques différentes, de l’ordre de + ou – 10%.

    A mon avis on doit pouvoir largement faire mieux et alléger cet ensemble.