È pratico scrivere i codici di uscita in uno script in cui il risultato è più complesso di successo / fallimento?

Più valori per i codici di uscita è una pratica abbastanza comune nel mondo della programmazione delle applicazioni. Dai un'occhiata a errno.h come esempio.

La parte fondamentale è di coordinare il significato dei codici di uscita in modo che i chiamanti & i mittenti sono in grado di comunicare correttamente il loro stato di uscita.

Per rispondere ad alcuni dei dettagli della tua domanda:

The only issue here is that the first task is a little more complicated than just success/fail.

Quale sarebbe un caso d'uso perfetto per l'implementazione di più codici di uscita come suggerito. Forse uno dei codici necessari è TRY_AGAIN_LATER , che consentirebbe alla tua routine di chiamata di sapere che la chiamata immediata è fallita, ma ci sono buone probabilità che funzioni dopo un timeout e poi riprovare.

My question is, is it practical to take the time to implement exit codes into a script as a temporary solution to a larger problem where the script is more complex than success/fail?

Assolutamente pratico e consigliabile. Non ti è garantito che avrai il tempo per correggere il secondo script. E in realtà potrebbe essere più semplice aspettare e riprovare una volta passata la condizione di errore. "Abbastanza buono" potrebbe essere esattamente questo in questo caso - perché passare una quantità eccessiva di tempo a fissare uno script quando si può aspettare il problema? Certo, potrebbe non essere il tuo caso esatto, ma avere più valori nei codici di uscita ti offre quella flessibilità.

"Is the time spent to implement this hack, while not a complete solution, worth it if we have to go back and undo the hack later?"

Molto probabilmente sì, ne varrà comunque la pena.

1. Non ti è garantito il tempo necessario per correggere correttamente il secondo script.
2. Non è garantito che in grado possa correggere correttamente il secondo script. Problemi tecnici sottostanti potrebbero impedire al tuo codice di funzionare nel modo desiderato.
3. Se non implementi il "trucco", considera quanto tu e il tuo team potreste soffrire nel frattempo mantenendo i due script in esecuzione.
4. Correttamente implementato, non è necessario annullare il trucco. Quelle sezioni del primo script semplicemente non verranno chiamate. E sto avendo difficoltà a vedere come ci sarebbe tanto lavoro nel secondo script: ti verranno mostrati i percorsi di errore che avrebbero in precedenza restituito un codice di uscita più sfumato.
5. I tuoi script sono in controllo di versione, giusto? Crea una nuova filiale e inserisci gli script "hackerati" con i codici di uscita aggiuntivi. Quando sei pronto per correggere il secondo script, torna al tuo ramo principale e lavora da lì.

Ma prendi qualche rough swags al costo per implementare il "hack" e costi per annullare tutto. Confronta questo con quanto la tua squadra soffrirà finché non avrai il tempo di sistemare completamente il secondo script. Quella valutazione finirebbe per essere la tua risposta finale.

Quello che stai facendo è costruire un sistema di flusso di lavoro, che è in realtà solo una macchina a stati complessa. I codici di uscita (e la registrazione degli errori) sono molto importanti per informare operazioni, test e sviluppo fino a dove le cose non sono andate a buon fine (e hanno avuto successo). Ma quello che vuoi veramente è un meccanismo di segnalazione che comunica ad altre entità se il loro lavoro può progredire, deve essere ritardato o se è necessario un intervento.

I codici di uscita sono una parte importante dell'immagine e possono essere utilizzati come proxy per risolvere il problema del flusso di lavoro. Ma molti processi sono più complessi di un flusso lineare di lavoro. E spesso vengono implementati sistemi che combinano più di un passo di lavoro, portando all'espansione dei codici di errore. Probabilmente stai anche osservando degli script che devono verificare che siano presenti le loro condizioni di partenza necessarie. Pertanto, i codici di errore sono dovuti a condizioni di stato che impediscono l'avvio del pezzo, inoltre sono presenti codici di errore dovuti a errori durante l'elaborazione.

La messaggistica o segnalazione di stato (un'altra risposta menziona l'uso di XML / JSON) è molto più comunicativa di un codice di errore numerico (e la confusione dei significati di un insieme limitato di codici di errore). Avere uno stato o un messaggio che comunica che un processo è "ok" per avviare / innescare è un segnale positivo per procedere.

Tutto ciò che ho detto, c'è un principio chiamato YAGNI (tu non ne avresti bisogno), che dice di rimandare la complessità della costruzione fino a quando non c'è un chiaro bisogno di farlo. Poiché i codici di errore / uscita sono un meccanismo esistente, è possibile che funzionino correttamente. Il mio consiglio è più di suggerire un'alternativa in cui crescere, se dovessi decidere che hai bisogno di qualcosa di più.

Come sottolineato da GlenH7, avere più valori possibili per il codice di uscita è una pratica abbastanza comune. Tuttavia, non sono sicuro di andare su quella strada se fossi nella tua posizione (che è chiaramente basata sulla mia conoscenza molto limitata della tua posizione).

I test automatici non sono umani. Penso che funzionino molto meglio e portino molto più beneficio quando le cose sono davvero in bianco e nero (o verde e rosso). La maggior parte dei libri di test unitari sottolineano come rendere i test molto semplici e prevedibili proprio per questo motivo.

Nel tuo caso, il tuo primo compito è piuttosto complesso e potrebbe restituire un sacco di cose diverse. Ma il lavoro a valle interessa davvero una cosa: dovrei o non dovrei correre?

Se il tuo lavoro downstream ha una serie di istruzioni condizionali e in base al codice di uscita del primo lavoro, farebbe cose diverse allora:

1. Sei sicuro di volere quei condizionali? Rende ogni esecuzione di test meno prevedibile. Se l'obiettivo di questa roba è verificare che il tuo software funzioni, forse la stessa verifica passerà ogni volta sarebbe più facile da mantenere?
2. Cosa succede se invece di un lavoro downstream, si hanno N lavori downstream, in cui ognuno verrebbe eseguito a seconda che l'ambiente sia stato configurato correttamente dal primo lavoro. In questo modo è possibile mantenere ogni codice del lavoro downstream molto più piccolo, semplice e funzionale.

Un'altra cosa che prenderei in considerazione è che il vero o il falso è decisamente molto limitante in termini di trasmissione di informazioni. Ma da -127 a 127 non è molto meglio. Potrebbe funzionare oggi, ma probabilmente avrai di nuovo raggiunto il limite. Cosa succede se invece si passa a XML o JSON. Fai eseguire il primo lavoro e genera un rapporto su ciò che ha fatto. Salvare quel rapporto su un file e fare analizzare il lavoro a valle e basare la sua decisione su questo. Entrambi i formati XML e JSON sono estensibili quindi a) sarai in grado di utilizzare quel rapporto per i report e b) sarai in grado di modificare il lavoro A e di estendere le informazioni che restituisce, ma il lavoro B dovrebbe essere ancora in grado di utilizzare i campi esistenti su cui si basa.

Vorrei attenermi ai codici di uscita di task1 che danno il pass o a come non ha funzionato. Non più.

Task2 dovrebbe avere un pre-task scritto che analizza i log di output ecc di task1 tra le altre fonti per prendere la decisione di eseguire task2 (e forse su cosa dovrebbe essere eseguito) ..

Con un po 'di pratica, puoi mantenere le modifiche a task1 e task2 al minimo (o nessuna modifica). Quello sarebbe il riutilizzo ma in un flusso modificato, quindi il flusso con il tester pre-condizionale task2 dovrebbe ancora essere testato.