Como trazer outras pessoas para entender sua interface

5

Estou trabalhando em uma empresa que tem dois produtos. Um é um aplicativo de desktop, o outro é um aplicativo da web. Eu estou na parte como engenheiro de back-end na aplicação web. Eu desenho as interfaces web. Usamos o SOAP como a tecnologia de interface.

Agora, conforme o produto se desenvolve, há muitas mudanças na versão atual não lançada da interface.

O aplicativo da web se desenvolve de forma mais rápida do que o aplicativo de desktop e nós criamos uma nova versão de interface apenas se tivermos acesso a ela (significa que há um aplicativo cliente-desktop que usa essa versão de interface). Mas, de vez em quando, há novos casos de uso que o aplicativo para desktop deve ser capaz de manipular. E temos que trocar novos dados para estendermos a versão atual.

Quando apresentamos a nova interface aos desenvolvedores de desktop (depois de muitas análises de negócios), eles sempre reclamam da estrutura, da nomenclatura e do conteúdo do esquema. Eles se recusam a trabalhar com isso e há muitas reuniões e conversas desnecessárias. Tecnologicamente está tudo bem, mas é como se eles não estivessem no mesmo barco.

Como seria a melhor aparência quando eu queria definir uma interface de sabão que fosse aceita tanto por desenvolvedores quanto por empresários?

Estou procurando um cenário de melhor caso para lidar com isso. Espero que quando a ideia de um fluxo de trabalho não venha de mim (o desenvolvedor) seja mais fácil para o empresário aceitá-lo.

EDIT (pergunta de acompanhamento @ k3b):

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

Como o provedor de interface, definimos a estrutura. Os desenvolvedores de desktop reclamam sobre como estruturamos o conteúdo. Existem várias maneiras possíveis e escolhemos a estrutura mais próxima do mundo real. Isso agrada principalmente os negócios, mas "ofende" os desenvolvedores. Um dos argumentos mais usados é que "geramos trabalho desnecessário para eles quando há uma maneira mais fácil (a partir de uma visão de desenvolvedores)".

Na visão técnica, eu concordo. Nós poderíamos tornar isso mais fácil. Mas devido ao fato de que a empresa não consegue ler os XSDs e a API fornecida suficientemente bem, temos que simplificá-la para eles. Então, eles podem vender as interfaces de dados para outras pessoas de negócios.

Quando criamos uma interface que favorece os desenvolvedores - os negócios não poderão lê-los (tentei).

    
por SWiggels 27.09.2016 / 08:44
fonte

2 respostas

6

Um cenário reconhecível.

Como você já tem protótipos do lado do cliente (no mínimo), crie uma (boa) API do lado do cliente e teste o código em um banco de dados de teste. Isso deve remover a distração criada pelo encanamento SOAP. Tenha um glossário definido de entidades de negócios. Documente as regras de negócios.

Uma mudança de interface deve ser compatível com versões anteriores - não é? Uma API do lado do cliente pode ocultar atributos, coletar em uma única classe de parâmetro vários atributos, para que a API permaneça sólida.

Extensões para funcionalidades específicas podem usar o padrão de adaptador / decorador.

O problema é que eles provavelmente estão mais próximos dos conceitos de negócios do mundo real do que da TI. Eles podem querer novos recursos, mas certamente não o esforço para atualizar por conta própria. E certamente não erros. Portanto, testes de unidade, dados de testes documentados e outros são importantes.

No entanto, muito não será novo.

  • Uma API cliente com ferramentas de teste e o restante proporcionam qualidade extra, ajudam o cliente e não lhe custará nada se você já estiver em testes de unidade e integração. Isso vai te salvar quando for estabelecido.
por 27.09.2016 / 09:38
fonte
0

Se for SOAP, forneça a eles um projeto de interface SOAP com vários casos de teste e solicitações que mostrem como chamar o serviço. Isso deve ser mais do que suficiente e permitirá que eles realmente enviem solicitações e analisem as respostas antes da codificação. Isso é um pouco menos abstrato que um XSD e dará a todos uma noção da estrutura de solicitação / resposta que está sendo usada.

Nomes são apenas nomes. Se eles não gostam dos nomes, pode ser alterado:

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

Então, não acho que seja um argumento válido deles. Se você estiver fazendo SOAP, tente evitar o uso de atributos e use apenas elementos, pois isso os afastará das tecnologias de serialização herdadas. Mantenha as interfaces simples e concisas.

Se eles estão realmente com pressa, tudo o que precisam fazer é apontar para o WSDL e fazer com que a pilha de tecnologia do cliente gere o código da definição do WSDL. Ou eles irão codificar manualmente eles mesmos. Qualquer método deve demorar apenas um tempo finito.

Você também pode incluí-los como parte do processo de design. Talvez eles sintam que estão recebendo uma granada sendo jogada sobre a parede. Se eles estiverem envolvidos na frente e puderem ditar parte da interface, talvez eles sejam mais receptivos a ela.

    
por 27.09.2016 / 15:47
fonte

Tags