Lavorando su un progetto software di grandi dimensioni e a più livelli, ho appena trovato una ripetizione di anti-pattern nel codice. Non ho trovato la sua definizione in Wikipedia o in altre fonti dopo una rapida ricerca, quindi vorrei chiederti se esiste un noto anti-modello per la nostra situazione attuale. Spiegherò sia in modo generale che fornendo un esempio.
In generale, questo anti-pattern potrebbe essere chiamato come l'espressione italiana "scaricabarile" (accesa passare il dollaro , evitando la tua responsabilità e dandole a qualcun altro sotto di te).
Secisonodiversepersoneinun[sotto]progetto,esonoorganizzateinunacatenadiresponsabilità,qualcunoailivellisuperioripotrebbedecideredievitaredeliberatamentedirisolvereunproblemadiprogettazioneelasciarelarisoluzioneallapersonaaccantoalui,chipotrebberipeterloeallafine"lascia l'ultimo sviluppatore in un caos di complessità di sviluppo". L'anti-pattern appare quando viene scoperto che se la persona in cima alla catena risolve il problema da solo, molto meno lavoro e rilavorazione sarebbero stati fatti dalle persone sotto di lui.
Situazione del mondo reale (in generale): si sta sviluppando un servizio di livello intermedio che gestisce le chiamate dal front-end e deve eseguire più chiamate a diversi servizi di back-end (un DB, un servizio Web, un archivio di file, servizi in outsourcing ...) che non sono molto ben documentati. Quando ottieni un campo di input che non puoi gestire da solo, invece di chiedere ulteriori informazioni puoi semplicemente inserirlo nell'interfaccia front-middle-end e richiedere al front-end di fornirti questo parametro che verrà passato non trasformato nel back-end. Il front-end potrebbe dover eseguire diverse chiamate ai servizi per ottenere un singolo valore che potrebbe essere ottenuto dal middle-tier con poche chiamate / istruzioni.
Nel mio caso (supponendo che nell'interfaccia middle-back-tier tutti i valori siano considerati string , e per favore non commentare perché ci sono ragioni), ho scoperto che i servizi di back-end richiedono campi come order , flagDescription che può essere considerato come un'enumerazione di ascending , descending e boolean .
Uno dei problemi è codificare l'enumerazione. Cosa accetta il servizio come valori? ASC / DESC ? A / D ? 0 / 1 ? Solo gli sviluppatori BE sanno.
In effetti, alla fine abbiamo scoperto che lo sviluppatore originale di ME era troppo pigro per chiedere informazioni dettagliate sui possibili valori di questi campi. Li ha invece messi nell'interfaccia front-middle-end come due string s, lasciando i ragazzi della FE a chiedere con rabbia "dove prendiamo i valori di questi campi?".
Descriverò un altro caso con un esempio fittizio: supponiamo che un servizio back-end in outsourcing definisca un'operazione come doSomethingOnAPerson(string socialSecurityNumber, string phoneNumber, Date birthdate) , la tabella Persons DB identifica le persone con un ID univoco e contiene tutte queste informazioni. A un certo momento, FE conosce solo l'ID della persona e un gruppo di informazioni insufficienti per effettuare una chiamata completa. Tuttavia, il livello intermedio espone la stessa firma del back-end invece di un doSomethingOnAPerson(long personID) più semplice che può essere implementato come una chiamata DB seguita da una chiamata di servizio. Poiché ME è già schierata, questo costringe i ragazzi della FE a richiedere una rilavorazione per un nuovo servizio per recuperare le informazioni mancanti per chiamare i servizi di fascia intermedia, o in altri casi richiedere che il servizio venga rielaborato per cambiare la firma ed eseguire il operazione mancata. In termini generali, lo sviluppatore originale non ha avuto il tempo di risolvere il problema [molto semplice / semplificato] di ottenere le informazioni richieste dalle più piccole informazioni disponibili, ma ha deciso di passare il tempo al FE
In poche parole, un design migliore e molta più attenzione avrebbero potuto impedire le situazioni . Infatti, il primo ha anche causato problemi quando si passa da un ambiente di simulazione a test di integrazione .
Vorrei spiegare al team che abbiamo sbagliato scambiando il conto tra di noi piuttosto che risolvere i problemi.