La comunicazione eccessiva è a volte un segno di cattivo software? [chiuso]

In base alla tua descrizione del problema: "anche un leggero cambiamento nel codice interno può compromettere l'API, e quindi può rompere il software che lo sta usando.", sembra che la tua API soffra di uno o più " astrazione leaky ". Tipicamente il modo in cui questo accade è quando la tua API è semplicemente un pass-through alle strutture dati sottostanti. Ad esempio, un problema comune è che le persone utilizzano un ORM per generare un modello di dominio anemico e quindi utilizzarlo per generare un livello di servizio web. È semplice e rapido e non è necessario scrivere alcun codice, ma significa che qualsiasi modifica al modello di database si manifesta come una modifica all'API.

Come affermi: la comunicazione non è una cosa negativa di per sé, ma è brutto dover usare la comunicazione per compensare un'API instabile. È una soluzione a un sintomo del problema.

Se il tuo manager non lo capisce, probabilmente non è tecnico o non capisce l'architettura del software al livello in cui questo viene svolto. Suppongo che sto dicendo: sì, questo può essere indicativo della cattiva progettazione dell'API. Il punto delle astrazioni è di limitare l'accoppiamento ad una piccola superficie. Ciò consente ai team di lavorare in modo più efficiente poiché non devono preoccuparsi di ogni aspetto di ciò che ogni altro team sta facendo. Lo sviluppo dei microservizi è stato guidato proprio da questo problema. Per una grande organizzazione tecnologica, il costo di avere tutti i team a coordinare i loro sforzi su base costante è insostenibile. Se leggi tra le righe, vedrai che questo approccio è guidato più dai problemi organizzativi / gestionali che da quelli veramente tecnici.

Sfortunatamente, è improbabile che tu possa risolvere questo problema a meno che tu non sia un architetto o uno sviluppatore principale. Il tuo manager potrebbe influire su alcuni miglioramenti se capisce il problema. Potrebbe essere che lo faccia, ma accetta che per il momento dovrai continuare a comunicare per aggirare questo difetto nell'architettura al fine di rispettare una tempistica.

Se i tuoi clienti (sì, quelli che utilizzano il tuo servizio sono clienti, anche se si trovano nella stessa azienda), dipendono dai servizi interni, qualcosa non va.

Almeno uno di questi tieni premuto:

1. La tua interfaccia non è adeguatamente documentata.
2. La tua interfaccia fa uno scarso lavoro all'incapsulamento e all'astrazione.
3. I tuoi clienti stanno programmando usando tentativi ed errori.

La via da seguire è quindi lenta e irta di pericoli:

1. Definisci e documenta correttamente la tua interfaccia corrente.
2. Se necessario, elimina gradualmente le parti dell'interfaccia corrente e sostituiscila con una più ingegnosa.
3. Spingi in modo che i tuoi clienti siano meglio istruiti in qualche modo.

I punti di discussione per la gestione sono i soldi (risparmiati a causa della consapevolezza invece di indovinare dopo aver raccolto le prove), i soldi (risparmiati grazie a una migliore efficienza ed ergonomia) e, avete indovinato, i soldi (risparmiati a causa dei vostri colleghi stanno facendo).

Si spera che, dopo un breve periodo di tempo, i tuoi clienti possano da un programma all'altro un'interfaccia ragionevolmente stabile, riducendo la necessità di coordinare strettamente tutte le modifiche e in realtà sapere (come) farlo.

Ovviamente, potrebbe essere che le regole di business del tuo servizio cambino a causa di leggi, sanzioni di gestione o altro. In quei casi in cui non puoi semplicemente astrarlo, pensa almeno alla versione.

Quando la comunicazione è eccessiva?

Una comunicazione strong potrebbe effettivamente essere un sintomo che qualcosa non va, per esempio che un componente è stato diviso in parti ma non dovrebbe essere stato. Ma potrebbe anche essere la prova che le squadre che hanno qualcosa in comune lavorano insieme in modo molto efficace.

Quindi come fare la differenza? Non è una questione di quantità, perché IMHO, il caso più frequente è l'assenza di comunicazione: le squadre lavorano in silos pensando di vivere su un'isola. Ciò comporta sempre equivoci, sorpresa inaspettata (cosa? Hanno cambiato l'API due settimane prima del nostro rilascio?) E frustrazione.

Domande di auto-introspezione : qual è la qualità della comunicazione? È utile? È costruttivo? Qual è il tuo sentimento negativo a riguardo? Questa opinione negativa è condivisa dai tuoi compagni di squadra? E dai membri dell'altra squadra? Perché pensi "sia troppo"?

Struttura dei domini aziendali

Se esistono alcune funzionalità o parti di dominio comuni (come sembra per il tuo gateway), quale sarebbe la soluzione migliore secondo te: ripetere / riutilizzare / reinventare un nuovo gateway per ogni prodotto o isolare la funzionalità?

Quindi forse il componente condiviso è esattamente l'architettura necessaria e il tuo team è la chiave per il successo di tutti gli altri. Ma se tutti gli altri fanno affidamento su di esso, non è normale che li coinvolgano come parti interessate nella decisione? Dopotutto, se tu fossi in un team di applicazioni, avresti frequenti incontri con i tuoi clienti per raccogliere i requisiti, demo di nuovi utenti e raccogliere le loro impressioni!

Domande di auto-introspezione : la comunicazione è utile, ad esempio riguardo ai requisiti e alle interdipendenze? O il tuo team non ha il coraggio di prendere alcune decisioni da solo e coinvolge eccessivamente le parti interessate nelle decisioni dei team?

Qualità?

La cattiva qualità, ad esempio se vengono consegnati troppi bug, potrebbe causare ulteriori richieste dagli altri team. Questo sarebbe un tipo di comunicazione che è il sintomo di un cattivo software.

Bad design pure. Se il tuo componente non è SOLIDO, tu e il tuo cliente avrete discussioni inutili, dovute ad esempio ad un accoppiamento stretto che potrebbe essere evitato con la segregazione dell'interfaccia e l'inversione di dipendenza.

Le informazioni mancanti potrebbero anche causare artificialmente un'eccessiva comunicazione. Una buona documentazione di riferimento (attenzione: non sovra-documentare ;-)) e alcune note di rilascio possono davvero aiutare ad evitare discussioni inutili.

Domande di auto-introspezione : sei orgoglioso di ciò che offri? E ti piacerebbe consumare il gateway se fossi in un'altra squadra?

Conclusioni

Con le poche informazioni che ho, è difficile dare un'opinione obiettiva su ciò che sta accadendo.

Ma l'eccesso di comunicazione non è necessariamente un problema di progettazione del software. Può essere un problema con le pratiche di comunicazione e collaborazione. Fortunatamente, questi possono essere migliorati se c'è consapevolezza.