Va bene usare una lingua non supportata dalla tua azienda per alcune attività?

Lavoro per un'azienda che supporta diverse lingue: COBOL, VB6, C # e Java.
Uso queste lingue per il mio lavoro principale, ma spesso mi trovo a programmare alcuni programmi minori (ad esempio gli script) in Python perché l'ho trovato lo strumento migliore per quel tipo di attività.

Ad esempio: un analista mi fornisce un file CSV complesso per popolare alcune tabelle DB, quindi utilizzerei Python per analizzarlo e creare uno script DB.

Qual è il problema?
Il problema principale che vedo è che alcune parti di questi script veloci e sporchi stanno lentamente guadagnando importanza e:

1. La mia azienda non supporta Python
2. Non sono controllati dalla versione (li backup in un altro modo)
3. I miei colleghi non conoscono Python

Gli analisti hanno persino iniziato a fare riferimento a loro tramite e-mail ("avvia lo script che esporta ..."), quindi sono necessari più spesso di quanto pensassi inizialmente.

Dovrei aggiungere che questi script sono solo utility che non fanno parte del progetto principale; aiutano semplicemente a svolgere compiti banali in meno tempo. Ai miei piccoli compiti mi aiutano molto.

In breve, se fossi stato un vincitore della lotteria per un incidente , i miei colleghi avrebbero dovuto mantenere vivo il progetto senza quegli script; passerebbero più tempo a correggere manualmente gli errori CSV, ad esempio.

È uno scenario comune? Sto facendo qualcosa di sbagliato? Cosa dovrei fare?

Devi formalizzare la situazione in quanto non dovrebbe davvero arrivare a questo punto. Tuttavia, queste cose accadono, quindi devi spiegare al tuo capo che hai creato questi script per uso personale, ma sono "sfuggiti" a una più ampia diffusione. Ammetti (se necessario) di essere stato in colpa per non averlo portato alla sua attenzione prima.

Per lo meno gli script dovrebbero essere messi sotto il controllo del codice sorgente "per ogni evenienza" - almeno se non sei disponibile (per qualsiasi motivo) i tuoi colleghi avranno accesso agli script.

Quindi devi convincere il tuo capo che Python è la strada da percorrere per questi o accettare che dovrai riscriverli in una lingua supportata. Se il costo di documentare gli script e di educare i tuoi colleghi in Python è inferiore a quello della riscrittura, potresti persino vincere l'argomento.

Non posso darti una risposta completa su cosa dovresti fare. Posso solo dare un singolo suggerimento che puoi usare per iniziare:

Controllare gli script in un repository a cui tutti gli sviluppatori (obbligatori) possano accedere. Ma fare molto sicuri di prendere nota del fatto che hai scritto prima questi script per il proprio scopo, cioè per eseguire un compito che era stato dato. Quindi aggiungi che stai solo controllando questi script per consentire ad altri il vantaggio di usarli.

Dopodiché dovrai solo vedere come le altre persone rispondono a questo.

Ho riscontrato problemi simili in cui lavoro. Ho sentito "Cos'è PHP?" diversi anni fa. Non capiscono o si preoccupano di imparare qualcosa al di fuori dello stack MS. Se python è lo strumento giusto per il lavoro, lo direi solo ai miei supervisori e sarei pronto per un sacco di confronto e spiegando perché Python era la scelta giusta. Sarà frustrante, ma penso che molti sarebbero d'accordo sul fatto che Python sia una buona scelta per la manipolazione del testo.

La prima cosa che devi fare è parlare con il team e il tuo capo. In questo momento, hai un enorme fattore di camion (se sei stato colpito da un camion, nessun altro sarebbe facilmente in grado di mantenere i tuoi script). Sembra che avere degli script per svolgere queste attività sia importante, ma è anche importante che chiunque debba modificarli e mantenerli. Devi spiegare in che modo l'utilizzo di Python aggiunge valore, in che modo consente di risparmiare tempo, fatica, risorse, denaro e così via.

Secondo, mettilo nel controllo della versione del progetto. Adesso. Nulla di ciò che produci per un progetto dovrebbe essere al di fuori del controllo di versione di quel progetto, mai.

Preparati al gioco: in genere alle persone non piace il cambiamento. Scappare da soli, usare tecnologie non supportate e sconosciute (per il team / organizzazione) è stata una cattiva idea, senza consultare almeno gli altri sviluppatori e determinare il modo migliore (per il progetto, non solo tu) di automatizzare queste attività per tutti usare.

Penso che questo sia probabilmente un buon caso di

È più facile chiedere perdono che ottenere l'autorizzazione.

Sembra che tu abbia fatto il lavoro, ma ora dovrai affrontare le ripercussioni.

La mia regola empirica è:

Tutto ciò che potenzialmente influisce sul lavoro degli altri dovrebbe essere discusso al più presto con colleghi e superiori.

Ma, se è solo per te e per te, purché non danneggi l'infrastruttura o la sicurezza della tua azienda , sei libero di fare ciò che desideri.

Hai due opzioni:

1. Rendilo uno standard
2. Traduci in uno strumento standard

A seconda dell'organizzazione n. 1 potrebbe essere difficile (dopotutto limitare l'elenco delle tecnologie standard evita un'esplosione combinatoria di addestramento e requisiti di abilità di supporto).

La seconda opzione aiuterebbe il tuo set di abilità e potresti essere in grado di trovare terze parti (e probabilmente open source con licenze commercialmente amichevoli) per fare un po 'del duro lavoro. Ad esempio, una ricerca di "LINQ to CSV" dovrebbe ottenere alcuni risultati utili.

A proposito, gli strumenti di sviluppo di VB6 (IDE, compilatore) non sono supportati (nemmeno le correzioni di sicurezza), quindi è probabile che lo standard debba comunque essere aggiornato. (Il runtime VB6 è supportato come parte di - e incluso nell'installazione - delle attuali versioni di Windows). Questo potrebbe forse essere usato come supporto per l'approccio n. 1: il set di strumenti standard deve raggiungere un obiettivo mobile a causa delle dipendenze dei fornitori.

Se ti viene assegnato un compito ed è l'unico modo in cui puoi realizzarlo in tempo, non hai davvero scelta. Penso che sia saggio far sapere ai responsabili ciò che stai facendo. Non dovresti andare al di fuori del controllo del codice sorgente richiesto (a meno che non funzioni assolutamente?) Test e documentazione.

A volte un'azienda potrebbe dover lasciare che un singolo sviluppatore inizi a cercare una nuova area di sviluppo. Sfortunatamente, il codice potrebbe entrare in produzione più velocemente di quanto chiunque altro possa ottenere rapidamente.

Bene, devo ammettere che lavorare con 20 lingue diverse puzza, MOLTO.

Hai uno script Bash che chiama lo script Python che chiama lo script Perl che chiama il binario Java che chiama C dll ...

Quindi qualcosa colpisce il fan in tutto il gasdotto e si passa attraverso - DOVE È DAT KODEZ? Soprattutto in Perl ... E il debug semplice, diciamo, il problema di codifica, si trasforma in un casino da incubo. Non è possibile eseguire il debug di 5 lingue su 7 in modo efficace e si trasforma in un vero dolore.

Oppure devi aggiungere una semplice modifica, ma crei 10 errori perché Perl ha gotcha, Java ha gotcha, ecc.

E quella catena linguistica 7+ inizia un passo alla volta.

Percorri attentamente, ecco i draghi ...

Se questi sono strumenti che usi per te stesso, sei libero di fare qualsiasi cosa che ti renda più produttivo.

In realtà, dovresti essere incoraggiato a creare e utilizzare tali strumenti, che alla fine diventeranno un'estensione delle tue braccia.

Alla fine, riconosceranno l'importanza di disporre di tali strumenti, indipendentemente dalla lingua in cui sono scritti , e inizieranno a implementare nel loro ambiente di lavoro.

Quando ti viene detto di scrivere codice facendo sth., La lingua viene solitamente specificata o implicita (la regola nelle società).

Ma quando devi svolgere alcune attività one-shot, come importare i dati in DB, sei libero di scegliere lo strumento che secondo te si adatta meglio, perché devi fare qualcosa di corretto e veloce e il risultato è importante, non gli strumenti.

Quindi, vorrei usare quella regola:

1) Se ti viene chiesto di svolgere alcune attività, come l'importazione dei dati, utilizzerei gli strumenti / lingua / ecc. sarebbe il più conveniente per me e sarebbe il più veloce per il compito.

2) Se ti viene detto di scrivere uno strumento che esegue alcune attività, come importare alcuni dati, discuterei quale linguaggio / strumento usare con il gestore (con l'eccezione quando uso un linguaggio implicito standard, ad esempio quando l'azienda usa [quasi ] solo Java).

3) Se l'attività sembrava essere un colpo solo, ma diventasse ripetibile, dovresti parlare con il manager per cambiarlo da 1) a 2) e riscrivere dalla tua lingua preferita a quella supportata dall'azienda.

Suppongo che tu non sia in grado di decidere (altrimenti non faresti la domanda). Cosa pensa il tuo capo di questo problema? Dovresti parlargli e cercare di convincerlo che Python è la strada da percorrere ...

Naturalmente, il problema riguarda ciò che accadrà quando esci. Non essere in grado di mantenere il codice è probabilmente una ragione sufficiente per smettere di usare Python. Oppure puoi iniziare a educare i tuoi colleghi a questa lingua ...