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

Hai bisogno di 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) che sei stato in colpa per non averlo portato prima alla sua attenzione.

Per lo meno gli script dovrebbero essere posti sotto il controllo del codice sorgente "nel caso in cui" - almeno se non sei disponibile (per qualsiasi ragione) 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 collaboratori in Python è inferiore a quello della riscrittura potresti addirittura vincere la discussione.

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

Controlla gli script in un repository a cui tutti gli sviluppatori (obbligatori) possono accedere. Ma assicurati di prendere nota del fatto che hai prima scritto questi script per il tuo scopo proprio , ad esempio per eseguire un'attività che ti è stata assegnata. Quindi aggiungi che stai solo controllando questi script per consentire agli altri il vantaggio di usarli.

Dopo avrai solo bisogno di vedere come rispondono le altre persone.

Ho incontrato 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 dirò ai miei supervisori e sarò pronto per un sacco di paragoni e spiegherò perché Python è stata la scelta giusta. Sarà frustrante, ma penso che la maggior parte sarebbe d'accordo che Python è una buona scelta per la manipolazione del testo.

La prima cosa che devi fare è parlare con la squadra e il tuo capo. In questo momento, hai un enorme fattore di camion (se sei stato investito da un camion, nessun altro sarebbe facilmente in grado di mantenere i tuoi script). Sembra che avere degli script per eseguire queste attività siano importanti, ma è anche importante che chiunque abbia bisogno di modificare e mantenere questi script. Devi spiegare in che modo l'utilizzo di Python aggiunge valore: come risparmia tempo, sforzi, risorse, denaro e così via.

In secondo luogo, mettilo nel controllo di 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 per il contraccolpo: le persone in genere non amano il cambiamento. Scappare da solo, utilizzando 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 per te) di automatizzare queste attività per tutti da usare.

Penso che questo sia probabilmente un buon caso di

It's easier to ask forgiveness than it is to get permission.

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

La mia regola del pollice è:

Qualunque cosa che possa influire sul lavoro degli altri dovrebbe essere discussa con i tuoi colleghi e superiori al più presto.

Tuttavia, se è per te e tu solo, purché non danneggi l'infrastruttura o la sicurezza della tua azienda , sei libero di fare ciò che desideri per portare a termine il lavoro .

Hai due opzioni:

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

A seconda dell'organizzazione # 1 potrebbe essere impegnativo (dopo tutto la limitazione dell'elenco di tecnologie standard evita un'esplosione combinatoria dei requisiti di formazione e 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. Per esempio. una ricerca per "LINQ to CSV" dovrebbe ottenere alcuni risultati utili.

BTW, gli strumenti di sviluppo di VB6 (IDE, compilatore) non sono supportati (nemmeno le correzioni di sicurezza) quindi è probabile che lo standard necessiti comunque di aggiornamento. (Il runtime VB6 è supportato come parte e incluso nell'installazione delle attuali versioni di Windows). Questo potrebbe forse essere usato come aiuto per l'approccio n. 1: lo strumento standard ha bisogno di un obiettivo mobile a causa delle dipendenze dei fornitori.

Se ti viene assegnato un compito ed è l'unico modo in cui puoi farlo in tempo, non hai scelta. Penso che sia saggio lasciare che i responsabili sappiano cosa stai facendo. Non dovresti andare fuori dal controllo del codice sorgente richiesto (a meno che non funzioni assolutamente assolutamente?) Test e documentazione.

A volte un'azienda potrebbe dover consentire a un singolo sviluppatore di iniziare a esaminare una nuova area di sviluppo. Sfortunatamente, il codice potrebbe entrare in produzione più velocemente di quanto chiunque altro possa fare a meno.

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

Poi qualcosa colpisce il ventilatore nell'intera pipeline e tu vai avanti - WTH IS DAT KODEZ? Soprattutto in Perl ... E il debugging del semplice, diciamo, problema di codifica, si trasforma in un pasticcio da incubo. Non è possibile eseguire il debug di 5 lingue su 7 in modo efficace e si trasforma in un vero dolore.

O devi aggiungere una semplice modifica, ma crei 10 errori perché Perl ha dei trucchi, Java ha dei trucchi, ecc.

E quella catena di lingue 7+ inizia un passo alla volta.

Calpesta attentamente, qui si trovano i draghi ...

Se si tratta di 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 avere tali strumenti, indipendentemente dalla lingua in cui sono scritti , e inizieranno ad essere implementati nel loro ambiente di lavoro.

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

Ma quando devi fare qualche attività one-shot, come importare 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, userei questa regola:

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

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

3) Se il compito sembrava essere one-shot, ma diventava ripetibile, dovresti parlare con il manager per cambiarlo da 1) a 2) e riscriverlo dalla tua lingua preferita a quella supportata dall'azienda.

Suppongo che tu non sia nella posizione 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 te ne andrai. Non essere in grado di mantenere il codice è probabilmente un motivo sufficiente per smettere di usare Python. Oppure puoi iniziare a educare i tuoi colleghi in questa lingua ...