Esiste un paradigma di programmazione che promuove rendere le dipendenze estremamente ovvie per gli altri programmatori?

Lavoro in un data warehouse che esegue il source di più sistemi tramite molti flussi e layer con dipendenze simili a labirinti che collegano vari artefatti. Praticamente ogni giorno mi imbatto in situazioni come questa: corro qualcosa, non funziona, passo attraverso un sacco di codice ma ore dopo mi rendo conto di essere riuscito a concettualizzare la mappa del processo di una piccola porzione di ciò che ora so nel corso della giornata è richiesto, quindi chiedo a qualcuno e mi dicono che questo altro flusso deve essere eseguito per primo e che se avessi controllato qui (indicando una parte apparentemente arbitraria di un enorme stack di altre dipendenze codificate), allora avrei Visto. È incredibilmente frustrante.

Se fossi stato in grado di suggerire al team che forse sarebbe una buona idea se avessimo fatto di più per rendere più evidenti e evidenti le dipendenze tra oggetti, piuttosto che incorporarli profondamente in livelli ricorsivi di codice, o anche nei dati che deve essere presente perché popolato da un altro flusso, forse facendo riferimento a un paradigma software ben noto, provato e testato, quindi potrei essere in grado di rendere il mio lavoro e tutti gli altri molto più semplici.

È un po 'difficile spiegare i vantaggi di questo al mio team. Tendono ad accettare le cose così come sono e non "pensano in grande" in termini di vedere i benefici di essere in grado di concettualizzare l'intero sistema in un modo nuovo - non vedono davvero che se si può modellare un sistema enorme in modo efficiente quindi rende meno probabile l'incontro con inefficienze di memoria, vincoli univoci che interrompono lo streaming e chiavi duplicate, dati senza senso perché è molto più facile progettarlo in linea con la visione originale e in seguito non incontrerai tutti questi problemi che ora stiamo vivendo, che so essere insolito rispetto ai lavori precedenti, ma che sembrano ritenere inevitabili.

Quindi, qualcuno conosce un paradigma software che enfatizza le dipendenze e promuove anche un modello concettuale comune di un sistema al fine di garantire l'adesione a lungo termine a un ideale? Al momento abbiamo praticamente un casino enorme e la soluzione che ogni sprint sembra essere "basta aggiungere questa cosa qui, qui e qui" e io sono l'unico che si preoccupa che le cose stiano davvero iniziando a crollare.

Discoverability

La sua assenza affligge molte organizzazioni. Dov'è quello strumento che Fred ha costruito di nuovo? Nel repository Git, certo. Dove?

Il modello software che viene in mente è Model-View-ViewModel. Per i non iniziati, questo modello è un mistero completo. L'ho spiegato a mia moglie come "cinque widget galleggianti sopra il tavolo che parlano tra loro tramite una forza misteriosa". Comprendi il modello e comprendi il software.

Molti sistemi software non documentano la loro architettura perché presumono che si spieghi da sé o emerge naturalmente dal codice. Non lo è e non lo è. A meno che tu non stia utilizzando un'architettura ben definita, le nuove persone si perderanno. Se non è documentato (o noto), le nuove persone si perderanno. E anche i veterani si perderanno, dopo essere stati lontani dal codice per alcuni mesi.

È responsabilità del team elaborare un'architettura organizzativa ragionevole e documentarla. Questo include cose come

• Organizzazione delle cartelle
• Riferimenti del progetto
• Documentazione di classe (cos'è, cosa fa, perché esiste, come viene usata)
• Progetto, modulo, assemblaggio, qualunque documentazione.

È responsabilità del team rendere le cose organizzate e rilevabili in modo che il team non reinventi costantemente la ruota.

A proposito, l'idea che "il codice dovrebbe essere auto-documentante" è solo parzialmente corretta. Mentre è vero che il tuo codice dovrebbe essere abbastanza chiaro in modo da non dover spiegare ogni riga di codice con un commento, le relazioni tra artefatti come classi, progetti, assiemi, interfacce e simili sono non ovvie e ancora deve essere documentato.

Il modo migliore per affrontare questo tipo di problemi è in modo incrementale. Non essere frustrato e proporre ampi cambiamenti architettonici. Quelli non verranno mai approvati e il codice non migliorerà mai. Ciò presuppone che sia persino possibile determinare le modifiche architettoniche ampie e ampie corrette da apportare, il che è improbabile.

Ciò che è probabile è che potresti determinare un piccolo cambiamento che ti avrebbe aiutato con il problema specifico che hai appena risolto. Magari invertendo alcune dipendenze, aggiungendo della documentazione, creando un'interfaccia, scrivendo uno script che avverte di una dipendenza mancante, ecc. Quindi proponi invece quel cambiamento più piccolo. Ancora meglio, a seconda della cultura della tua azienda, possono tollerare o addirittura aspettarsi che tu faccia miglioramenti del genere come parte del tuo compito originale.

Quando apporti queste piccole modifiche una parte regolare del tuo lavoro e, con il tuo esempio, incoraggi anche altri a farlo, si sommano davvero nel tempo. Molto più efficace del piagnucolio su singole modifiche più grandi che non ti è consentito apportare.

Architettura.

Non esiste un principio o una pratica unica, specifica e universale che risolva i problemi di rilevabilità e manutenibilità che si applicano a tutti gli aspetti di tutto il software. Ma, il termine generale per le cose che rendono sano un progetto è architettura.

La tua architettura è l'intero corpus di decisioni attorno a ciascun punto di potenziale (o storica) confusione, inclusa la designazione di come le decisioni sull'architettura vengono prese e documentate. Tutto ciò che riguarda il processo di sviluppo, la struttura delle cartelle, la qualità del codice, i modelli di progettazione e così via sono tutte cose che potrebbero andare nella tua architettura, ma nessuna di queste è un'architettura.

Idealmente, queste regole sono unificate da una singolarità della mente.

Un piccolo team può certamente creare un'architettura collaborativa. Ma, con opinioni diverse, questo può portare rapidamente a un'architettura molto schizofrenica che non serve a mantenere la sanità mentale. Il modo più semplice per garantire che la tua architettura, i numerosi TLA e i relativi modelli, servano tutti al successo del team con una singolarità mentale è di rendere responsabile una sola mente.

Ora, ciò non richiede necessariamente un "architetto" per pontificare . E, mentre alcuni team potrebbero desiderare che una persona esperta prenda queste decisioni, il punto principale è che qualcuno deve possedere l'architettura, specialmente quando il team cresce. Qualcuno tiene sotto controllo il polso del team, moderando discussioni sull'architettura, documentando le decisioni e monitorando le decisioni e il lavoro in corso per la conformità con l'architettura e la sua filosofia.

Non sono un grande fan di nessuna persona che prende tutte le decisioni; ma, individuando un "architetto" o "proprietario prodotto tecnico" che è responsabile per moderare le discussioni architettoniche e documentare le decisioni combatte un male maggiore: la diffusione della responsabilità che porta a nessun un'architettura riconoscibile.

Benvenuto in Ingegneria del software (in entrambi i sensi);) Questa è una buona domanda, ma in realtà non ci sono risposte facili, dato che sono sicuro che tu ne sia consapevole. È davvero un caso di evolversi in migliori pratiche nel tempo, addestrando le persone ad essere più abili (per definizione la maggior parte delle persone nel settore sono di competenza mediocre) ...

L'ingegneria del software come disciplina soffre di crearla per prima e progettare la mentalità "as-go-go-go", in parte per opportunità e in parte per necessità. È solo la natura della bestia. E, naturalmente, gli hack si costruiscono nel tempo con gli hack, poiché i suddetti programmatori mettono in atto rapidamente soluzioni funzionali che risolvono il bisogno a breve termine a scapito dell'introduzione del debito tecnico.

Il paradigma che devi usare è essenzialmente quello di ottenere persone migliori, formare le persone che hai bene e sottolineare l'importanza di dedicare tempo alla pianificazione e all'architettura. Non si può facilmente essere "Agili" quando si lavora con un sistema monolitico. Può essere necessaria una pianificazione considerevole per attuare anche piccoli cambiamenti. La realizzazione di un eccellente processo di documentazione di alto livello aiuterà anche le persone chiave a familiarizzare più rapidamente con il codice.

Le idee su cui potersi concentrare sarebbero (nel tempo, gradualmente) l'isolamento e il refactoring delle parti chiave del sistema in modo da renderle più modulari e disaccoppiate, leggibili, mantenibili. Il trucco sta nel lavorare con i requisiti aziendali esistenti, in modo che la riduzione dell'indebitamento tecnico possa essere fatta simultaneamente alla fornitura di valore commerciale visibile. Quindi la soluzione è in parte migliorare le pratiche e le competenze e in parte cercare di spostarsi maggiormente verso il pensiero architettonico a lungo termine, come posso già dire.

Si noti che ho risposto a questa domanda dal punto di vista della metodologia di sviluppo del software piuttosto che dal punto di vista della tecnica di codifica perché in realtà questo è un problema che è molto più grande dei dettagli della codifica o persino dello stile architettonico. È davvero una questione di come prevedi il cambiamento.

Mi piace l'idea delle convenzioni di @ RobertHarvey e penso che aiutino. Mi piace anche l'idea di @ KarlBielefeldt di "documentare mentre vai" e so che è essenziale perché è l'unico modo per mantenere aggiornata la documentazione. Ma penso che l'idea generale sia che documentare come trovare tutti i pezzi del codice, costruirli e distribuirli sia importante!

Di recente ho inviato per e-mail un significativo progetto open source che aveva avuto una configurazione XML che generava codice totalmente privo di documenti. Ho chiesto al manutentore: "Dove è documentato questo processo di generazione del codice XML? Dove è documentata la configurazione del database di test?" e disse: "Non lo è." È fondamentalmente un progetto a contributore singolo e ora so perché.

Senti, se sei quella persona e stai leggendo questo, apprezzo molto quello che stai facendo. Adoro praticamente i frutti delle tue fatiche! Ma se trascorri un'ora a documentare come vengono messe insieme le tue cose davvero creative, potrei passare un paio di giorni a programmare nuove funzionalità che potrebbero aiutarti. Di fronte al muro di mattoni della "mancanza di documentazione non è un problema", non ci proverò nemmeno.

In un'azienda, la mancanza di documentazione è un enorme spreco di tempo ed energia. Progetti del genere spesso vengono affidati a consulenti che costano ancora di più, solo per capire cose di base come "dove sono tutti i pezzi e come si incastrano".

In conclusione

Ciò che serve non è tanto una tecnologia o una metodologia, ma un cambiamento di cultura; una convinzione condivisa che documentare come sono costruite le cose e perché è importante. Dovrebbe far parte delle revisioni del codice, un requisito per passare alla produzione, legato agli aumenti. Quando tutti lo credono e agiscono su di esso, le cose cambieranno. Altrimenti, sarà come il mio contributo open source fallito.

Per rispondere alla domanda così come è posta (piuttosto che darti consigli per la tua situazione particolare):

Il paradigma di programmazione noto come pura programmazione funzionale richiede che tutto ciò che influenza l'output di una funzione debba essere specificato nei parametri di input. Non ci sono dipendenze nascoste o variabili globali o altre forze misteriose che agiscono invisibilmente attraverso la base di codice. Non esiste un accoppiamento temporale "devi prima fare questo".

Ogni data warehouse è diverso ma c'è molto che puoi fare per semplificarti le cose.

Per cominciare, ogni riga nel database aveva una colonna DATE_ADDED e DATA_UPDATED in modo da poter vedere quando è stato aggiunto al database e quando è stato modificato. Avevamo anche una colonna SOURCE_CODE in modo da poter tracciare dove ogni bit di dati entrava nel sistema.

Successivamente abbiamo avuto strumenti comuni che hanno funzionato in tutti i nostri data warehouse come ordinamenti, corrispondenze di tabelle, affettatrici e dadi, ecc.

Il codice su misura è stato ridotto al minimo assoluto e anche allora ha dovuto confermare vari stili di codifica e reportistica.

Presumo che tu abbia già familiarità con le suite ETL . Ci sono molte funzionalità che ottieni gratuitamente in questi giorni che non erano presenti quando ero in gioco circa un decennio fa.

Potresti anche voler esaminare i data mart per presentare una versione più amichevole e igienizzata del tuo data warehouse. Ovviamente non è un proiettile d'argento, ma potrebbe aiutare con alcuni problemi piuttosto che dover ricostruire / correggere il tuo data warehouse.

Non so quanto sia rilevante per il tuo caso, ci sono alcune strategie per rendere le dipendenze più visibili e il mantenimento generale del codice-

• Evita le variabili globali, usa invece i parametri. Questo vale anche per le chiamate tra lingue.
• Evita di cambiare / mutare i valori delle variabili, per quanto puoi. Crea una nuova variabile e, se possibile, utilizza, se necessario, per modificare il valore.
• Rendi il codice modulare. Se non è possibile descrivere cosa sta facendo (non come) in una semplice frase, suddividerla in moduli che soddisfino la condizione.
• Assegna un nome alle porzioni di codice in modo corretto. Quando puoi effettivamente descrivere cosa sta facendo una porzione di codice in termini semplici, questi termini diventano il nome della porzione. Pertanto, il codice diventa auto-documentato attraverso nomi di moduli / classi / funzioni / procedure / metodi ecc.
• Metti alla prova il tuo codice. Verifica se le entità nel tuo codice giustificano i loro nomi, discussi nel punto precedente.
• Registra gli eventi nel codice. Almeno mantenere due livelli di registro. Il primo è sempre abilitato (anche in produzione) e registra solo eventi critici. E usa l'altro per registrare praticamente tutto, ma può essere attivato o disattivato.
• Trova e usa gli strumenti adatti per navigare, mantenere e sviluppare la tua base di codice. Anche una semplice opzione "Cerca tutto" di Visual Studio Code ha reso la mia vita molto più semplice in alcuni casi.