Garder le «code» loin des concepteurs?

Je construis pas mal de projets avec un de mes amis, mais nous revenons toujours au même piège encore et encore. Je sais écrire PHP, Javascript et tout ça (je connais aussi CSS et HTML) donc je peux faire la plupart du travail quand il s'agit de construire la fonctionnalité réelle. Cependant, il ne peut pas, mais il peut faire quelque chose que je peux à peine faire: concevoir les sites.

Mais à chaque fois, nous tombons sur un problème, car il ne sait pas écrire du code, cela ralentit généralement un peu notre développement. En ce moment, c'est notre flux de travail:

1. Nous proposons une fonctionnalité
2. Il construit le design frontal (où il doit être placé, à quoi il ressemblera, etc.)
3. Il m'envoie le modèle complet (l'export HTML de Pinegrow)
4. Je cherche les modifications qu'il a apportées, puis les implémente dans le site actuel (depuis quelques semaines, j'utilise CakePHP pour cela).
5. lorsque quelque chose ne fonctionne pas comme prévu (comme par exemple, cela n'a pas fonctionné comme nous l'avions prévu pour une raison quelconque), je résout le problème de mon côté, puis je lui renvoie le modèle
6. rincer et répéter

Ce processus, comme on pourrait l'imaginer, est extrêmement lent et inefficace. Ma question est donc la suivante: comment rendre ce processus plus fluide? J'ai vu beaucoup de choses à ce sujet que nous devrions utiliser React et utiliser RESTful et ce qui ne l'est pas, mais nous voulons utiliser CakePHP pour cela. Certaines personnes pourraient-elles me guider vers des ressources utiles à ce sujet? Je le cherche depuis un moment maintenant, mais je n'ai jamais trouvé de solution décente pour cela.

Fondamentalement, tout ce que mon partenaire peut faire est de concevoir le site. Il ne peut pas utiliser Docker (j'utilise Docker tout le temps), PHP, Javascript et à peu près tout le reste (il connaît du CSS, mais travaille principalement avec un WYSIWYGéditeur), je suis prêt à l'apprendre, mais il est pas intéressé (donc j'ai du respect). J'espère que quelqu'un ici pourrait m'aider (et probablement d'autres à venir par cette question plus tard) avec cela car je pense que c'est une chose assez importante.

Vous voulez libérer votre Front End Designer du code? Vous voulez accélérer l'intégration? Vous souhaitez utiliser les techniques professionnelles utilisées par les sites Web les plus astucieux? De loin, le meilleur outil pour cela est:

Peindre.

Oui Paint. Eh bien, un programme de dessin de toute façon. Laissez-le prendre des captures d'écran de votre site, déplacer des éléments et ajouter des éléments qu'il trouve ailleurs. Cela lui permettra de travailler à la vitesse de ses idées et vous permettra de plier le code dans la forme qui vous convient le mieux tout en lui donnant ce dont il a besoin.

Si c'est encore trop lent, par exemple parce que le client est dans la pièce avec vous deux, je recommande un ensemble d'outils beaucoup plus avancé:

Papier, ciseaux et ruban adhésif.

Peut-être un stylo si vous vous sentez ambitieux.

J'ai utilisé cette technique pour réussir à prendre des décisions sur le thème, le style, le contenu et les principales fonctionnalités d'un site à une table dans un Panera Bread avec un client avant que quiconque ne se rende compte que nous avions fini de manger.

Cela le rendra rapide, cela vous libérera de son "code", et c'est en fait le moyen le plus puissant pour développer une interface utilisateur. Il peut commencer à faire des tests d'utilisabilité avant d'avoir écrit une ligne de code.

Vous pensez peut-être "oh c'est bien au début mais vous ne l'utilisez pas une fois le site développé". Pas vrai. Cela fonctionne aussi bien sur des sites stables. Mais maintenant, la plupart des captures d'écran proviennent de votre propre site.

Et si votre Front End Designer veut utiliser des outils de génération de code pour réaliser ses maquettes? Très bien, mais ne pensez pas une seconde que vous devez utiliser son "code". Ce que vous devez respecter, ce sont ses décisions concernant l'apparence, le flux et la présentation. Ce qui se passe derrière le rideau pour que cela se produise n'est pas son domaine d'expertise. C'est le tien. Prenez la responsabilité de cela.

Il suffit de respecter suffisamment son travail pour que, lorsque vous avez terminé, vous lui montriez comment cela s'est passé. Laissez-le toucher tout ce que l'utilisateur vivrait. Soyez prêt à vous lancer dans de nouvelles idées.

Il s'agit d'un développement itératif. Ne faites pas grand chose avant de demander. Faites le moins possible. Demandez aussi souvent que possible. Mettez des jouets sur votre bureau pour le divertir pendant que vous mettez en œuvre sa dernière idée afin qu'il puisse l'examiner dès qu'elle se charge. Continuez comme ça jusqu'à ce qu'il soit temps de rencontrer le client.

Si le code produit par votre Front End Designer en vaut vraiment la peine, vous devez apprendre à intégrer votre code au sien. Pour cela, je vous encourage fortement à apprendre le contrôle des sources . Apprenez-le si bien que vous pouvez apprendre à votre Front End Designer à l'utiliser.

Ce n'est qu'une fois que vous pouvez tous deux utiliser de manière fiable un outil de contrôle de code source que je vous recommande de baser votre plan d'intégration sur la fusion de code. À ce stade, votre ami mériterait un changement de titre de Front End Designer à Front End Developer.

Maintenant, même si vous faites cela, cela ne me surprendrait pas si la technique de gribouillage à l'écran ne s'avère toujours pas le moyen le plus rapide pour vous deux de collaborer.

Peut-être que vous ne pouvez tout simplement pas prendre le chaos de tous ces changements. Cela crée trop de travail. Eh bien, c'est ce qu'on appelle un logiciel car il accepte le changement. Sinon, un ingénieur électricien le ferait sur une puce spécialisée. Il se peut que vous deviez atteindre l' architecte pour déplacer votre logique de comportement hors de l'interface utilisateur afin que les modifications de l'interface utilisateur n'aient pas d'impact sur vos règles métier principales. Si vous accélérez votre Front End Designer, vous devez être prêt à les suivre.

La seule bonne raison de forcer un Front End Designer à produire du code est que vous êtes fatigué et que vous voulez les ralentir. Eh bien, je suppose que ce n'est pas vraiment une "bonne" raison.

En termes d'outils, le flux de travail optimal que je vois utilise Sketch et Zeplin. Sketch est un outil de conception simple. Équivalent à Photoshop ou InDesign, mais optimisé pour la conception d'applications et de sites Web. Zeplin est un outil pour partager et approuver des conceptions dans Sketch (ou Photoshop). Il peut donner des mesures de pixels précises et même des extraits de code pour CSS ou tout autre code de mise en page et exporter des ressources graphiques. Une fois qu'une conception est définie, elle est remise au développeur. À ce stade, le développeur le récupère et crée l'interface utilisateur. Ensuite, il peut revenir au concepteur pour un contrôle qualité visuel. Tout ce qu'il trouve erroné, doit simplement être enregistré en tant que bug pour être priorisé et résolu par vous.

lorsque quelque chose ne fonctionne pas comme prévu (comme par exemple, cela n'a pas fonctionné comme nous l'avions prévu pour une raison quelconque), je résout le problème de mon côté, puis je lui renvoie le modèle

C'est la racine de vos problèmes. Le flux de conception doit toujours provenir de Designer to Developeret ne jamais s'inverser. Les révisions et les changements devraient avoir été effectués par le concepteur, puis poussés vers vous pour une implémentation dans le site Web. Vous pouvez toujours apporter des correctifs rapides vous-même, mais essayez d'accepter que ces correctifs rapides ne sont que temporaires. Le designer doit revenir à ses créations et trouver la bonne solution. Il vous propose ensuite le changement, et s'il s'avère que c'est la même chose que votre solution rapide, c'est parfait, sinon vous mettez à jour à partir de ses conceptions.

Il m'envoie le modèle complet (l'export HTML de Pinegrow)

Ne devenez pas accro à recevoir du HTML avec lequel vous pouvez travailler. C'est mieux si vous implémentez la technologie du site Web (Bootstrap, CSS, jQuery, React, PHP, etc. etc .. etc.) comme vous en avez besoin. Vous reproduisez ensuite ses créations à l'aide de ces outils. Si le code HTML qu'il vous donne est un démarrage rapide, c'est parfait , mais plus tard, à mesure que le projet se développe, il ne sera pas très utile. Vous devrez effectuer les modifications vous-même car vous seul comprenez votre moteur de création de modèles (c'est-à-dire les vues CakePHP, les modèles, les plugins, les composants, etc. etc.).

Ce processus, comme on pourrait l'imaginer, est extrêmement lent et inefficace.

Il en a toujours été ainsi. Les concepteurs ne sont pas des programmeurs. Ils prennent leur temps pour déterminer ce qui fonctionne le mieux pour l'utilisateur et font parfois des erreurs. Ils ne comprennent pas les concepts tels que les composants, les cadres et autres. En tant que programmeur, vous devez parler à votre concepteur et partager la façon dont j'implémente ce que vous concevez .

Le designer est coincé au milieu. D'un côté, ils doivent satisfaire les besoins du programmeur, et de l'autre, ils doivent satisfaire les besoins de l'utilisateur.

Ma question est donc la suivante: comment rendre ce processus plus fluide?

J'ai trouvé que s'asseoir physiquement à côté du concepteur et de la programmation aide vraiment à la communication. Si vous travaillez à distance, vous devez continuer à faire fonctionner Facetime pendant quelques jours. Cela aide vraiment à accélérer les choses.

J'ai vu beaucoup de choses à ce sujet que nous devrions utiliser React et utiliser RESTful et ce qui ne l'est pas, mais nous voulons utiliser CakePHP pour cela.

CakePHP est l'un des meilleurs frameworks de la planète (divulgation complète, je fais partie de l'équipe de base de CakePHP).

Cake est un cadre de développement de lapin où les fonctionnalités sont conçues pour créer des sites Web rapidement. Je sais que cela ressemble à un argumentaire de vente, mais c'est ce qu'il est classé. Il existe de nombreux autres cadres qui sont classés comme lapin. Java serait un exemple de framework plus d'entreprise que de lapin. Si vous utilisiez cette langue, j'aurais alors recommandé de changer. Puisque vous utilisez CakePHP. Je dirais que vous devriez rester avec elle.

CakePHP est un bon serveur principal si vous avez besoin d'API RESTful.

React / Angular / Vue sont tous des frameworks frontaux populaires et tendance, mais ils n'existent pas depuis très longtemps. CakePHP, d'autre part, existe depuis plus de 13 ans. Mon point n'est pas une critique. C'est le fait que ces bibliothèques JavaScript ont une courte durée de vie. Dans 5 ans, nous parlerons tous de quelque chose de nouveau, mais je pense que CakePHP sera toujours là.

Ainsi je dis. Utilisez React / Angular / Vue maintenant pendant qu'ils sont chauds, mais ne vous y engagez pas. Quelque chose de nouveau et de meilleur sera bientôt disponible. Je pense que nous vivons dans un monde où vous ne pouvez pas créer de bons sites Web sans eux.

Certaines personnes pourraient-elles me guider vers des ressources utiles à ce sujet?

Les demandes de listes sont hors sujet ici. Pardon.

MODIFIER :

J'ai raté la partie sur le suivi des modifications de conception.

Demandez à votre concepteur de sauvegarder sa sortie HTML dans BitBucket (ils ont des référentiels privés gratuits). Vous pouvez ensuite suivre et faire des comparaisons en utilisant le site Web BitBucket. Chaque fois que le concepteur fait un changement majeur, il ajoute une nouvelle branche avec un numéro de version.

Cela devrait être relativement facile pour lui de le faire, et cela vous permettra d'avoir un endroit pour commenter ces changements. Par exemple; il peut faire une demande d'extraction pour mettre à jour le référentiel dans lequel vous effectuez un examen des modifications avant leur fusion.

Vous devez séparer ces deux choses:

1. La conception UX & UI, une activité non codante
2. La mise en œuvre, définitivement une activité de codage

Le concepteur doit utiliser des outils créatifs comme Marvel qui sont juste pour la conception. Le concepteur ne devrait pas avoir à faire quoi que ce soit avec du code, du HTML, du CSS, etc. Les couleurs, les dimensions, l'esthétique, les interactions, les animations sont toutes les choses sur lesquelles il devrait se concentrer.

Le programmeur doit recevoir les actifs et la maquette (avec interactions et animations) et doit y arriver en programmant le logiciel. Cela comprenait également HTML et CSS. Le programmeur peut également utiliser des outils générateurs de son côté.

Pour accélérer le flux des tâches, je recommande d'utiliser un outil minimal comme Trello et de tout lier / documenter pour chaque unité de travail.

comment rendre ce processus plus fluide?

Insister sur le contrôle de version

Branche de logiciels et univers parallèles

• Ne travaillez sur aucun code hors contrôle de version. arrêt complet. Et je veux dire aller en grève jusqu'à ce que le projet soit entièrement dans un VCS.
• Branche officiellement, généreusement, localement
  • Formellement: branchement pour les versions et sous-parties des versions, correctif de test formel, etc. Faire évoluer un plan de contrôle de version formel, c'est-à-dire l'écrire.
  • Libéralement: au-delà de la numérotation officielle des versions en 4 parties, branchez si votre instinct vous dit que cela pourrait être une bonne idée.
  • Localement: j'ai gardé un repo personnel avec des succursales jamais destinées à la consommation d'équipe car en tant qu'équipe nous n'avons pas de succursale au début, et j'ai souvent des expériences, de l'exploration, au cas où, etc.

Concevez l'enfer de vos API middleware

Avantages:

• Stabilité - même lorsque le code sous-jacent évolue.
• Code testable
• Réutilisation
• Un outil de communication d'équipe
• C'est un contrat. Une promesse de services rendus (jeu de mots voulu)
• Codage dans le domaine du programmeur de maintenance SOLID == happy

C'est le principe `` demander, ne pas dire '' appliqué de la manière obsessionnelle compulsive qu'il devrait être. Si l'interface utilisateur manipule une propriété de couche métier unique, c'est faux.

Tout et n'importe quoi sur les objets métier doit être dans lesdits BO. Même des choses insignifiantes qui peuvent sembler mieux faites dans l'interface utilisateur - même un seul LOC. Minuita aime ajouter 2 valeurs fournies par l'utilisateur - toute la logique associée, y compris la validation, doit être dans l'API de la couche de gestion. La redondance OMI est parfois OK. Pour atténuer la redondance, vous pouvez avoir de petits objets de couche métier ciblés auxquels l'interface utilisateur a un accès complet.

Tout et tout ce dont l'interface utilisateur a besoin des objets métier doit être API. Par exemple, disposez de méthodes explicites qui relient ses arguments aux gestionnaires d'événements.

Méfiez-vous des cadres comme une béquille

Entre les mains des non-qualifiés, les frameworks et les IDE ne sont pas des barrières aux monstres B-movie qu'ils créent.

Avec des frameworks comme React, vous pourriez dire que tout est côté client, il n'y a pas de couche de logique métier back-end. L'idée clé ici est de découpler ce que l'utilisateur voit de ce que fait le programme. C'est faisable. Ce n'est pas seulement un serveur physique contre le navigateur des utilisateurs.

Je pense que c'est un bon indicateur de l'immaturité hors de la profession et de la pratique que nous acceptons que les gens qui conçoivent ne peuvent pas faire.

Cela ne serait pas acceptable dans presque toutes les autres professions.

Il est raisonnable de s'attendre à ce qu'un concepteur spécialisé dans la conception de sites Web / d'applications connaisse suffisamment bien CSS et HTML pour vous fournir des fichiers de travail et utilisables de ce type.

Les concepteurs qui fournissent des éditeurs graphiques WYSIWYG sont des concepteurs visuels ou graphiques. Il existe différents types de designers.

Cependant, il existe également différents types de niveaux de compétences, de capacités et d'expériences. Celui qui conçoit des meubles pourrait le faire uniquement sur un ordinateur avec des outils de conception 3D, auquel cas leur connaissance de la façon de tourner un tour ou d'utiliser un routeur CNC pourrait être tout à fait théorique. Ils font leurs créations et les envoient ensuite à d'autres.

À l'inverse, certains designers experts peuvent avoir le contrôle sur l'ensemble du processus et avoir la capacité et les connaissances nécessaires pour construire leurs meubles en tenant compte de chaque détail, peut-être même de l'artisanat.

Vous ne pourrez pas convaincre votre ami de changer sa façon de travailler. Si vous préférez avoir un concepteur Web avec les compétences HTML et CSS pour créer leurs propres conceptions, vous devrez en trouver un.