Esiste un paradigma di programmazione che promuove la creazione di dipendenze estremamente ovvie per altri programmatori?

Discoverability

La sua assenza affligge molte organizzazioni. Dov'è lo strumento che Fred ha ricostruito? Nel repository Git, sicuro. Dove?

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

Molti sistemi software non riescono a documentare la loro architettura perché presumono che sia auto-esplicativa o emerga naturalmente dal codice. Non lo è, e non lo è. A meno che tu non stia usando un'architettura ben definita, le nuove persone si perderanno. Se non è documentato (o conosciuto), le nuove persone si perderanno. E anche i veterani si perderanno, dopo che sono stati lontani dal codice per alcuni mesi.

È responsabilità del team trovare una ragionevole architettura organizzativa e documentarla. Ciò include cose come

• Organizzazione cartelle
• Riferimenti al progetto
• Documentazione di classe (cosa è, 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 reinventhi costantemente la ruota.

A proposito, l'idea che "il codice dovrebbe essere auto-documentante" è solo parzialmente corretta. Anche se è vero che il tuo codice dovrebbe essere abbastanza chiaro da non dover spiegare ogni linea di codice con un commento, le relazioni tra artefatti come classi, progetti, assiemi, interfacce e simili sono non ovvi e devono ancora essere documentati.

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

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

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

Architettura.

Non esiste un singolo principio o pratica singola, specifica che risolva i problemi di rilevabilità e manutenibilità che si applicano a tutti gli aspetti di tutto il software. Ma il termine generico per il materiale che rende sano un progetto è architettura

La tua architettura è l'intero corpo di decisioni attorno a ogni punto di potenziale (o storica) confusione - compresa la designazione di come le decisioni architetturali vengono prese e documentate. Tutto ciò che riguarda il processo di sviluppo, la struttura delle cartelle, la qualità del codice, i pattern di progettazione e così via sono tutte cose che potrebbero andare in la tua architettura, ma nessuna di esse è un'architettura .

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

Una piccola squadra può certamente creare un'architettura collaborativa. Ma, con opinioni diverse, questo può portare rapidamente a un'architettura schizofrenica molto che non serve a mantenere la tua sanità mentale. Il modo più semplice per garantire che la tua architettura, e i molti TLA e i relativi pattern, servano tutti al successo del team con una singolarità della mente è di affidarsi a una singola mente responsabile.

Ora che non richiede necessariamente un "architetto" per pontificare . E, mentre alcune squadre potrebbero volere che una persona esperta prenda semplicemente queste decisioni, la prima Il punto è che qualcuno deve possedere l'architettura, specialmente quando il team cresce. Qualcuno tiene il dito sulle pulsazioni del team, moderati dibattiti architettonici, decisioni sui documenti e monitora le decisioni e progredisce verso il rispetto dell'architettura e della sua etica.

Non sono un grande fan di una persona che prende tutte le decisioni; ma, identificando un "architetto" o "proprietario di un prodotto tecnico" che è responsabile della moderazione delle discussioni architettoniche e delle decisioni di documentazione, combatte un male più grande: la diffusione della responsabilità che porta all'architettura discernibile no .

Benvenuti in Ingegneria del software (in entrambi i sensi);) Questa è una buona domanda, ma in realtà non ci sono risposte facili, come sono sicuro che voi siate a conoscenza. Si tratta in realtà di evolvere verso pratiche migliori nel tempo, addestrando le persone ad essere più abili (per definizione la maggior parte delle persone nel settore è una competenza mediocre) ...

L'ingegneria del software come disciplina soffre di prima costruirla e progettarla mentalmente, parte per convenienza e parte per necessità. È solo la natura della bestia. E naturalmente gli hacker si basano su hack nel tempo, poiché i suddetti programmatori implementano rapidamente soluzioni funzionali che risolvono la necessità a breve termine spesso al costo di introdurre il debito tecnico.

Il paradigma che devi utilizzare è essenzialmente quello di ottenere persone migliori, formare le persone che hai a disposizione e sottolineare l'importanza di occupare il tempo della pianificazione e dell'architettura. Non si può facilmente essere quel "Agile" quando si lavora con un sistema monolitico. Può richiedere una pianificazione considerevole per mettere in atto anche piccole modifiche. Ottenere un ottimo processo di documentazione di alto livello aiuterà anche le persone chiave a gestire il codice più rapidamente.

Le idee su cui potresti focalizzarti sarebbero (col tempo, gradualmente) isolando e riattribuendo le parti chiave del sistema in un modo che le rende più modulari e disaccoppiabili, leggibili e manutenibili. Il trucco sta nel lavorare in questo modo con i requisiti aziendali esistenti, in modo che la riduzione del debito tecnico possa essere eseguita simultaneamente con la fornitura di valore commerciale visibile. Quindi la soluzione è in parte migliorando le pratiche e le competenze e in parte cercando di orientarsi maggiormente verso il pensiero architettonico a lungo termine, come posso già dire.

Nota che ho risposto a questa domanda da una prospettiva metodologica di sviluppo del software piuttosto che da una prospettiva tecnica di codifica, perché in realtà questo è un problema molto più grande dei dettagli della codifica o persino dello stile architettonico. È davvero una questione di come pianifichi il cambiamento.

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

Recentemente ho inviato per e-mail un significativo progetto open source che aveva avuto una configurazione XML che ha generato codice completamente privo di documenti. Ho chiesto al manutentore, "Dove viene documentato questo processo di generazione del codice XML? Dove viene documentata la configurazione del database di test?" e lui disse: "Non lo è". È fondamentalmente un progetto a contribuzione singola e ora so perché.

Guarda, se sei quella persona e stai leggendo questo, apprezzo molto quello che stai facendo. Adoro praticamente i frutti delle tue fatiche! Ma se hai passato un'ora a documentare come sono state create le tue cose veramente creative, potrei passare un paio di giorni a codificare nuove funzionalità che potrebbero aiutarti. Di fronte al muro di mattoni di "mancanza di documentazione non è un problema", non ho intenzione di provare.

In un'azienda, la mancanza di documentazione è un enorme spreco di tempo ed energia. Progetti come questo spesso vengono estrapolati da consulenti che costano ancora di più, solo per poter capire cose di base come "dove sono tutti i pezzi e come si adattano".

In conclusione

Ciò di cui c'è bisogno non è tanto una tecnologia o una metodologia, ma un cambiamento culturale; una convinzione condivisa che documenta come vengono costruite le cose e perché è importante. Dovrebbe essere parte delle revisioni del codice, un requisito per passare alla produzione, legato ai rilanci. Quando tutti lo credono e agiscono, le cose cambieranno. Altrimenti, sarà come il mio contributo open source fallito.

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

Il paradigma di programmazione noto come pure functional programming 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 c'è alcun "devi fare questo primo" accoppiamento temporale.

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

Per cominciare, ogni riga del database aveva una colonna DATE_ADDED e DATA_UPDATED in modo da poter vedere quando è stata aggiunta al database e quando è stata modificata. Disponevamo anche di una colonna SOURCE_CODE in modo da poter tracciare dove ogni bit di dati è entrato nel sistema.

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

Il codice su misura è stato mantenuto al minimo e anche in quel caso, ha dovuto confermare vari stili di codifica e reporting.

Presumo che tu abbia già familiarità con le suite ETL . In questi giorni c'è un sacco di funzionalità gratuite che non erano presenti quando ero in gioco circa dieci anni fa.

Potresti anche voler consultare 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 la manutenzione generale del codice -

• Evita le variabili globali, usa invece i parametri. Questo vale anche per le chiamate in lingue diverse.
• Evita di modificare / mutare i valori delle variabili, il più possibile. Crea una nuova variabile e usala, quando è necessario modificare il valore, se possibile.
• Rendi il codice modulare. Se non è possibile descrivere quale parte (non come) sta effettivamente facendo in una frase semplice, suddividila in moduli che soddisfano 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, quei termini diventano il nome della porzione. Quindi, il codice diventa auto-documentante attraverso i nomi di moduli / classi / funzioni / procedure / metodi ecc.
• Verifica il tuo codice. Verifica se le entità nel tuo codice giustificano il loro nome, discusso nel punto precedente.
• registra gli eventi nel codice. Almeno mantieni due livelli di log. 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 sfogliare, mantenere e sviluppare il tuo codebase. Anche una semplice opzione "Cerca tutto" di Visual Studio Code mi ha reso la vita molto più semplice in alcuni casi.