Perché scrivere un intero script bash in functions?

Ho “iniziato a utilizzare questo stesso stile di programmazione bash dopo aver letto il post del blog di Kfir Lavi “Defensive Bash Programming” . Fornisce alcune buone ragioni, ma personalmente le trovo le più importanti:

• le procedure diventano descrittive: è molto più facile capire quale sia supposta una particolare parte di codice da fare. Invece del muro di codice, vedi “Oh, la funzione find_log_errors legge quel file di log per errori”. Confrontalo con la ricerca di un sacco di righe awk / grep / sed che usa dio sa che tipo di regex nel bel mezzo di un lungo script – non hai idea di cosa ci faccia a meno che non ci siano commenti.

• puoi eseguire il debug di funzioni racchiudendo tra set -x e set +x. Una volta che sai che il resto del codice funziona bene, puoi usare questo trucco per concentrarti sul debug solo di quella funzione specifica. Certo, puoi racchiudere parti di script, ma cosa succede se è “una porzione lunga? È più facile fare qualcosa del genere:

   set -x parse_process_list set +x 

• utilizzo della stampa con cat <<- EOF . . . EOF. Lho usato diverse volte per rendere il mio codice molto più professionale. Inoltre, parse_args() con la funzione getopts è abbastanza conveniente. Ancora una volta, questo aiuta con la leggibilità, invece di inserire tutto nello script come un gigantesco muro di testo. È anche conveniente riutilizzarli.

E ovviamente, questo è molto di più leggibile per qualcuno che conosce C o Java, o Vala, ma ha una limitata esperienza di bash. Per quanto riguarda lefficienza, non cè molto di quello che puoi fare – bash in sé non è il linguaggio più efficiente e le persone preferiscono perl e python quando si tratta di velocità ed efficienza.Tuttavia, puoi nice una funzione:

nice -10 resource_hungry_function 

Rispetto a chiamare nice su ogni riga di codice, questo riduce tutta la digitazione E può essere convenientemente usato quando vuoi che solo una parte del tuo script venga eseguito con una priorità inferiore.

Lesecuzione di funzioni in background, a mio parere, aiuta anche quando vuoi avere tutto un mucchio di istruzioni da eseguire in background.

Alcuni degli esempi in cui ho “usato questo stile:

• https://askubuntu.com/a/758339/295286
• https://askubuntu.com/a/788654/295286
• https://github.com/SergKolo/sergrep/blob/master/chgreeterbg.sh

Commenti

• Non sono sicuro che dovresti prendere molto sul serio i suggerimenti di questo articolo. Certo, ha alcune buone idee, ma chiaramente non è qualcuno abituato allo scripting della shell. Non un singola variabile in uno qualsiasi degli esempi è tra virgolette (!) e suggerisce di usare UPPER C Nomi di variabili ASE che spesso sono una pessima idea poiché possono entrare in conflitto con le variabili env esistenti. I tuoi punti in questa risposta hanno senso, ma larticolo collegato sembra essere stato scritto da qualcuno che è semplicemente abituato ad altre lingue e sta cercando di forzare il proprio stile su bash.
• @terdon sono tornato allarticolo e lho riletto. Lunico posto in cui lautore menziona la denominazione delle variabili in maiuscolo è in ” Variabili globali immutabili “. Se consideri le variabili globali come quelle che devono essere allinterno dellambiente della funzione ‘, allora ha senso renderle maiuscole. Nota a margine, il manuale di bash ‘ s non ‘ t convenzione di stato per il caso variabile. Anche qui ha accettato la risposta dice ” di solito ” e lunico ” standard ” è di Google, che ‘ t rappresenta lintero settore IT.
• @terdon su unaltra nota, sono daccordo al 100% sul fatto che la citazione variabile avrebbe dovuto essere menzionata nellarticolo, ed è stata evidenziata anche nei commenti sul blog. Inoltre, non ‘ giudicare qualcuno che utilizza questo stile di codifica, indipendentemente dal fatto che ‘ sia utilizzato o meno in unaltra lingua. Lintera domanda e le risposte mostrano chiaramente i vantaggi di ‘ e il grado ‘ della persona ‘ il riutilizzo di unaltra lingua è probabilmente irrilevante qui.
• @terdon beh, larticolo è stato pubblicato come parte della ” fonte ” materiale. Avrei potuto pubblicare tutto come le mie opinioni, ma dovevo solo dare credito che alcune delle cose che ho imparato dallarticolo e che tutto questo proveniva dalla ricerca nel tempo. La pagina linkedin dellautore ‘ mostra che ha una buona esperienza con Linux e IT in generale, quindi ‘ immagino che larticolo non ‘ non lo mostro davvero, ma confido nella tua esperienza quando si tratta di Linux e degli script di shell, quindi potresti avere ragione.
• Questo ‘ è unottima risposta ma ‘ vorrei anche aggiungere che lambito della variabile in Bash è funky. Per questo motivo, preferisco dichiarare le mie variabili allinterno delle funzioni utilizzando local e chiamando tutto tramite la funzione main(). Questo rende le cose molto più gestibili e puoi evitare una situazione potenzialmente complicata.

La leggibilità è una cosa. Ma cè di più nella modularizzazione oltre a questo. ( La semi-modularizzazione è forse più corretta per le funzioni.)

Nelle funzioni puoi mantenere alcune variabili locali, il che aumenta l affidabilità , diminuendo la possibilità di le cose si incasinano.

Un altro vantaggio delle funzioni è la riutilizzabilità . Una volta che una funzione è stata codificata, può essere applicata più volte nello script. Puoi anche portarlo su un altro script.

Il tuo codice ora potrebbe essere lineare, ma in futuro potresti entrare nel regno del multi-threading o multi- elaborazione nel mondo Bash. Una volta che impari a fare le cose nelle funzioni, sarai ben equipaggiato per il passaggio al parallelo.

Un altro punto da aggiungere. Come nota Etsitpab Nioliv nel commento qui sotto, è facile reindirizzare dalle funzioni come entità coerente, ma cè un altro aspetto dei reindirizzamenti con le funzioni. Vale a dire, i reindirizzamenti possono essere impostati lungo la definizione della funzione. Ad esempio:

f () { echo something; } > log 

Ora non sono necessari reindirizzamenti espliciti per le chiamate di funzione.

$ f 

Questo può risparmiare molte ripetizioni, il che aumenta di nuovo laffidabilità e aiuta a mantenere le cose in ordine.

Vedi anche

• https://unix.stackexchange.com/a/483304/181255

Commenti

• Molto buono risposta anche se sarebbe molto meglio se fosse suddiviso in funzioni.
• Forse aggiungere che le funzioni consentono di importare lo script in un altro script (utilizzando source o . scriptname.sh e utilizza queste funzioni come se fossero nel nuovo script.
• Questo ‘ è già coperto in unaltra risposta.
• Lo apprezzo. Ma ‘ preferirei che anche altre persone fossero importanti.
• Ho affrontato un caso oggi dove ho dovuto reindirizzare parte delloutput di uno script su un file (per inviarlo tramite e-mail) invece di farlo eco. Ho semplicemente dovuto eseguire myFunction > > myFile per reindirizzare loutput delle funzioni desiderate. Abbastanza conveniente. Potrebbe essere rilevante.

Nel mio commento ho menzionato tre vantaggi delle funzioni:

1. Sono più facili da testare e verificare la correttezza.

2. Le funzioni possono essere facilmente riutilizzate (reperite) in script futuri

3. Al tuo capo piacciono.

E, non sottovalutare mai limportanza del numero 3.

Vorrei affrontare un altro problema:

… quindi essere in grado di scambiare arbitrariamente lordine di esecuzione non è qualcosa che normalmente faremmo. Ad esempio, non vorresti improvvisamente inserire declare_variables dopo walk_into_bar, in modo da rompere le cose.

Per ottenere il vantaggio di suddividere il codice in funzioni, si dovrebbe cercare di rendere le funzioni il più indipendenti possibile. Se walk_into_bar richiede una variabile che non viene utilizzata altrove, quindi quella variabile dovrebbe essere definita e resa locale in walk_into_bar. Il processo di separazione del codice in funzioni e di minimizzazione delle loro interdipendenze dovrebbe rendere il codice più chiaro e semplice .

Idealmente, le funzioni dovrebbero essere facili da testare individualmente. Se, a causa delle interazioni, non sono facili da testare, allora questo è un segno che potrebbero trarre vantaggio dal refactoring.

Commenti

• ‘ d sostengo che ‘ a volte è ragionevole modellare e applica quelle dipendenze, contro il refactoring per evitarle (poiché se ci sono abbastanza h di loro, e ‘ sono sufficientemente pelosi, il che può portare a un caso in cui le cose non sono più modularizzate in funzioni). Un caso duso molto complicato una volta ha ispirato un framework a fare proprio questo .
• Ciò che deve essere diviso in funzioni dovrebbe essere, ma lesempio lo porta troppo lontano. Penso che lunico che mi infastidisca davvero è la funzione di dichiarazione delle variabili. Le variabili globali, soprattutto quelle statiche, dovrebbero essere definite globalmente in una sezione commentata dedicata a tale scopo. Le variabili dinamiche dovrebbero essere locali rispetto alle funzioni che le utilizzano e le modificano.
• @Xalorous I ‘ ho visto una pratica in cui le variabili globali sono inizializzate in una procedura, come passaggio intermedio e veloce prima dello sviluppo di una procedura che legge il loro valore da un file esterno … sono daccordo che dovrebbe essere più pulito separare definizione e inizializzazione ma raramente bisogna piegarsi per sottoporsi al vantaggio numero 3 ;-)

Pur essendo totalmente daccordo con la riusabilità , la leggibilità e il bacio delicato dei capi, ma cè un altro vantaggio delle funzioni in bash : ambito variabile . Come mostra LDP :

#!/bin/bash # ex62.sh: Global and local variables inside a function. func () { local loc_var=23 # Declared as local variable. echo # Uses the "local" builtin. echo "\"loc_var\" in function = $loc_var" global_var=999 # Not declared as local. # Therefore, defaults to global. echo "\"global_var\" in function = $global_var" } func # Now, to see if local variable "loc_var" exists outside the function. echo echo "\"loc_var\" outside function = $loc_var" # $loc_var outside function = # No, $loc_var not visible globally. echo "\"global_var\" outside function = $global_var" # $global_var outside function = 999 # $global_var is visible globally. echo exit 0 # In contrast to C, a Bash variable declared inside a function #+ is local ONLY if declared as such. 

Non lo vedo molto spesso nel mondo reale script di shell, ma sembra una buona idea per script più complessi. La riduzione della coesione aiuta a evitare bug in cui “reindirizzi una variabile prevista in unaltra parte del codice .

Riusabilità spesso significa creare una libreria comune di funzioni e source inserire quella libreria in tutti i tuoi script. Questo non li aiuterà a correre più velocemente, ma ti aiuterà a scriverli più velocemente.

Commenti

• Poche persone usano esplicitamente local, ma penso che la maggior parte delle persone che scrivono script suddivisi in funzioni seguano ancora il principio di progettazione. Usign local rende solo più difficile introdurre bug.
• local rende le variabili disponibili per la funzione e le sue figlie, quindi ‘ è davvero bello avere una variabile che può essere passata giù dalla funzione A, ma non disponibile per la funzione B, che potrebbe voler avere una variabile con lo stesso nome ma uno scopo diverso.Quindi ‘ va bene per definire lambito e, come ha detto Voo, meno bug

Suddividi il codice in funzioni per lo stesso motivo per cui lo faresti per C / C ++, python, perl, ruby o qualsiasi altro linguaggio di programmazione. La ragione più profonda è lastrazione: incapsuli attività di livello inferiore in primitive (funzioni) di livello superiore in modo da non doverti preoccupare di come vengono fatte le cose. Allo stesso tempo, il codice diventa più leggibile (e gestibile) e il la logica del programma diventa più chiara.

Tuttavia, guardando il tuo codice, trovo abbastanza strano avere una funzione per dichiarare le variabili; questo mi fa davvero alzare un sopracciglio.

Commenti

• Risposta sottovalutata IMHO. Suggerisci di dichiarare le variabili nella funzione / metodo main?

Una ragione completamente diversa da quelle già fornite in altre risposte: una delle ragioni per cui a volte si usa questa tecnica, dove lunica Listruzione di definizione di non funzione al livello superiore è una chiamata a main, è per assicurarsi che lo script non faccia accidentalmente qualcosa di brutto se lo script viene troncato. Lo script potrebbe essere troncato se è convogliato dal processo A al processo B (la shell), e il processo A termina per qualsiasi motivo prima di aver finito di scrivere lintero script. Ciò è particolarmente probabile che accada se il processo A recupera lo script da una risorsa remota. Anche se per motivi di sicurezza questa non è una buona idea, è qualcosa che viene fatto e alcuni script sono stati modificati per anticipare il problema.

Commenti

• Interessante! Ma trovo preoccupante che ci si debba occupare di queste cose in ciascuno dei programmi. Daltra parte, esattamente questo main() pattern è usuale in Python dove si usa if __name__ == '__main__': main() alla fine del file.
• Lidioma python ha il vantaggio di consentire ad altri script di import lo script corrente senza eseguire main. Suppongo che una guardia simile potrebbe essere inserita in uno script bash.
• @Jake Cobb Sì. Ora lo faccio in tutti i nuovi script bash. Ho uno script che contiene uninfrastruttura di base di funzioni utilizzate da tutti i nuovi script. Quello script può essere acquistato o eseguito. Se originato, la sua funzione principale non viene eseguita. Il rilevamento dellorigine rispetto allesecuzione avviene tramite il fatto che BASH_SOURCE contiene il nome dello script in esecuzione. Se ‘ è uguale allo script principale, lo script viene eseguito. Altrimenti, ‘ viene originato.
• Strettamente correlato a questa risposta, bash utilizza una semplice elaborazione basata su riga quando viene eseguito da un file già su disco. Se il file cambia durante lesecuzione dello script, il contatore di riga non ‘ t cambia e ‘ continuerà sulla riga sbagliata. Lincapsulamento di tutto in funzioni garantisce che ‘ venga caricato in memoria prima di eseguire qualsiasi cosa, quindi la modifica del file non ‘ influisce su di esso.

Alcuni truisms rilevanti sulla programmazione:

• Il tuo programma cambierà, anche se il tuo capo insiste che non è così.
• Solo il codice e limmissione influiscono sul comportamento del programma.
• Dare un nome a è difficile.

I commenti iniziano come una sosta per non essere in grado di esprimere chiaramente le tue idee in codice * e peggiorare (o semplicemente sbagliare) con il cambiamento. Pertanto, se possibile, esprimi concetti, strutture, ragionamento, semantica, flusso, gestione degli errori e qualsiasi altra cosa pertinente alla comprensione del codice come codice.

Detto questo, Le funzioni Bash hanno alcuni problemi non trovati nella maggior parte delle lingue:

• La spaziatura dei nomi è terribile in Bash. Ad esempio, dimenticando di utilizzare la parola chiave local si inquina lo spazio dei nomi globale.
• Lutilizzo di local foo="$(bar)" produce perdere il codice di uscita di bar .
• Non ci sono parametri denominati, quindi devi tenere a mente cosa significa "$@" in contesti diversi.

* Mi dispiace se questo offende, ma dopo utilizzando commenti per alcuni anni e sviluppando senza di essi ** per più anni è abbastanza chiaro quale sia superiore.

** È ancora necessario utilizzare commenti per la licenza, la documentazione API e simili.

Commenti

• Ho impostato quasi tutte le variabili locali dichiarandole a null allinizio della funzione …local foo="" Quindi impostarli utilizzando lesecuzione del comando per agire sul risultato … foo="$(bar)" || { echo "bar() failed"; return 1; }. Questo ci fa uscire rapidamente dalla funzione quando non è possibile impostare un valore richiesto. Le parentesi graffe sono necessarie per assicurare che return 1 venga eseguito solo in caso di errore.
• Volevo solo commentare i tuoi punti elenco. Se utilizzi ‘ funzioni subshell ‘ (funzioni delimitate da parentesi e non parentesi graffe), 1) non ‘ non è necessario utilizzare local ma ottenere i vantaggi di local, 2) ‘ non incorrere nel problema di perdere il codice di uscita della sostituzione del comando in local foo=$(bar) tanto (perché ‘ non stai usando locale) 3) Non ‘ devi preoccuparti sullinquinamento accidentale o sulla modifica dellambito globale 4) sono in grado di trasmettere ‘ parametri denominati ‘ che sono ‘ local ‘ alla tua funzione utilizzando la sintassi foo=bar baz=buz my-command

Un processo richiede una sequenza. La maggior parte delle attività sono sequenziali. Non ha senso interferire con lordine.

Ma laspetto più importante della programmazione, che include lo scripting, è il testing. Test, test, test. Quali script di test hai attualmente per convalidare la correttezza dei tuoi script?

Il tuo capo sta cercando di guidarti dallessere uno script kiddy a essere un programmatore. Questa è una buona direzione in cui andare. Le persone che vengono dopo di te ti piaceranno.

MA. Ricorda sempre le tue radici orientate al processo. Se ha senso che le funzioni siano ordinate nella sequenza in cui vengono eseguite tipicamente, fallo, almeno come primo passaggio.

Più tardi, vedrai che alcune delle tue funzioni sono gestendo input, altri output, altri elaborando, altri modellando dati e altri manipolando i dati, quindi potrebbe essere intelligente raggruppare metodi simili, forse anche spostarli in file separati.

In seguito, potresti vieni a rendermi conto che “ora hai scritto librerie di piccole funzioni di supporto che usi in molti dei tuoi script.

Commenti e la spaziatura non può avvicinarsi alla leggibilità che le funzioni possono, come dimostrerò. Senza funzioni, non puoi vedere la foresta per gli alberi – grossi problemi si nascondono tra molte righe di dettaglio. In altre parole, le persone non possono concentrarsi simultaneamente sui dettagli fini e sul quadro generale. Questo potrebbe non essere ovvio in un breve script; fintanto che rimane breve può essere abbastanza leggibile. Il software diventa più grande, non più piccolo , e certamente fa parte dellintero sistema software della tua azienda, che è sicuramente molto più grande, probabilmente milioni di righe.

Considera se ti ho dato istruzioni come questa:

Place your hands on your desk. Tense your arm muscles. Extend your knee and hip joints. Relax your arms. Move your arms backwards. Move your left leg backwards. Move your right leg backwards. (continue for 10,000 more lines) 

Quando sei arrivato a metà, o anche al 5%, avresti dimenticato quali erano i primi passaggi. Probabilmente non potresti individuare la maggior parte dei problemi, perché non potresti vedere la foresta per gli alberi. Confronta con le funzioni:

stand_up(); walk_to(break_room); pour(coffee); walk_to(office); 

Questo è certamente molto più comprensibile, indipendentemente dal numero di commenti che potresti inserire nella versione sequenziale riga per riga. inoltre rende molto più probabile che “noterai di aver dimenticato di preparare il caffè e probabilmente hai dimenticato sit_down () alla fine. Quando la tua mente pensa ai dettagli delle regex grep e awk, non puoi “pensare a un quadro generale -” e se non viene preparato il caffè “?

Le funzioni ti consentono principalmente di vedere il quadro generale, e nota che hai dimenticato di preparare il caffè (o che qualcuno potrebbe preferire il tè). In un altro momento, in uno stato danimo diverso, ti preoccupi dellimplementazione dettagliata.

Ci sono anche altri vantaggi discussi in altre risposte, ovviamente. Un altro vantaggio non chiaramente indicato nelle altre risposte è che le funzioni forniscono una garanzia importante per prevenire e correggere i bug. Se scopri che qualche variabile $ foo nella corretta funzione walk_to () era sbagliata, sai che devi solo guardare le altre 6 righe di quella funzione per trovare tutto ciò che potrebbe essere stato influenzato da quel problema, e tutto ciò che potrebbe hanno causato che fosse sbagliato. Senza le funzioni (appropriate), qualsiasi cosa nellintero sistema potrebbe essere una causa di $ foo non corretta, e qualsiasi cosa potrebbe essere influenzata da $ foo. Quindi non puoi aggiustare $ pippo in modo sicuro senza riesaminare ogni singola riga del programma. Se $ pippo è locale per una funzione, puoi garantire che qualsiasi modifica sia sicura e corretta controllando solo quella funzione.

Commenti

• Questa non è la sintassi ‘ t bash.Tuttavia, ‘ è un peccato; Non ‘ penso che ci sia un modo per passare linput a funzioni del genere. (ad es. pour(); < coffee). Sembra più c++ o php (credo).
• @ tjt263 senza parentesi, ‘ s sintassi bash: versa il caffè. Con le parentesi, ‘ è praticamente tutte le altre lingue. 🙂

Il tempo è denaro

Ci sono altre buone risposte che fanno luce sui motivi tecnici per scrivere in modo modulare uno script, potenzialmente lungo, sviluppato in un ambiente di lavoro, sviluppato per essere utilizzato da un gruppo di persone e non solo per uso personale.

Voglio concentrarsi su una sola aspettativa: in un ambiente di lavoro “il tempo è denaro” . Quindi lassenza di bug e le prestazioni del tuo codice vengono valutate insieme a leggibilità , testabilità, manutenibilità, refactoring, riusabilità …

Scrittura in ” moduli “ un codice diminuirà il tempo di lettura necessario non solo al coder stesso, ma anche il tempo utilizzato dai tester o dai il capo. Inoltre tieni presente che il tempo di un capo è solitamente pagato più del tempo di un programmatore e che il tuo capo valuterà la qualità del tuo lavoro.

Inoltre scrivendo in “moduli” indipendenti un codice (anche uno script bash) ti permetterà di lavorare in “parallelo” con altro componente del tuo team accorciando i tempi complessivi di produzione e utilizzando al meglio le competenze del singolo, per rivedere o riscrivere una parte senza effetti collaterali sugli altri, per riciclare il codice che hai appena scritto “così comè” per un altro programma / script, per creare librerie (o librerie di snippet), per ridurre la dimensione complessiva e la relativa probabilità di errori, per eseguire il debug e il test approfondito di ogni singola parte … e ovviamente si organizzerà in logica seziona il tuo programma / script e migliora la sua leggibilità. Tutte cose che ti faranno risparmiare tempo e quindi denaro. Lo svantaggio è che devi attenersi agli standard e commentare le tue funzioni (che non hai eless to do in a working environment).

Aderire a uno standard rallenterà il tuo lavoro allinizio ma velocizzerà il lavoro di tutti gli altri (e anche il tuo) in seguito. Infatti quando la collaborazione cresce nel numero di persone coinvolte questa diventa una necessità inevitabile. Quindi, ad esempio, anche se credo che le variabili globali debbano essere definite globalmente e non in una funzione, posso capire uno standard che le inizializza in una funzione denominata declare_variables() chiamato sempre nella prima riga di main() …

Ultimo ma non meno importante, non sottovalutare la possibilità nel codice sorgente moderno editor per mostrare o nascondere routine separate selettivamente ( Code pieghevole ). Ciò manterrà compatto il codice e focalizzerà lutente risparmiando di nuovo tempo.

^{Qui sopra puoi vedere come è spiegata solo la funzione walk_into_bar(). Anche degli altri erano lunghi 1000 righe ciascuno, si poteva comunque tenere sotto controllo tutto il codice in una sola pagina. Nota che è piegata anche la sezione in cui vai per dichiarare / inizializzare le variabili.}

Un altro motivo quello che spesso viene trascurato è lanalisi della sintassi di bash:

set -eu echo "this shouldn"t run" { echo "this shouldn"t run either" 

Questo script ovviamente contiene un errore di sintassi e bash non dovrebbe “t eseguirlo affatto, giusto? Sbagliato.

~ $ bash t1.sh this shouldn"t run t1.sh: line 7: syntax error: unexpected end of file 

Se racchiudessimo il codice in una funzione, questo “non accadrebbe:

set -eu main() { echo "this shouldn"t run" { echo "this shouldn"t run either" } main 

~ $ bash t1.sh t1.sh: line 10: syntax error: unexpected end of file 

A parte le ragioni fornite in altre risposte:

9. Psicologia: un programmatore la cui produttività viene misurata in righe di codice avrà un incentivo a scrivere codice inutilmente dettagliato. Più gestione è concentrandosi sulle righe di codice, maggiore è lincentivo che il programmatore ha ad espandere il suo codice con una complessità non necessaria, il che non è desiderabile poiché una maggiore complessità può portare a un aumento dei costi di manutenzione e a un maggiore impegno richiesto per la risoluzione dei bug.
   • WP, Righe di codice sorgente; Svantaggi, n. 9

Commenti

• Non è una cattiva risposta, come dicono i voti negativi. Nota: agc dice, anche questa è una possibilità, e sì, lo è. Non ‘ dice che sarebbe lunica possibilità e non ‘ accusa nessuno, si limita a dichiarare i fatti. Anche se penso che oggi sia quasi inascoltato una ” riga di codice ” – > ” $$ ” lavoro a contratto in stile, indiretto significa che è abbastanza comune che sì, la massa del codice prodotto conta dai leader / bosses.