Pode ser útil criar um aplicativo começando com a GUI?

A tendência no design e desenvolvimento de aplicativos parece estar começando com as "tripas": o domínio, o acesso a dados, a infraestrutura etc. A GUI geralmente aparece mais tarde no processo. Gostaria de saber se poderia ser útil construir a GUI primeiro ...

Minha lógica é que, ao criar pelo menos uma GUI protótipo, você obtém uma idéia melhor do que precisa acontecer nos bastidores e, portanto, está em uma posição melhor para começar a trabalhar no domínio e no código de suporte.

Percebo um problema com essa prática: se o código de suporte ainda não foi gravado, não haverá muito o que a camada da GUI realmente faça. Talvez a criação de objetos simulados ou classes descartáveis ​​(algo semelhante ao feito em testes de unidade) forneça uma base suficiente para construir a GUI inicialmente.

Essa pode ser uma ideia viável para um projeto real? Talvez possamos adicionar GDD (GUI Driven Development) ao acrônimo stable ...

Criar protótipos rápidos de GUI é uma boa ideia, e ouvi dizer que ele está sendo usado em muitos projetos. O feedback inicial é realmente valioso. No entanto, tem seus perigos:

• é muito tentador (para gerentes / usuários) usar ainda mais o código do protótipo e criar o aplicativo final, o que pode ter conseqüências muito ruins a longo prazo (isso realmente aconteceu em um dos projetos nos quais trabalhei e resultou em um produto "funcional" com arquitetura inexistente e muita dor de cabeça para manutenção)
• para o usuário médio, a GUI é o aplicativo . Assim, quando eles veem uma GUI de boa aparência, tendem a acreditar que a maior parte do trabalho real está concluído, para que possam ficar muito chateados com o "pouco trabalho restante" se arrastando por tanto tempo: - /

A atenuação desses riscos requer discussão ativa e, possivelmente, educação de seus usuários e / ou gerentes.

O problema que vejo com isso é que o objetivo parece ser totalmente atrasado.

"Minha lógica é que, ao criar pelo menos uma GUI protótipo, você obtém uma idéia melhor do que precisa acontecer nos bastidores e, portanto, está em uma posição melhor para começar a trabalhar no domínio e no código de suporte".

Essa é, na minha opinião, a maneira errada de olhar para uma camada de negócios e uma ótima maneira de encontrar um design pobre e inexpansível. Uma camada de dados bem projetada para expressar completamente os dados pode ser usada em qualquer interface do usuário. Uma camada de dados projetada para funcionar de acordo com as necessidades de uma interface do usuário específica pode não ser adaptável a qualquer outra coisa, nem mesmo a menores adições de recursos a essa interface.

A experiência com sistemas projetados da maneira como você está falando me leva a concluir que a maioria dos projetos que usam essa metodologia acaba tendo vida curta e / ou complicada. Eles também tendem a criar um acoplamento entre a interface do usuário e a camada de dados que nunca deveria estar lá.

A independência da camada de dados e da interface do usuário deve ser incentivada. É por isso que criar a camada de dados para simplesmente representar os dados inteiros, em vez de direcionar uma interface específica, simplesmente funciona melhor a longo prazo.

Construir um protótipo pode ser bom para a coleta e o acordo de requisitos, mas deve ser descartado. Na verdade, não use nada do código do protótipo no produto real.

Acho que @ Péter está certo ao sugerir que construir protótipos de GUI é uma boa idéia. Eu gostaria de complementar as possíveis armadilhas de fornecer a experiência do usuário de uma maneira invertida, ou seja, com foco nas ontologias, na arquitetura e na infraestrutura primeiro e na experiência imediata do usuário por último:

• O usuário que você enviou até o final do cronograma de desenvolvimento invalida suas estimativas dos dados e a maneira como seu aplicativo está sendo usado.
• Seus projetos elaborados que você desenvolveu prematuramente provam ser maquinações com finalidade própria e que têm pouco ou nenhum uso no final.
• Seu aplicativo pode ser levado a um estado em que oferecer experiências ruins ao usuário se torna a norma.

Você faz a coragem e, em seguida, o usuário obtém o que saiu de suas suposições, enquanto você deve se preocupar com o que o usuário precisa e construí-las de acordo. Por que as pessoas recorrem a fazê-lo ao contrário é simplesmente porque a apresentação, com a qual o usuário interage, de onde os comportamentos do aplicativo naturalmente surgem, é a parte mais complexa do sistema que nunca é totalmente explorada ou as pessoas simplesmente se sentem muito felizes em se preocupar com a construção de coisas que evitem a realmente ter que pensar por que / o quê / por quem a estão construindo. Erguer uma estrutura enorme que seja estruturalmente sólida é uma brincadeira de criança, conseguir satisfazer as necessidades funcionais (e estéticas) de todos é a parte mais difícil.

Para cada experiência craptástica, fluxo peculiar, informações mal colocadas, falta de funcionalidade óbvia, coisas simplesmente erradas, instâncias sempre que você implorou para perguntar "exatamente qual gênio inventou isso ?", Existe algo que ignorou, negou ou divulgou o usuário como a vanguarda dos esforços de desenvolvimento.

Em geral, o modelo deve ser desenvolvido antes da visualização. Depois de ter uma base lógica do seu aplicativo, você pode criar uma ou mais visualizações desse modelo (por exemplo, você pode exibir dados na tabela ou no gráfico). Geralmente, o modelo é mais importante que a GUI. Isso é especialmente verdadeiro para o desenvolvimento empresarial, em que a GUI geralmente é feita de maneira padrão.

No entanto, às vezes a GUI é realmente a parte mais importante do aplicativo. Às vezes, você deseja analisar os dados de uma maneira nova e específica - e extraí-los a partir daí, desenvolvendo o modelo. Por exemplo, o CashCurve é um aplicativo em que o ponto está na GUI, enquanto o próprio modelo de dados é um material chato padrão que qualquer um pode modelar em alguns minutos. (Isenção de responsabilidade: não sou afiliado ao CashCurve, apenas um usuário muito satisfeito.)

Isso é relevante para a criação de serviços da Web ou outras APIs - somente lá é conhecido como design " contrato primeiro ".

Portanto, quanto a tudo, não há regra sobre o que projetar primeiro; às vezes é modelo e às vezes é GUI. Como regra geral, eu recomendaria "projetar a parte mais importante primeiro".

Existem algumas ressalvas a serem consideradas ao projetar a GUI primeiro, como que o usuário provavelmente terá problemas para entender que o aplicativo está longe de ser concluído quando apenas o protótipo da GUI existe, mas outras respostas abordaram isso muito bem, portanto não entrarei em detalhes.

Eu acho que é uma maneira extremamente boa de abordar o design de aplicativos, especialmente em um ambiente de desenvolvimento ágil. A maioria dos projetos de sucesso em que trabalhei começaram com um protótipo que acabou se tornando real.

Você precisa entender que a GUI é a janela do sistema (por exemplo, banco de dados, sistema de arquivos etc.). Em uma situação em que os requisitos do projeto são tão vagos quanto uma pilha de lama, você não terá nenhuma esperança de obter uma solução correta, iniciando no back-end. Quase sempre, o desenvolvedor de back-end bem-intencionado desenvolve um monte de API que não tem relevância para as interações do usuário.

Ao iniciar na GUI, o cliente tem uma idéia melhor do que deseja. À medida que esse estágio avança, o desenvolvimento da GUI (usando zombarias e stubs) dá origem a um modelo de domínio. Esse modelo de domínio pode ser transferido para o back-end e os desenvolvedores de back-end podem começar a desenvolver a lógica persistente e transacional.

E por que você quer jogar fora o protoype? Não estamos lidando com estádios construídos com palitos de fósforo. Basta refatorar a coisa maldita em algo bom.

Não parece ruim para mim se a pessoa que olha para a GUI entende que é apenas um shell e literalmente botões e processos não funcionam (lance a nova NotImplementedException ();;)).

Se você continuar usando uma arquitetura no estilo MVC, não prevejo problemas futuros de manutenção ou construção, pois a "Visualização" não define nada desse tipo de coisa. Os "Controladores" e "Modelo" podem vir posteriormente com qualquer infraestrutura necessária para as necessidades de escalabilidade / design, etc.

Quanto à administração, desenhe para eles um grande gráfico de pizza com três partes, identifique-os como "M", "V" e "C". Dê ao V cerca de 20% e explique que o restante da torta é "TBC";).

Em qualquer sistema de tamanho razoável, o que precisa acontecer nos bastidores está vagamente relacionado à aparência da GUI. A GUI fornecerá apenas alguns dos requisitos. Geralmente, existem muitos componentes que não possuem uma GUI.

Após o desenvolvimento do sistema, interfaces adicionais (incluindo novas GUIs) podem ser necessárias. Compreender e implementar os requisitos de negócios é fundamental para que isso seja bem-sucedido.

Onde o design da GUI e outros mecanismos de entrada e saída pode ajudar na validação do modelo. Atributos que nunca são gerados podem não ser necessários. (Pode haver razões para mantê-los, mas provavelmente serão requisitos de auditoria ou reguladores.)

Como outros já mencionaram, uma vez que você tenha uma GUI funcional, muitos clientes pensam que você terminou. No entanto, você pode não ter nenhuma infraestrutura por trás disso. Os protótipos de papel podem ser uma boa opção para validar o layout e o conteúdo da GUI.

Não esqueça que pode ser necessário ajustar a interface após o desenvolvimento. Ouvi o relatório de uma falha na substituição da interface do checkout para um processo de checkout em cinco etapas. Uma interface muito mais simples não dava aos usuários a sensação adequada de segurança e tinha uma taxa de conclusão muito mais baixa. Ouça o Speed ​​Bumps: o ingrediente mágico do marketing .