Est-il acceptable d'utiliser une langue qui n'est pas prise en charge par votre entreprise pour certaines tâches?

Je travaille pour une entreprise qui prend en charge plusieurs langages: COBOL, VB6, C # et Java.
J'utilise ces langages pour mon travail principal, mais je me retrouve souvent à coder certains programmes mineurs (par exemple des scripts) en Python parce que je l'ai trouvé être le meilleur outil pour ce type de tâche.

Par exemple: un analyste me donne un fichier CSV complexe pour remplir certaines tables de base de données, donc j'utiliserais Python pour l'analyser et créer un script de base de données.

Quel est le problème?
Le principal problème que je vois est que quelques parties de ces scripts rapides et sales gagnent lentement en importance et:

1. Mon entreprise ne prend pas en charge Python
2. Ils ne sont pas contrôlés par la version (je les sauvegarde d'une autre manière)
3. Mes collègues ne connaissent pas Python

Les analystes ont même commencé à les référencer par e-mail ("lancer le script qui exporte ..."), donc ils sont nécessaires plus souvent que je ne le pensais au départ.

Je dois ajouter que ces scripts ne sont que des utilitaires qui ne font pas partie du projet principal; ils aident simplement à accomplir des tâches triviales en moins de temps. Pour mes propres petites tâches, ils aident beaucoup.

En bref, si j'étais un gagnant de loterie pour être dans un accident , mes collègues auraient besoin de maintenir le projet en vie sans ces scripts; ils passeraient plus de temps à corriger les erreurs CSV à la main par exemple.

Est-ce un scénario courant? Est-ce que je fais quelque chose de mal? Que devrais-je faire?

Vous devez officialiser la situation car elle ne devrait pas vraiment en être arrivée là. Cependant, ces choses se produisent, vous devez donc expliquer à votre patron que vous avez créé ces scripts pour un usage personnel, mais ils se sont "échappés" dans une diffusion plus large. Reconnaissez (si nécessaire) que vous étiez en faute de ne pas l'avoir signalé plus tôt.

À tout le moins, les scripts doivent être placés sous contrôle de code source "juste au cas où" - alors au moins si vous n'êtes pas disponible (pour une raison quelconque), vos collègues auront accès aux scripts.

Ensuite, vous devez soit convaincre votre patron que Python est la voie à suivre pour ces derniers, soit accepter que vous devrez les réécrire dans un langage pris en charge. Si le coût de la documentation des scripts et de la formation de vos collègues en Python est inférieur à celui de la réécriture, vous pourriez même gagner l'argument.

Je ne peux pas vous donner une réponse complète à ce que vous devez faire. Je ne peux donner qu'une seule suggestion que vous pouvez utiliser pour commencer:

Archivez les scripts dans un référentiel auquel tous les développeurs (requis) peuvent accéder. Mais assurez-vous de noter que vous avez d'abord écrit ces scripts pour votre propre but, c'est-à-dire pour effectuer une tâche qui vous a été confiée. Ajoutez ensuite que vous archivez uniquement ces scripts pour permettre aux autres de les utiliser.

Après cela, vous aurez juste besoin de voir comment les autres personnes réagissent à cela.

J'ai rencontré des problèmes similaires là où je travaille. J'ai entendu "Qu'est-ce que PHP?" il y a plusieurs années. Ils ne comprennent ni ne veulent rien apprendre en dehors de la pile MS. Si python est le bon outil pour le travail, j'en parlerais à mes superviseurs et je serais prêt à faire beaucoup de comparaison et à expliquer pourquoi python était le bon choix. Ce sera frustrant, mais je pense que la plupart conviendront que le python est un bon choix pour la manipulation de texte.

La première chose que vous devez faire est de parler avec l'équipe et votre patron. À l'heure actuelle, vous avez un énorme facteur de camion (si vous vous faites heurter par un camion, personne d'autre ne pourrait facilement maintenir vos scripts). Il semble que la possession de scripts pour effectuer ces tâches soit importante, mais il est également important que quiconque en ait besoin puisse modifier et maintenir ces scripts. Vous devez expliquer comment l'utilisation de Python ajoute de la valeur - comment elle permet d'économiser du temps, des efforts, des ressources, de l'argent, etc.

Deuxièmement, mettez-le dans le contrôle de version du projet. À présent. Rien de ce que vous produisez pour un projet ne doit jamais être en dehors du contrôle de version de ce projet.

Soyez prêt à réagir - les gens n'aiment généralement pas le changement. Se lancer seul, utiliser des technologies non prises en charge et inconnues (pour l'équipe / l'organisation) était une mauvaise idée, sans consulter au moins les autres développeurs et déterminer la meilleure façon (pour le projet, pas seulement vous) d'automatiser ces tâches pour tout le monde utiliser.

Je pense que c'est probablement un bon cas de

Il est plus facile de demander pardon que d'obtenir la permission.

Il semble que vous ayez fait le travail, mais vous allez devoir faire face aux répercussions maintenant.

Ma règle d'or est la suivante:

Tout ce qui peut avoir un impact sur le travail des autres doit être discuté avec vos pairs et vos supérieurs dès que possible.

Mais, si c'est pour vous et pour vous seul, tant que cela n'endommage pas l'infrastructure ou la sécurité de votre entreprise , vous êtes libre de faire ce que vous voulez pour faire le travail.

Vous avez deux options:

1. Faites-en un standard
2. Traduire en un outil standard

Selon l'organisation # 1 pourrait être difficile (après tout, limiter la liste des technologies standard évite une explosion combinatoire des exigences de formation et de soutien).

La deuxième option aiderait votre ensemble de compétences, et vous pourriez être en mesure de trouver des tiers (et probablement open source avec des licences commerciales) pour effectuer une partie du travail acharné. Par exemple, une recherche de "LINQ to CSV" devrait obtenir des résultats utiles.

BTW, les outils de développement de VB6 (IDE, compilateur) ne sont pas pris en charge (pas même les correctifs de sécurité), il est donc probable que la norme doive de toute façon être mise à jour. (Le runtime VB6 est pris en charge dans le cadre des versions Windows actuelles et inclus dans l'installation). Cela pourrait peut-être être utilisé comme une aide pour l'approche n ° 1: l'ensemble d'outils standard doit augmenter une cible mobile en raison des dépendances des fournisseurs.

Si on vous confie une tâche et que c'est la seule façon de l'accomplir à temps, vous n'avez pas vraiment le choix. Je pense qu'il est sage de faire savoir aux responsables ce que vous faites. Vous ne devez pas sortir du contrôle de source requis (à moins qu'il ne fonctionne absolument pas du tout?) Des tests et de la documentation.

Parfois, une entreprise peut devoir laisser un seul développeur commencer à explorer un nouveau domaine de développement. Malheureusement, le code peut arriver en production plus rapidement que quiconque ne peut le faire.

Eh bien, je dois admettre que travailler avec 20 langues différentes pue beaucoup.

Vous avez un script Bash qui appelle un script Python qui appelle un script Perl qui appelle un binaire Java qui appelle C dll ...

Puis quelque chose frappe le ventilateur dans tout le pipeline, et vous passez par - WTH IS DAT KODEZ? Surtout en Perl ... Et le débogage simple, disons, problème de codage, se transforme en un cauchemar cauchemardesque. Vous ne pouvez pas déboguer efficacement 5 langues sur 7, et cela devient une véritable douleur.

Ou vous devez ajouter un simple changement, mais vous créez 10 erreurs car Perl a des accrochages, Java a des accrochages, etc.

Et cette chaîne de langues 7+ commence une étape à la fois.

Soyez prudent, voici des dragons ...

Si ce sont des outils que vous utilisez vous-même, vous êtes libre de faire tout ce qui vous rend plus productif.

En fait, vous devriez être encouragé à fabriquer et à utiliser de tels outils, qui deviendront finalement une extension de vos bras.

Finalement, ils reconnaîtront l'importance d'avoir de tels outils, quelle que soit la langue dans laquelle ils sont écrits , et commenceront à les mettre en œuvre dans leur environnement de travail.

Quand on vous dit d'écrire du code en faisant qc, le langage est généralement spécifié ou implicite (la règle dans les sociétés).

Mais lorsque vous devez effectuer une tâche ponctuelle, comme importer des données dans la base de données, vous êtes libre de choisir l'outil qui, à votre avis, convient le mieux, car vous devez faire quelque chose de correct et rapide, et le résultat est important, pas les outils.

Donc, j'utiliserais cette règle:

1) Si on vous dit de faire une tâche, telle que l'importation de données, j'utiliserais les outils / langue / etc. ce serait le plus pratique pour moi et le plus rapide pour la tâche.

2) Si l'on vous dit d'écrire un outil effectuant une tâche, telle que l'importation de certaines données, je discuterais de la langue / de l'outil à utiliser avec le gestionnaire (à l'exception lorsque j'utilise un langage implicite standard, par exemple lorsque l'entreprise utilise [presque ] uniquement Java).

3) Si la tâche semblait être ponctuelle, mais qu'elle devenait répétable, vous devriez parler avec le gestionnaire pour la changer de 1) à 2) et réécrire de votre langue préférée à celle prise en charge par l'entreprise.

Je suppose que vous n'êtes pas en mesure de décider (sinon vous ne poseriez pas la question). Que pense votre patron de ce problème? Vous devriez lui parler et essayer de le convaincre que Python est la voie à suivre ...

Bien sûr, la question est de savoir ce qui se passera lorsque vous partirez. Ne pas pouvoir maintenir le code est probablement une raison suffisante pour arrêter d'utiliser Python. Ou vous pouvez commencer à éduquer vos collègues à cette langue ...