Come portare gli altri a capire la tua interfaccia

Question

Come portare gli altri a capire la tua interfaccia

#1 da (6 voti)
#2 da (0 voti)

5

Sto lavorando in una società che ha due prodotti. Una è un'applicazione desktop, l'altra è un'applicazione web. Sono nella parte come tecnico di back-end sull'applicazione web. Progetto le interfacce web. Utilizziamo SOAP come tecnologia di interfaccia.

Ora che il prodotto si sviluppa ci sono molti cambiamenti nella versione attuale dell'interfaccia non pubblicata.

L'applicazione web si sviluppa molto più velocemente rispetto all'applicazione desktop e creiamo una nuova versione dell'interfaccia solo se ci viviamo con esso (significa che c'è un'applicazione cliente-desktop che utilizza questa versione dell'interfaccia). Ma di tanto in tanto ci sono nuovi casi d'uso che l'app desktop dovrebbe essere in grado di gestire. E dobbiamo scambiare nuovi dati in modo da estendere la versione corrente.

Quando presentiamo la nuova interfaccia agli sviluppatori desktop (dopo molte revisioni aziendali) si lamentano sempre della struttura, della denominazione e del contenuto dello schema. Si rifiutano di lavorarci e ci sono un sacco di incontri e discorsi inutili. Tecnologicamente va tutto bene, ma è come se non fossero sulla stessa barca.

Come apparirebbe nel migliore dei casi quando voglio definire un'interfaccia per il sapone che sia accettata da sviluppatori e uomini d'affari?

Sto cercando uno scenario migliore per come gestirlo. Spero che quando l'idea di un flusso di lavoro funzionante non venga da me (lo sviluppatore) è più facile per l'uomo d'affari accettarla.

EDIT (@ k3b follow up question):

they always complain about the structure, naming and content of the scheme

Come fornitore di interfacce definiamo la struttura. Gli sviluppatori di desktop si lamentano di come abbiamo strutturato il contenuto. Ci sono diversi modi in cui è possibile e scegliamo la struttura più vicina al mondo reale. Questo fa piacere agli affari principalmente ma "offende" gli sviluppatori. Uno degli argomenti più usati è che "generiamo lavoro non necessario per loro quando ci sarebbe un modo più semplice (da una vista sviluppatori)".

Nella vista tecnica sono d'accordo. Potremmo renderlo più facile. Ma a causa del fatto che l'azienda non può leggere gli XSD e l'API fornita abbastanza bene, dobbiamo semplificarla per loro. Quindi possono vendere le interfacce dati ad altri uomini d'affari.

Quando creiamo un'interfaccia che favorisce gli sviluppatori, l'azienda non sarà in grado di leggerla (ho provato).

interfaces

posta SWiggels 27.09.2016 - 08:44

fonte

2 risposte

0

Se è SOAP, fornire loro un progetto dell'interfaccia utente SOAP con diversi casi di test e richieste che mostrano come chiamare il servizio. Questo dovrebbe essere più che sufficiente e permetterà loro di inviare effettivamente richieste e guardare le risposte prima della codifica. Questo è un po 'meno astratto di un XSD e darà a tutti un senso della struttura richiesta / risposta che viene utilizzata.

I nomi sono solo nomi. Se non gli piacciono i nomi può essere cambiato:

[DataMember(Name="YourAPIName")]
public string ThierClientName {get; set;}

Quindi, non penso che sia un argomento valido da parte loro. Se stai facendo SOAP, prova ad evitare di utilizzare gli attributi e utilizzare solo elementi, in quanto ciò li allontanerà dalle tecnologie di serializzazione precedenti. Mantieni le interfacce semplici e concise.

Se sono davvero di fretta, tutto ciò che dovrebbero fare è puntare al WSDL e fare in modo che lo stack tecnologico del client generi il codice dalla definizione WSDL. Oppure lo codificheranno manualmente da soli. Entrambi i metodi dovrebbero richiedere solo una quantità limitata di tempo.

Potresti includerli anche come parte del processo di progettazione. Forse sentono di ricevere una granata lanciata sul muro. Se sono coinvolti in prima linea e sono autorizzati a dettare alcune delle interfacce, forse sarebbero più ricettivi ad esso.

risposta data 27.09.2016 - 15:47

fonte

Leggi altre domande sui tag interfaces

Tipi di reso dettagliati Che lingua usano le aziende come la NASA per creare le loro applicazioni? [duplicare]

score 6 · Accepted Answer

Uno scenario riconoscibile.

Dato che hai già prototipi lato client (come minimo), crea una (piacevole) API lato client e prova il codice su un database di test. Ciò dovrebbe rimuovere la distrazione creata dall'impianto idraulico SOAP. Avere un glossario definito di entità bussiness. Documenta le regole aziendali.

Un cambio di interfaccia dovrebbe essere retrocompatibile - non è vero? Un'API lato client può nascondere attributi, raccogliere in una singola classe di parametri diversi attributi, quindi l'API rimane solida.

Le estensioni per funzionalità specifiche potrebbero utilizzare il modello adattatore / decoratore.

Il problema è che probabilmente sono più vicini ai concetti di business del mondo reale che all'IT. Potrebbero volere nuove funzionalità, ma certamente non lo sforzo di aggiornare da sole. E certamente non errori. Quindi i test unitari, i dati dei test documentati e simili sono importanti.

Comunque molto non sarà nuovo.

Un'API client con strumenti di test e il resto darà una qualità extra, aiuterà il cliente e non ti costerà nulla se sei già in unità e test di integrazione. Ti salverà, una volta stabilito.