Mantendo o "código" longe dos designers?

Eu construo vários projetos com um amigo meu, mas sempre chegamos à mesma armadilha repetidamente. Eu sei escrever PHP, Javascript e tudo o mais (também sei CSS e HTML) para que eu possa fazer a maior parte do trabalho quando se trata de construir a funcionalidade real. No entanto, ele não pode, mas ele pode fazer algo que eu mal posso: criar os sites.

Mas sempre que deparamos com um problema, já que ele não sabe escrever código, isso geralmente atrasa bastante o nosso desenvolvimento. No momento, este é o nosso fluxo de trabalho:

1. Criamos um recurso
2. Ele cria o design do front-end (onde deve ser colocado, como ficará, etc.)
3. Ele envia o modelo completo para mim (a exportação HTML do Pinegrow)
4. Eu procuro as alterações que ele fez e as implementa no site real (há algumas semanas, eu uso o CakePHP para isso).
5. quando algo não funciona como planejado (como por exemplo, não funcionou como planejado por algum motivo), eu corrijo o problema do meu lado e depois enviei o modelo de volta
6. enxaguar e repetir

Esse processo, como se poderia imaginar, é minuciosamente lento e ineficiente. Então, minha pergunta é: como podemos tornar esse processo mais suave? Eu já vi muitas coisas sobre isso que devemos usar React e RESTful e o que não, mas queremos usar o CakePHP para isso. Algumas pessoas poderiam me orientar sobre alguns recursos úteis sobre isso? Estou procurando por isso há um tempo, mas nunca cheguei a uma solução decente para isso.

Basicamente, tudo que meu parceiro pode fazer é criar o site. Ele não pode usar o Docker (eu uso o Docker o tempo todo), PHP, Javascript e praticamente qualquer outra coisa (ele conhece algum CSS, mas trabalha principalmente com um WYSIWYGeditor). Estou disposto a aprender isso com ele, mas ele é não estou interessado (então eu respeito isso). Espero que alguém aqui possa me ajudar (e provavelmente outros que virão depois dessa pergunta) a resolver isso, pois acho que isso é algo importante.

Deseja liberar seu Front End Designer do código? Deseja acelerar a integração? Deseja usar as técnicas profissionais usadas pelos sites mais sofisticados? De longe, a melhor ferramenta para isso é:

Pintura.

Sim pinte. Bem, algum programa de desenho de qualquer maneira. Deixe-o tirar capturas de tela do seu site, mudar as coisas e adicionar coisas que encontrar em outros lugares. Isso permitirá que ele trabalhe na velocidade de suas idéias e liberte você para dobrar o código da forma que for melhor para você, dando a ele o que ele precisa.

Se ainda estiver muito lento, digamos, porque o cliente está na sala com os dois, recomendo um conjunto de ferramentas muito mais avançado:

Papel, tesoura e fita adesiva.

Talvez uma caneta, se você estiver se sentindo ambicioso.

Eu usei essa técnica para obter com êxito decisões sobre o tema, estilo, conteúdo e principais recursos de um site em uma mesa em um Pão Panera com um cliente antes que alguém percebesse que tínhamos terminado de comer.

Isso o tornará rápido, libertará você de seu "código" e é realmente a maneira mais poderosa de desenvolver uma interface de usuário. Ele pode começar a fazer testes de usabilidade antes de escrever uma linha de código.

Você pode estar pensando "oh, isso é bom ao começar, mas você não usa isso quando o site é desenvolvido". Não é verdade. Funciona tão bem em sites estáveis. Mas agora a maioria das capturas de tela vem de seu próprio site.

E se o seu Front-end Designer quiser usar algumas ferramentas de geração de código para fazer seus mock-ups? Tudo bem, mas não pense por um segundo que você precisa usar o "código" dele. O que você precisa respeitar são as decisões dele sobre aparência, fluxo e apresentação. O que acontece por trás da cortina para que isso aconteça não é sua área de especialização. É seu. Assuma a responsabilidade por isso.

Apenas respeite o trabalho dele o suficiente para que, quando terminar, mostre a ele como acabou. Deixe-o escolher tudo o que o usuário experimentará. Esteja preparado para ser atingido por novas idéias.

Este é um desenvolvimento iterativo. Não faça muito antes de perguntar. Faça o mínimo que puder. Pergunte sempre que puder. Coloque brinquedos em sua mesa para mantê-lo entretido enquanto você implementa a idéia mais recente para que ele possa revisá-lo assim que carregar. Continue assim até a hora de encontrar o cliente.

Se o código que o Front End Designer produz realmente vale a pena, então você precisa aprender a integrar seu código ao dele. Por isso, recomendo fortemente que você aprenda o controle da fonte . Aprenda tão bem que você pode ensinar seu Front End Designer como usá-lo.

Somente quando os dois puderem usar com confiança uma ferramenta de controle de origem, recomendo que você baseie seu plano de integração na mesclagem de código. Nesse ponto, seu amigo merece uma alteração de título de Front End Designer para Front End Developer.

Agora, mesmo que você faça isso, não me surpreenderia se a técnica de rabiscar na tela ainda não fosse a maneira mais rápida de vocês colaborarem.

Talvez você não consiga suportar o caos de todas essas mudanças. Está criando muito trabalho. Bem, isso se chama software porque aceita mudanças. Caso contrário, teríamos um engenheiro elétrico fazendo isso em um chip especializado. Pode ser que você precise entrar em contato com o arquiteto para mover sua lógica de comportamento para fora da interface do usuário para que as alterações na interface do usuário não afetem suas regras de negócios principais. Se você acelerar o Front End Designer, precisará estar pronto para acompanhá-lo.

A única boa razão para forçar um Front End Designer a produzir código é porque você está cansado e deseja atrasá-lo. Bem, acho que essa não é realmente uma "boa" razão.

Em termos de ferramentas, o fluxo de trabalho ideal que eu vejo está usando o Sketch e o Zeplin. O Sketch é uma ferramenta de design direta. Equivalente ao Photoshop ou InDesign, mas otimizado para o design de aplicativos e sites. Zeplin é uma ferramenta para compartilhar e aprovar projetos no Sketch (ou Photoshop). Ele pode fornecer medições precisas de pixel e até trechos de código para CSS ou outro código de layout e exportar ativos gráficos. Depois que um design é definido, ele é entregue ao desenvolvedor. Neste ponto, o desenvolvedor pega e cria a interface do usuário. Em seguida, ele pode voltar ao designer para controle de qualidade visual. Qualquer coisa que ele achar errado, deve ser registrada como um bug para ser priorizada e resolvida por você.

quando algo não funciona como planejado (como por exemplo, não funcionou como planejado por algum motivo), eu corrijo o problema do meu lado e depois enviei o modelo de volta

Essa é a raiz dos seus problemas. O fluxo do design deve sempre ser Designer to Developere nunca invertido. Revisões e alterações deveriam ter sido feitas pelo designer e depois enviadas a você para implementação no site. Você sempre pode fazer correções rápidas, mas tente aceitar que essas correções rápidas são apenas temporárias. O designer precisa voltar aos seus projetos e descobrir a solução adequada. Ele então envia a mudança para você, e se for igual à sua solução rápida, será ótimo, caso contrário, você atualizará os designs dele.

Ele envia o modelo completo para mim (a exportação HTML do Pinegrow)

Não fique viciado em receber HTML com o qual possa trabalhar. É melhor se você implementar a tecnologia do site (Bootstrap, CSS, jQuery, React, PHP, etc .. etc .. etc ..) da maneira que você precisar. Você então reproduz os desenhos dele usando essas ferramentas. Se o HTML que ele fornece é um começo rápido , é ótimo, mas mais tarde, à medida que o projeto cresce, não será de muita utilidade. Você precisará fazer as alterações sozinho, porque apenas você entende o seu mecanismo de modelagem (por exemplo, visualizações do CakePHP, modelos, plugins, componentes, etc. etc.)

Esse processo, como se poderia imaginar, é minuciosamente lento e ineficiente.

Sempre foi assim. Designers não são programadores. Eles levam um tempo para descobrir o que funciona melhor para o usuário e, às vezes, cometem erros. Eles não entendem conceitos como componentes, estruturas e outros. Como programador, você precisa falar com seu designer e compartilhar como eu implemento o que você cria .

O designer está preso no meio. Por um lado, eles devem agradar às necessidades do programador e, por outro lado, devem agradar às necessidades do usuário.

Então, minha pergunta é: como podemos tornar esse processo mais suave?

Descobri que sentar-se fisicamente ao lado do designer e da programação realmente ajuda na comunicação. Se vocês dois estão trabalhando remotamente, mantenha o horário de funcionamento em funcionamento por alguns dias. Isso realmente ajuda a acelerar as coisas.

Eu já vi muitas coisas sobre isso que devemos usar React e RESTful e o que não, mas queremos usar o CakePHP para isso.

O CakePHP é um dos melhores frameworks do planeta (divulgação completa, estou no time principal do CakePHP).

Cake é uma estrutura de desenvolvimento para coelhos, na qual os recursos são projetados para criar sites rapidamente. Sei que isso soa como um discurso de vendas, mas é assim que é classificado. Existem muitas outras estruturas que são classificadas como coelho. Java seria um exemplo de uma estrutura que é mais corporativa que um coelho. Se você estivesse usando esse idioma, eu recomendaria mudar. Desde que você está usando o CakePHP. Eu diria que você deveria ficar com isso.

O CakePHP cria um bom servidor de back-end se você precisar de APIs RESTful.

React / Angular / Vue são todos os frameworks de front-end populares e populares, mas eles não existem há muito tempo. O CakePHP, por outro lado, existe há mais de 13 anos. Meu ponto não é uma crítica. É o fato de que essas bibliotecas JavaScript têm uma vida útil curta. Em 5 anos, todos estaremos falando sobre algo novo, mas eu suspeito que o CakePHP ainda estará por aí.

Então eu digo. Use React / Angular / Vue agora enquanto estiverem quentes, mas não se comprometa com eles. Algo novo e melhor virá em breve. Acho que agora vivemos em um mundo onde você não pode criar bons sites sem eles.

Algumas pessoas poderiam me orientar sobre alguns recursos úteis sobre isso?

Os pedidos de listas estão fora do tópico aqui. Desculpe.

EDIT :

Perdi a parte sobre o rastreamento de alterações de design.

Peça ao seu designer que salve sua saída HTML no BitBucket (eles têm repositórios particulares gratuitos). Você pode acompanhar e fazer comparações usando o site do BitBucket. Sempre que o designer faz uma grande alteração, ele adiciona uma nova ramificação com um número de versão.

Deve ser relativamente fácil para ele fazer isso, e isso permitirá que você tenha um lugar para comentar sobre as alterações. Por exemplo; ele pode fazer uma solicitação pull para atualizar o repositório no qual você executa uma revisão das alterações antes que elas sejam mescladas.

Você precisa separar essas duas coisas:

1. Design de UX e UI, uma atividade sem codificação
2. Implementação, definitivamente uma atividade de codificação

O designer deve usar ferramentas criativas como a Marvel, que são apenas para o design. Não deve ser preocupação do designer fazer nada com código, HTML, CSS etc. As cores, dimensões, estética, interações, animações são todas as coisas em que ele deve se concentrar.

O programador deve receber os ativos e a maquete (com interações e animações) e deve fazer isso programando o software. Isso incluía HTML e CSS também. O programador também pode usar ferramentas geradoras ao seu lado.

Para acelerar o fluxo de tarefas, recomendo usar uma ferramenta mínima como o Trello e vincular / documentar tudo para cada unidade de trabalho.

como podemos tornar esse processo mais suave?

Insista no controle de versão

Universidades de ramificação e paralelas de software

• Trabalhe em nenhum código que não esteja no controle de versão. ponto final. Quero dizer, entrar em greve até que o projeto esteja em um VCS.
• Ramifique formalmente, liberalmente, localmente
  • Formalmente: ramificação para liberações e sub-partes de liberações, correção formal de teste, etc. Evolua um plano formal de controle de versão, ou seja, anote-o.
  • Liberalmente: além da numeração formal de liberação em quatro partes, ramifique se seu intestino lhe disser que pode ser uma boa idéia.
  • Localmente: mantive um repositório pessoal com filiais nunca destinadas ao consumo da equipe, porque como equipe não ramificamos a princípio, e muitas vezes tenho experimentos, exploração, apenas no caso, etc.

Projete suas APIs de middleware

Benefícios:

• Estabilidade - mesmo quando o código subjacente está evoluindo.
• Código testável
• Reuso
• Uma ferramenta de comunicação em equipe
• É um contrato. Uma promessa de serviços prestados (trocadilhos)
• Codificação no domínio do SOLID == programador de manutenção feliz

É a pergunta, não diga o princípio aplicado da maneira obsessiva e compulsiva que deveria ser. Se a interface do usuário estiver manipulando uma única propriedade da camada de negócios, isso está errado.

Tudo e qualquer coisa sobre os objetos de negócios devem estar nos referidos BOs. Até coisas triviais que podem parecer melhores na interface do usuário - até mesmo um único LOC. Minuita, como adicionar 2 valores fornecidos pelo usuário - toda a lógica associada, incluindo a validação, deve estar na API da camada de negócios. Às vezes, a redundância da IMO é boa. Para mitigar a redundância, talvez tenha pequenos objetos de camada de negócios focados aos quais a interface do usuário tenha acesso total.

Tudo e qualquer coisa que a interface do usuário precise dos objetos de negócios devem ter API. Por exemplo, tenha métodos explícitos que conectem seus argumentos aos manipuladores de eventos.

Cuidado com estruturas como uma muleta

Nas mãos dos não qualificados, estruturas e IDEs não são barreiras para os monstros de filmes B que eles criam.

Com estruturas como React, você pode dizer que é tudo do lado do cliente, não há camada de lógica de negócios de back-end. A idéia principal aqui é separar o que o usuário vê do que o programa faz. Isso é factível. Não é apenas uma coisa de servidor físico versus navegador de usuários.

Eu acho que é um bom indicador da imaturidade da profissão e da prática que aceitamos que as pessoas que projetam não podem fazer.

Isso não seria aceitável em quase nenhuma outra profissão.

É razoável esperar que um designer especializado em design de site / aplicativo conheça CSS e HTML suficientemente bem para fornecer arquivos de trabalho e utilizáveis ​​desse tipo.

Os designers que fornecem editores gráficos WYSIWYG são designers visuais ou gráficos. Existem muitos tipos diferentes de designers.

No entanto, também existem muitos tipos diferentes de níveis, habilidades e experiências. Quem projeta móveis pode fazê-lo exclusivamente em um computador com ferramentas de design 3D; nesse caso, o conhecimento de como transformar um torno ou operar um roteador CNC pode ser totalmente teórico. Eles fazem seus desenhos e depois os enviam para serem feitos por outros.

Por outro lado, alguns designers especializados podem ter controle sobre todo o processo e ter a capacidade e o conhecimento para construir seus móveis de olho em cada detalhe, talvez até em artesanato.

Você não será capaz de convencer seu amigo a mudar sua maneira de trabalhar. Se você preferir ter um web designer com habilidades em HTML e CSS para criar seus próprios designs, precisará encontrar um.