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


27

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?


22
Si vos collègues ne peuvent pas comprendre un script simplement parce qu'il est dans une autre langue, vous avez de plus gros problèmes
CaffGeek

1
Je suis d'accord avec Chad. Python est aussi proche du pseudo-code que possible.
Job

2
@Chad eheh nice one mais le problème pourrait en être un autre; Python sdk ne fait pas partie de l'installation par défaut de la machine de développement. Afin de l'installer, j'ai payé beaucoup de cafés au bon administrateur système;).
systempuntoout

3
@systempuntoout, les développeurs devraient pouvoir installer ce qu'ils veulent sur leur ordinateur dans les limites légales. Donc, PowerShell est préinstallé sur Windoze et j'ai essayé de le remplacer par Python, mais ce n'est pas la même chose. Les cas de bord me giflent au visage chaque fois que j'essaie de faire quelque chose de simple. Python fait simplement avancer les choses et si les drones d'entreprise ne le font pas - tant pis!
Job

1
Mettez-les en contrôle de source. Juste un petit coin quelque part, mais mettez-les dedans.

Réponses:


42

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.


8
+1, d'accord. Je peux voir comment ce genre de chose peut très facilement se produire, mais ce n'est pas nécessairement "une mauvaise chose" ou "une erreur" de la part du PO. Cela a probablement commencé lorsque le PO a été chargé d'un mini-projet "unique" et il a choisi un bon outil, python, pour nettoyer rapidement son bureau du projet - mais s'est ensuite retrouvé à exécuter la tâche encore et encore ...
Angelo

Je vis ça maintenant. J'ai piraté une preuve de concept en Python pour m'aider à comprendre un vieux code C merdique, et j'ai réussi à faire fonctionner tout le désordre en remplacement de l'ancien code C, mais on m'a demandé de réécrire en C après avoir effectué les nouveaux changements. . J'ai réussi à garder un peu de Python, j'ai écrit une petite application web en utilisant Python + Flask et mon manager et je l'utilise constamment pour analyser les opérations du code C. Il y a donc toujours de l'espoir que Python sera officiellement adopté ici. :)
John Gaines Jr.18

6

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.


Commentez-les autant que possible. Aide à voir rapidement ce qui se passe, plutôt que d'essayer de comprendre ce que vous faites.
JD Frias

5

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.


5

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.


4
"" "Se lancer seul, en utilisant 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 que tout le monde peut utiliser. "" "- Je ne suis pas d'accord. Joel Spolsky n'aurait pas pu créer VBA pour Excel s'il avait suivi cette voie. Ce n'est de loin pas un exemple unique.
Job

@Job Je ne peux pas parler des circonstances exactes du développement de VBA pour Excel, mais cela ressemble à de la R&D avancée ou du prototypage. Il y a une différence entre la R&D avancée et les systèmes de production. Vous ne pouvez jamais travailler dans le noir, seul et isolé de votre équipe. Je ne suis pas opposé à l'introduction de nouvelles technologies, mais il est important que tout le monde sache quelles sont ces nouvelles technologies, leurs avantages, leurs inconvénients et comment elles sont déployées dans un projet. Faire quelque chose en solo et dans le noir est généralement une mauvaise idée et met un projet en danger.
Thomas Owens

@Thomas Je suis l'équipe
systempuntoout

@systempuntoout C'est peut-être vrai maintenant. Mais ce sera dans 6 mois? Ou un an? Le développement de logiciels, même si vous êtes actuellement seul, ne doit jamais être considéré comme une tâche en solo - vous devez penser au futur développeur ou mainteneur de votre travail.
Thomas Owens

@Thomas vous avez raison; comme indiqué dans certains commentaires ci-dessus, j'ai porté de nombreux scripts en C # (langage pris en charge par la société)
systempuntoout

3

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.


1
Comment savez-vous si c'est pour vous ou pour les autres? Au travail, vous pouvez être réaffecté ou vous pouvez quitter. Tout ce que vous produisez au travail (dans la plupart des cas) n'est pas le vôtre, mais il appartient à l'entreprise ou au client. S'ils ne peuvent pas le comprendre ou le maintenir, le temps perdu est le temps que vous avez passé à le développer plus le temps qu'il faut à quelqu'un d'autre pour le comprendre (et peut-être développer une nouvelle solution). Tout ce qui est produit au travail doit être traité comme quelque chose pour quelqu'un d'autre.
Thomas Owens

1
Si pendant le temps où vous étiez à ce poste, cela a augmenté votre propre productivité personnelle, alors l'entreprise a déjà tiré de la valeur de ce script et ce n'était pas un gaspillage, qu'il soit réutilisé plus tard par quelqu'un d'autre.
Nate CK

@Thomas Owens - il y a souvent des tâches ponctuelles - une fois qu'elles sont terminées, elles sont terminées - ou vos propres hacks et tests que vous faites au cours du développement pour passer à travers quelque chose de collant - encore une fois, une fois qu'ils sont terminés , ils sont faits - effectivement jetables.
Vector

Et si quelqu'un d'autre a besoin de faire la même tâche ou une tâche similaire plus tard (ce qui est très probable, selon mes expériences)? Ils doivent réinventer la roue. C'est une chose que d'avoir un prototype jetable pour résoudre un problème ou apprendre une bibliothèque ou un framework. C'est une autre de passer du temps à développer un outil pour effectuer une tâche, puis à la jeter. Les types d'outils auxquels la question fait référence concernent les tâches qui doivent potentiellement être effectuées plusieurs fois, et si d'autres personnes effectuent ces tâches, elles perdent du temps en n'ayant pas d'outil pour les aider (ou en ayant besoin de développer un tel outil) .
Thomas Owens

@Thomas Owens - d'accord - c'est inclus dans ce que j'ai dit «peut avoir un impact sur le travail des autres».
Vector

2

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.


2

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.


Croyez-le ou non, après avoir posté cette question et reçu de nombreuses suggestions perspicaces, j'ai porté plusieurs scripts en C #.
systempuntoout

1

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 ...


Travailler avec le bon outil ne pue pas, c'est la façon dont Unix construit les choses. La méthode Windows consiste à lancer Excel. Vieille histoire de marteaux et de clous ...
mouviciel

1

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.


Au travail, je ne pense pas que vous devriez traiter quoi que ce soit comme "pour vous-même". Ce sont des outils pour soutenir un projet, et il y a une équipe qui travaille sur ce projet. Vous pouvez démissionner, être licencié, réaffecté ou abandonné demain et maintenant, vos responsabilités incombent à quelqu'un d'autre. S'ils ne peuvent pas utiliser et entretenir vos outils, l'effort qui a été consacré à leur fabrication a été gaspillé (ce qui a coûté de l'argent à l'entreprise).
Thomas Owens

3
@Thomas: Je traite les scripts que je crée pour moi et mon usage personnel comme les miens. Ils sont une extension de mes bras et de mon esprit. C'est comme dire "Vous ne pouvez pas penser comme ça, vous ne pouvez penser que comme ça". Je pense que ce que vous pensez n'est pas important, tant que vous êtes capable de faire ce qu'on vous demande de faire.
Jose Faeti

Pour moi, cela est extrêmement peu professionnel et contraire à l'éthique. L'une des responsabilités éthiques d'un ingénieur logiciel est d'agir dans le meilleur intérêt du client et de l'employeur, tant qu'il ne risque pas le public. Une autre responsabilité éthique consiste à être juste et à soutenir ses collègues. Garder vos outils pour vous quand ils sont pour un projet viole ces deux principes.
Thomas Owens

3
@Thomas: Je ne parlais pas d'écrire un langage de programmation spécifique pour le projet. Je parle de quelque chose comme "renommer 10000 fichiers avec une seule commande", quelque chose que les programmeurs stupides font à la main un par un, alors que je suis capable de le faire avec un script auto-créé. Je n'interagis avec rien de spécifiquement impliqué dans le projet. Ce ne sont PAS des outils spécifiques au projet.
Jose Faeti

3
@Thomas: Il ne s'agit pas de savoir si un tel utilitaire existe, mais de savoir comment automatiser votre travail en créant de tels utilitaires. Vous aurez toujours besoin d'un nouveau script pour vous aider dans vos tâches quotidiennes. Forcer un programmeur à utiliser des outils existants ou des outils fabriqués par d'autres, c'est comme couper des ailes à un oiseau. Je ne peux pas imaginer travailler dans un tel endroit. Quoi qu'il en soit, je comprends vos points. Ma réponse a été soulevée parce que le PO était déjà dans cette situation, je pense que le mieux serait de partager l'idée de fabriquer / utiliser un outil particulier avec toute l'équipe dès que cela est nécessaire, puis de décider.
Jose Faeti

1

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.


0

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 ...

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.