Discussion :

[Pierre Fauconnier]

quand c'est bien codé avec des petits fonctions ca va encore .si le contenu d'un sub est long le risque de trouver le bug en question est galère non?

Un principe de programmation: Une fonction = UNE ET UNE SEULE responsabilité...

En respectant cette règle de base, tu ne saurais pas avoir de "sub long"...

Comme le dit unparia, le problème, c'est l'interface entre le dossier et le clavier.

Et il y a moyen de créer de vraies applications en VBA avec Excel. Cela ne dépend pas du nombre de lignes de codes, ce paramètre n'entrant pour moi pas en ligne de compte pour qualifier un développement de professionnel ou non. J'ai développé de véritables applications en VBA avec Excel, avec de la gestion de données, maintenables, distribuables, réutilisables. Ce n'est pas le langage qui fait qu'une application plante ou pas. Ces développements gèrent les non-conformités, le risque d'accident de travail ou le risque environnemental et permettent aux sociétés qui les utilisent d'être certifiées ISO. Le "professionnel" ne dépend donc ni du langage ni de l'outil qui supporte ce langage.

Comparer VBA/EXCEL ou VBA/ACCESS avec PHP/MySQL n'a pour moi aucun sens, ne serait-ce déjà que parce que php/Mysql sera utilisé pour développer des applications WEB et donc, la finalité technique n'est pas la même.

Mais personnellement, je ne réduirais pas VBA/EXCEL à des "petits" développements ou à des applications "personnelles", parce que ces termes sont à définir et que pour pouvoir en débattre, il faudrait tomber d'accord sur une définition commune, restreinte au cercle des participants à cette discussion, de ces termes tels que "professionnel", "petite", "application", "personnelle"...

Bref, un débat souvent vain parce qu'il participe plus de la volonté de convaincre que de partager.

[Invité]

Si je devais te rejoindre sur un point ce serait sur la taille du code!

Non pas que vba ne permet pas de développement conséquent mais plus le code est tassé plus il est maintenable!

80% du temps est généralement consacré à l'analyse, le codage en lui même n'est pas un problème de langage de programmation mais de syntaxe lié à ce langage.

Je découpe ma problématique en fonctionnalité!

Je prend souvent l'exemple d'un vélo!

Il est composé d'une parti cadre,cycle et propulsion (chaine,pédalier,etc)

Chaque découpe de mon projet général devient une sous routine de mon projet en d'autre terme je factorise!

Une méthode ne doit rarement dépasser une dizaine de lignes!

J'ai une méthode qui gère mes classeurs; une qui gère les onglets d'un classeurs une autre qui gère un onglet! Et le tout interagi!

[clementmarcotte]

Bonjour,

Avec VBA, il y en a trop qui font l'ânerie de vouloir transformer Excel en Access. Comme s'il suffisait qu'un psychiatre dorme une nuit pour installer une prothèse de la hanche.

[Pierre Fauconnier]

[...]

Mwouais... On n'a pas toujours le choix des armes, pour de multiples raisons. Mon expérience m'a amené à être pragmatique et à développer en Excel de la gestion de données, simplement parce le client, après d'âpres discussions, voulait Excel et un seul fichier, et rien d'autre (même pas un mdb lié à Excel, juste une fichier xlsm). Et les raisons du client l'emportaient sur la volonté de mettre en place les bonnes techniques.

je ne suis pas sûr que ce soit toujours un choix "d'âne" que de vouloir (devoir) "refaire de l'Access" avec Excel... Bien sûr, tu peux aussi refuser le boulot et le laisser faire à d'autres "plus ânes" que toi. Tu peux aussi développer des outils +/- génériques pour gérer les données au sein du fichier Excel, en spécifiant au client les limitations d'un choix qui, in fine, reste le sien.

Et perso, j'ai pris du plaisir à développer un framework générique de gestion de données avec Excel, qui me permet de répondre rapidement à des besoins de clients qui font le choix d'Excel "pur et dur", à nouveau pour des questions qu'il ne m'appartient pas de juger ou de remettre en question...

Ne pas trop vite juger le travail ou le choix des autres par mon petit bout de lorgnette, c'est quelque chose qu'une expérience de plus de vingt ans d'indépendant en IT m'a permis d'apprendre...

[clementmarcotte]

Bonjour

Mwouais... On n'a pas toujours le choix des armes, pour de multiples raisons. Mon expérience m'a amené à être pragmatique et à développer en Excel de la gestion de données, simplement parce le client, après d'âpres discussions, voulait Excel et un seul fichier, et rien d'autre (même pas un mdb lié à Excel, juste une fichier xlsm). Et les raisons du client l'emportaient sur la volonté de mettre en place les bonnes techniques.

je ne suis pas sûr que ce soit toujours un choix "d'âne" que de vouloir (devoir) "refaire de l'Access" avec Excel... Bien sûr, tu peux aussi refuser le boulot et le laisser faire à d'autres "plus ânes" que toi. Tu peux aussi développer des outils +/- génériques pour gérer les données au sein du fichier Excel, en spécifiant au client les limitations d'un choix qui, in fine, reste le sien.

Et perso, j'ai pris du plaisir à développer un framework générique de gestion de données avec Excel, qui me permet de répondre rapidement à des besoins de clients qui font le choix d'Excel "pur et dur", à nouveau pour des questions qu'il ne m'appartient pas de juger ou de remettre en question...

Ah, c'es sûr que le client a toujours raison et qu'aucun développeur ne peut refuser d'exécuter la commande reçue.

Ne pas trop vite juger le travail ou le choix des autres par mon petit bout de lorgnette, c'est quelque chose qu'une expérience de plus de vingt ans d'indépendant en IT m'a permis d'apprendre...

Je ne peux pas de donner tort dans l'absolu. Mais j'avoue que là, ma formation de gestionnaire prend le dessus sur le reste. C'est vrai qu'Access, dans la mesure où il est, disons restreint, à une utilisation spécialisée, un peu comme Project, nous pourrions dire que cela semble faire hésiter beaucoup d'organisations. La plupart vont dire que c'est trop cher. Et, ils semblent croire que pour utiliser Access, il faille payer plus de formation que juste pour Excel. La vérité, c'est que la formation nécessaire, ce sont des bénévoles qui la dispensent sur des forums. Et grâce aux forums, il arrive qu'il soit possible de prévenir les gens qu'ils sont à deux pas du précipice.

Toujours avec ma vision de gestionnaire, il n'y a aucune économie à faire à vouloir transformer Excel en Access ou en Project, ou de transformer Word en Publisher. Les coûts pour juste implanter en VBA dans Excel ce qui existe déjà dans Access dépassent probablement déjà la différence de prix. Ils peuvent sans doute économiser un peu en engageant quelqu'un qui peut réutiliser son code pour économiser du temps, mais Excel ne peut pas gérer des fichiers aussi imposants que ceux qu'Access peut gérer. À toutes fins pratiques, l'utilisation d'Excel devient un frein à la croissance de l'entreprise.

Même que le Runtime d'Access permet de construire une application sur Access et de l'utiliser sur des postes sans Access.

Ce qui m'irrite le plus dans tout cela, c'est le refus de juste envisager des solutions gratuites de SGBD.

Visual Studio Community est gratuit, même pour utilisation commerciale, pour des individus et des boîtes d'au plus 5 programmeurs. Même qu'une grosse boîte peut utiliser VS Community gratuitement pour produire des applications dites "Open Source". Il inclut une version de base gratuite de SQL Server, et il est compatible avec Office Tools for Visual Studio, anciennement Visual Studio Tools For Office. Il y a aussi Microsoft SQL Server Express qui est gratuit et qui peut gérer des bases de 4 Go, ou peut-être même plus. Visual Studio peut également piloter Office à distance. À strictement parler, ce n'est pas par automation, nais c'est tout comme. Il faut quand même modifier un peu les noms d'objets, mais cela n'a rien d'un Calvaire. Même que Visual Studio .net peut écrire n'importe quel fichier compatible Open XML, directement sans passer par Automation. Même que pour Excel, Word et PowerPoint, il y a un SDK que MS a mis en Open Source. Même que VB.net (en fait tout langage .net), peut construire une base de données dans un fichier XML qui peut être enregistré sur disque, ou relu, avec une seule ligne de code.

Même si certains intervenants du Forum .net mettent en doute l'appellation SGBD, il y a MySQL.

Et il y a tous les Open et Libre Offices de ce monde.

C'est pour cela que je deviens rouge quand je vois passer dans le même message Excel et base de données

[Pierre Fauconnier]

Tout à fait, Robert...

Et plus on découpe le code en petites fonctions à responsabilité unique, plus on engrange des "briques logicielles" que l'on peut réutiliser dans d'autres projets.

Pour réaliser cela, éviter autant que possible les variables globales, éviter le hard coding, utiliser l'outil sur lequel on travaille plutôt que réinventer la roue (En VBA pour Excel, penser Excel avant de psner VBA permet souvent de s'éviter de pisser de code, d'avoir des fonctions optimisées et d'éviter les bugs, ...).

Et je garantis que l'on peut réaliser des applications sérieuses, professionnelles, maintenables et évolutives en VBA, et en VBA sur Excel...

[Pierre Fauconnier]

Clément,

Je te rejoins sur l'entièreté de ton analyse, mais dans la pratique, je la nuance en fonctions des outils qui seront utilisables. J'ai travaillé pour une grosse boîte disposant d'une équipe IT interne avec un DBA. Hors de question pour eux de m'ouvrir l'accès à leur sql server et hors de question d'utiliser Access. Hors de question également de developper en vsto car " ils perdraient le contrôle sur l'outil " malgré que je donnais le code source.

Jai donc développé en vba sur excel. Cest moins rapide, pas partageable et ils ont de toute façon perdu le contrôle de l'outil. "Mieux", ils se le sont fait piquer par un indélicat lorsqu'il a quitté la boite.

Il y a toujours du bon et du moins bon dans le choix des technos. Par pragmatisme et dans la mesure où j'en maitrise plusieurs, j'utilise celles qui constituent, à mon aune, le moins mauvais compromis possible.

😉

[Pierre Fauconnier]

Robert,

Ok. Mais à nouveau, c'est dans une certzine taille de boîte. J'ai comme clients des boites de trois personnes et des boites de 700 personnes avec plusieurs sites. Les demandes et les besoins ne sont pas les memes. Et paradoxalement, dans les grosses boites, les services fonctionnent parfois comme des pme distinctes.

Il nexiste donc pas Une configuration qui soit universelle.