Je ne suis pas développeur, c’est un métier que je n’ai pas appris et bien que connaissant certains langages, je ne me lancerais pas dans l’écriture d’autre chose que de petits scripts.
Mais je gère des parcs de PC, et la je dois dire que parfois certains développeurs me font souffrir ou hurler !!
Alors voici 12 choses à ne jamais faire pour un développeur, suivi d’explications :
- Je ne fournis pas de programme d’installation, il suffit de copier les fichiers
- Pour fonctionner correctement mon programme à besoin de tel composant, mais je ne vous dit pas ou le trouver (google est votre ami…)
- Si vous voulez que mon programme fonctionne bien vous devez être administrateur
- Mon programme n’utilise pas le registre, les fichiers ini, c’est mieux
- Sans vous le dire, mon programme modifie des DLL de Windows, mais c’est sans conséquences
- J’ai glissé un add on qui est une beta avec mon programme, mais ça marche
- Mon programme ne fonctionne que avec une version d’Internet Explorer, ou Adobe Reader ou Word
- Mon programme utilise un dongle pour éviter le piratage ou mon programme nécessite une activation, et n’en supporte qu’une seule
- Mon programme doit s’installer à la racine, pas dans Programmes Files (ou en tous cas le fait par défaut)
- Mon programme enregistre des données dans le répertoire ou il est installé, c’est plus simple
- Mon programme a été traduit en Français par un sous traitant, mot, pour mot, ça suffit…
- Mon programme est fourni sans fichier ADMX ou possibilité de stratégie, pas besoin
Il y en a surement d’autres, je fais confiance aux développeurs en la matière, ces développeurs à qui j’aurais envie de dire : avant d’écrire un programme pour Windows, apprenez le fonctionnement de Windows et les best practice qui vont avec (au lieu de dire, Windows c’est plein de bugs… Linux c’est mieux… trop souvent entendu).
Voici quelques explications :
1 – Importance d’un programme d’installation
Non, un programme d’installation ne se contente pas de copier les fichiers dans le bon répertoire :
- il place les fichiers dans le bon répertoire, avec les bons droits
- il enregistre les DLL dans le système
- il rends le programme visible dans Ajout Suppression de programmes (sinon comment savoir quel PC contient quel logiciel ?)
- il provoque les bonnes élévations de privilège pour que tout cela fonctionne
- il fournit un fichier log, en cas de problèmes
- il fait surement encore d’autres choses que j’ignore
- et il réalise le tout : toujours de la même manière, reproductible et fiable
2 – Votre programme nécessite des pré requis, identifiez les !!
J’ai passé tellement de temps à chercher tel ou tel version de .NET (jamais la même), ou de runtime, rien de plus énervant, pourquoi ne pas fournir un lien vers une page référençant les sources pour ces add-ons ?
3 – Le danger de l’utilisateur administrateur
Le complexe d’infériorité ! Aucun programme ne doit avoir besoin de privilège élevés pour fonctionner, cela est trop dangereux !
Microsoft a dépensé des millions de dollars pour sécuriser Windows, il y a des (bonnes) raisons : éviter les risques d’infection du système, les erreurs utilisateurs, les application malveillantes, protéger votre système et vos données. Ne gâchez pas tout en décrédibilisant votre application…
4 – Découverte de la base de registre
Si vous êtes développeur pour Windows et que vous ne connaissez pas le registre, passez votre tour…
Le registre est à la fois génial et horrible, flexible et rigide, fiable et capricieux. En fait c’est un super outil qui permet à plusieurs utilisateurs de coexister sur un même PC, à votre application d’être utilisée sur de nombreux systèmes différents, aux utilisateurs de changer de PC aisément, en gros d’utiliser Windows comme il a été prévu.
Par contre mal utilisé, maintenu ou mis à mal par des applications tordues, le registre peut vite devenir un problème.
Microsoft à inventé le Registre avec Windows 3, il a été énormément amélioré, reste surement perfectible mais à vraiment fait ses preuves et lorsque vous en avez compris le fonctionnement, vous serez un expert de Windows.
Lisez cette page, vous en saurez déjà pas mal : http://www.toutwindows.com/vista_registre.shtml
5 – A quoi sert une DLL ?
Je ne suis pas développeur, mais le principe est simple : une DLL offre des fonctions (du code) qui peut être être appelé par un programme. Et pour rendre les choses plus modulables il est souvent plus aisé d’externaliser certaines fonction d’un programme (les enlever du fichier .EXE ) et de les mettre dans une DLL (ou tout autre fichier partagé). L’autre avantage d’une DLL est que les fonctions de celle-ci peuvent être utilisées par plusieurs programmes.
Nous y sommes !! Voila le cœur du problème !
Microsoft fournit un service dans une DLL v1.0, puis v1.1, 1.2 etc etc. L’auteur d’un programme à besoin de la v1.2, alors que fait il ? Il copie bêtement la nouvelle version dans un répertoire partagé de Windows (system32, par exemple).
Tout ceci vous parait logique mais ce n’est pas si simple : si entre temps une mise à jour à déjà installé la v1.3 ou la v2, alors patatras tout s’écroule.
Autre variante, au lieu de vérifier et éventuellement mettre à jour la DLL v1.2 est copié dans le même répertoire que le programme, qui pourra alors l’appeler ! Sauf si au même moment un autre programme a déjà rechargé cette DLL en mémoire, re patatras !
Rassurez vous cependant Microsoft déploie des modèles d’ingéniosité pour que tout ceci n’aboutisse pas à un désastre, surtout si ces opérations sont effectuées par un programme d’installation… (cf point 1).
6 – Une beta c’est quoi ?
Les éditeurs, Microsoft en tête, rendent de plus en plus disponible les versions beta de leur programme, cela m’attriste beaucoup !
Alors, qu’est ce qu’une beta :
Un “brouillon” de programme, une version préliminaire.
Une beta ne doit pas être installé sans compétences techniques car une fois installée, elle pourra (je dirais presque devra) nécessiter la réinstallation du Windows l’hébergeant. Elle peut aussi engendrer des plantages, des pertes de données, des problèmes de sécurité, etc etc
Donc amis développeurs, fournisseurs, éditeurs ne fournissez jamais une beta avec vos produits, encore moins sans le dire, cela révèle de l’amateurisme et de la malhonnêteté.
beta = test = plantages = rien à faire sur un PC de production ou contenant des données
Cliquez sur le lien ci-dessous pour la suite :
Continue reading Les 12 commandements d’un administrateur de parc pour un développeur
