Mantenere il "codice" lontano dai progettisti?

Costruisco un bel po 'di progetti con un mio amico, ma veniamo sempre alla stessa trappola più e più volte. So come scrivere PHP, Javascript e tutto il resto (conosco anche CSS e HTML) in modo da poter fare la maggior parte del lavoro quando si tratta di costruire la funzionalità effettiva. Tuttavia, non può, ma può fare qualcosa che a malapena posso fare: progettare i siti.

Ma ogni volta, ci imbattiamo in un problema, dal momento che non sa come scrivere il codice, generalmente rallenta un po 'il nostro sviluppo. Al momento questo è il nostro flusso di lavoro:

1. Troviamo una funzionalità
2. Costruisce il design del front-end (dove dovrebbe essere posizionato, come apparirà ecc.)
3. Mi invia il modello completo (l'esportazione HTML da Pinegrow)
4. Cerco le modifiche che ha apportato, quindi le implemento nel sito reale (da alcune settimane uso CakePHP per questo).
5. quando qualcosa non funziona come previsto (come ad esempio, non ha funzionato come previsto per qualche motivo), risolvo il problema dalla mia parte, quindi gli restituisco il modello
6. risciacqua e ripeti

Questo processo, come si può immaginare, è meticolosamente lento e inefficiente. Quindi la mia domanda è: come possiamo rendere questo processo più fluido? Ho visto molte cose su ciò che dovremmo usare React e usare RESTful e cosa no, ma vogliamo usare CakePHP per questo. Alcune persone potrebbero guidarmi verso alcune risorse utili al riguardo? Lo cerco da un po 'di tempo ma non ho mai trovato una soluzione decente per questo.

Fondamentalmente, tutto ciò che il mio partner può fare è progettare il sito. Non può usare Docker (uso sempre Docker), PHP, Javascript e praticamente qualsiasi altra cosa (conosce alcuni CSS, ma lavora principalmente con un WYSIWYGeditor) Sono disposto a impararlo, ma lui è non interessato (quindi lo rispetto). Spero che qualcuno qui possa aiutarmi (e probabilmente altri che verranno in seguito a questa domanda in seguito) con questo in quanto penso che sia una cosa abbastanza importante.

Vuoi liberare il tuo Front End Designer dal codice? Vuoi accelerare l'integrazione? Vuoi utilizzare le tecniche professionali utilizzate dai siti web più eleganti? Di gran lunga, lo strumento migliore per questo è:

Dipingere.

Sì Paint. Beh, qualche programma di disegno comunque. Lascialo catturare schermate del tuo sito, spostare le cose e aggiungere cose che trova altrove. Ciò gli consentirà di lavorare alla velocità delle sue idee e ti libererà di piegare il codice in qualsiasi forma funzioni meglio per te, dandogli ciò di cui ha bisogno.

Se è ancora troppo lento, supponiamo che il cliente sia nella stanza con entrambi, raccomando un set di strumenti molto più avanzato:

Carta, forbici e nastro.

Forse una penna se ti senti ambizioso.

Ho usato questa tecnica per prendere con successo decisioni sul tema, lo stile, il contenuto e le caratteristiche principali di un sito a un tavolo in un Pane Panera con un cliente prima che qualcuno si rendesse conto che avevamo finito di mangiare.

Ciò lo renderà veloce, ti libererà dal suo "codice" ed è in realtà il modo più potente per sviluppare un'interfaccia utente. Può iniziare a fare test di usabilità prima di aver scritto una riga di codice.

Potresti pensare "oh, va bene all'inizio ma non lo usi una volta sviluppato il sito". Non vero. Funziona altrettanto bene su siti stabili. Ma ora la maggior parte delle schermate provengono dal tuo sito.

Che cosa succede se il tuo Front End Designer desidera utilizzare alcuni strumenti di generazione del codice per realizzare i suoi modelli? Bene, ma non pensare per un secondo che devi usare il suo "codice". Quello che devi rispettare sono le sue decisioni su aspetto, flusso e presentazione. Ciò che accade dietro il sipario per farlo accadere non è la sua area di competenza. È tuo. Assumiti la responsabilità.

Rispetta abbastanza il suo lavoro che quando hai finito gli mostri come è andata a finire. Lascia che chiacchieri tutto ciò che l'utente potrebbe sperimentare. Preparati a essere colpito da nuove idee.

Questo è sviluppo iterativo. Non fare molto prima di chiedere. Fai il meno possibile. Chiedi il più spesso possibile. Metti i giocattoli sulla scrivania per intrattenerlo mentre implementi la sua ultima idea in modo che possa rivederla non appena carica. Continua così fino al momento di incontrare il cliente.

Se il codice prodotto dal tuo Front End Designer vale davvero la pena, allora devi imparare a integrare il tuo codice con il suo. Per questo ti incoraggio vivamente ad apprendere il controllo del codice sorgente . Imparalo così bene che puoi insegnare al tuo Front End Designer come usarlo.

Solo una volta che entrambi potete utilizzare in modo affidabile uno strumento di controllo del codice sorgente, vi consiglio di basare il vostro piano di integrazione sulla fusione del codice. A questo punto il tuo amico meriterebbe una modifica del titolo da Front End Designer a Front End Developer.

Ora anche se lo fai, non mi sorprenderebbe se la tecnica degli scarabocchi sullo schermo non si rivelasse ancora il modo più veloce per voi due di collaborare.

Forse non puoi proprio prendere il caos di tutti questi cambiamenti. Sta creando troppo lavoro. Beh, si chiama software perché accetta il cambiamento. Altrimenti avremmo un ingegnere elettrico farlo su un chip specializzato. Potrebbe essere necessario raggiungereitectect per spostare la logica di comportamento fuori dall'interfaccia utente in modo che le modifiche dell'interfaccia utente non influiscano sulle regole aziendali principali. Se acceleri il tuo Front End Designer devi essere pronto a tenerli al passo.

L'unico buon motivo per costringere un Front End Designer a produrre codice è perché sei stanco e vuoi rallentarlo. Beh, immagino che non sia proprio una "buona" ragione.

In termini di strumenti, il flusso di lavoro ottimale che ho visto è l'utilizzo di Sketch e Zeplin. Sketch è uno strumento di progettazione semplice. Equivalente a Photoshop o InDesign, ma ottimizzato per la progettazione di app e siti Web. Zeplin è uno strumento per condividere e approvare progetti in Sketch (o Photoshop). Può fornire misurazioni precise di pixel e persino frammenti di codice per CSS o altri codici di layout ed esportare risorse grafiche. Una volta impostato, il progetto viene consegnato allo sviluppatore. A questo punto, lo sviluppatore lo raccoglie e crea l'interfaccia utente. Quindi può tornare al designer per il controllo qualità visivo. Tutto ciò che trova sbagliato, dovrebbe essere registrato come un bug per essere prioritario e risolto da te.

quando qualcosa non funziona come previsto (come ad esempio, non ha funzionato come previsto per qualche motivo), risolvo il problema dalla mia parte, quindi gli restituisco il modello

Questa è la radice dei tuoi problemi. Il flusso del design dovrebbe sempre provenire daDesigner to Developer e mai invertito. Revisioni e modifiche avrebbero dovuto essere apportate dal progettista e quindi inviate all'utente per l'implementazione nel sito Web. Puoi sempre apportare correzioni rapide da solo, ma prova ad accettare che quelle correzioni rapide siano solo temporanee. Il designer deve tornare ai suoi progetti e trovare la soluzione corretta. Ti spinge quindi la modifica a te, e se capita che sia la stessa della tua soluzione rapida, allora è fantastico, altrimenti aggiorni dai suoi progetti.

Mi invia il modello completo (l'esportazione HTML da Pinegrow)

Non diventare dipendente dalla ricezione di HTML con cui puoi lavorare. È meglio se implementate la tecnologia del sito Web (Bootstrap, CSS, jQuery, React, PHP, ecc. Ecc. Ecc.) Nel modo in cui ne avete bisogno. Quindi riproduci i suoi disegni usando quegli strumenti. Se l'HTML che ti dà è un avvio veloce, allora è fantastico, ma più avanti man mano che il progetto cresce non sarà di grande utilità. Dovrai apportare le modifiche da solo perché solo tu capisci il tuo motore di template (ad es. Viste CakePHP, template, plugin, componenti, ecc. Ecc.)

Questo processo, come si può immaginare, è meticolosamente lento e inefficiente.

È sempre stato così. I designer non sono programmatori. Prendono il loro tempo per capire cosa funziona meglio per l'utente e talvolta commettono errori. Non comprendono concetti come componenti, framework e simili. Come programmatore devi parlare con il tuo designer e condividere il modo in cui implemento ciò che progetti .

Il designer è bloccato nel mezzo. Da un lato devono soddisfare le esigenze del programmatore e dall'altro devono soddisfare le esigenze dell'utente.

Quindi la mia domanda è: come possiamo rendere questo processo più fluido?

Ho scoperto che sedersi fisicamente accanto al progettista e programmare lì aiuta davvero nella comunicazione. Se voi due state lavorando in remoto, continuate così per qualche giorno. Aiuta davvero ad accelerare le cose.

Ho visto molte cose su ciò che dovremmo usare React e usare RESTful e cosa no, ma vogliamo usare CakePHP per questo.

CakePHP è uno dei migliori framework del pianeta (piena divulgazione, sono nel core team di CakePHP).

Cake è un framework di sviluppo dei conigli in cui le funzionalità sono progettate per creare rapidamente siti Web. So che suona come un passo di vendita, ma questo è ciò che è classificato come. Esistono molti altri framework classificati come coniglio. Java sarebbe un esempio di un framework più aziendale di coniglio. Se avessi usato quella lingua, avrei fatto una raccomandazione per cambiare. Dal momento che stai usando CakePHP. Direi che dovresti restare con esso.

CakePHP è un buon server back-end se hai bisogno di API RESTful.

React / Angular / Vue sono tutti framework popolari e di tendenza, ma non esistono da molto tempo. CakePHP d'altra parte è in circolazione da 13+ anni. Il mio punto non è una critica. È il fatto che queste librerie JavaScript hanno una durata breve. Tra 5 anni parleremo tutti di qualcosa di nuovo, ma sospetto che CakePHP sarà ancora in giro.

Quindi dico io. Usa React / Angular / Vue ora mentre sono caldi, ma non impegnarti con loro. Qualcosa di nuovo e migliore arriverà a breve. Penso che viviamo in un mondo in cui non puoi costruire buoni siti Web senza di loro.

Alcune persone potrebbero guidarmi verso alcune risorse utili al riguardo?

Le richieste di elenchi sono fuori tema qui. Scusa.

MODIFICARE :

Ho perso la parte relativa al rilevamento delle modifiche al design.

Chiedi al tuo designer di salvare il suo output HTML in BitBucket (hanno repository privati ​​gratuiti). È quindi possibile tenere traccia e fare confronti utilizzando il sito Web BitBucket. Ogni volta che il progettista apporta una modifica importante, aggiunge una nuova filiale con un numero di versione.

Dovrebbe essere relativamente facile per lui farlo, e questo ti permetterà di avere un posto per commentare tali cambiamenti. Per esempio; può fare una richiesta pull per aggiornare il repository in cui si esegue una revisione delle modifiche prima che vengano unite.

Devi separare queste due cose:

1. Progettazione di UX e UI, un'attività non codificante
2. Implementazione, sicuramente un'attività di codifica

Il designer dovrebbe usare strumenti creativi come la Marvel che sono solo per la progettazione. Non dovrebbe essere la preoccupazione del progettista di fare qualcosa con codice, HTML, CSS ecc. I colori, le dimensioni, l'estetica, le interazioni, le animazioni sono tutte le cose su cui dovrebbe essere focalizzato.

Il programmatore dovrebbe ricevere le risorse e il modello (con interazioni e animazioni) e dovrebbe farlo accadere programmando il software. Ciò includeva anche HTML e CSS. Il programmatore può usare anche strumenti generatori dalla sua parte.

Per accelerare il flusso di attività, consiglio di utilizzare uno strumento minimo come Trello e collegare / documentare tutto per ogni unità di lavoro.

come possiamo rendere questo processo più fluido?

Insistere sul controllo della versione

Branching software e universi paralleli

• Funziona su nessun codice non nel controllo versione. punto. E intendo scioperare fino a quando il progetto non è tutto in un VCS.
• Ramo formalmente, liberalmente, localmente
  • Formalmente: diramazione per rilasci e sottoparti di rilasci, correzione formale dei test, ecc. Evoluzione di un piano formale di controllo della versione, ovvero annotazione.
  • Liberalmente: oltre la numerazione delle versioni formali in 4 parti, diramazione se l'intestino ti dice che potrebbe essere una buona idea.
  • A livello locale: ho tenuto un repository personale con filiali non destinate al consumo di squadra perché inizialmente non abbiamo una filiale e spesso ho esperimenti, esplorazioni, per ogni evenienza, ecc.

Ingegnere le API del middleware

Benefici:

• Stabilità - anche quando il codice sottostante si sta evolvendo.
• Codice testabile
• Riutilizzazione
• Uno strumento di comunicazione di squadra
• È un contratto Una promessa di servizi resi (gioco di parole intenzionale)
• Codifica nel regno di SOLID == buon programmatore di manutenzione

È la domanda, non dire il principio applicato nel modo ossessivo compulsivo che dovrebbe essere. Se l'interfaccia utente sta manipolando una singola proprietà del livello aziendale, è sbagliato.

Tutto ciò che riguarda gli oggetti business deve essere contenuto in detti BO. Anche cose banali che potrebbero sembrare fatte meglio nell'interfaccia utente - persino un singolo LOC. A Minuita piace aggiungere 2 valori forniti dall'utente - tutta la logica associata inclusa la convalida deve essere nell'API del livello aziendale. La ridondanza dell'IMO a volte va bene. Per mitigare la ridondanza è possibile disporre di oggetti di livello aziendale piccoli e mirati a cui è consentito l'accesso completo all'interfaccia utente.

Tutto e tutto ciò di cui l'interfaccia utente ha bisogno dagli oggetti business dovrebbe essere API. Ad esempio, hanno metodi espliciti che collegano i suoi argomenti ai gestori di eventi.

Fai attenzione ai quadri come una stampella

Nelle mani di non qualificati, i framework e gli IDE non sono barriere per i mostri del film B che creano.

Con framework come React potresti dire che è tutto lato client, non esiste un livello di logica aziendale back-end. L'idea chiave qui è disaccoppiare ciò che l'utente vede da ciò che fa il programma. È fattibile. Non è solo un server fisico rispetto al browser degli utenti.

Penso che sia un buon indicatore dell'immaturità fuori dalla professione e dalla pratica che accettiamo che le persone che progettano, non possono fare.

Ciò non sarebbe accettabile in quasi tutte le altre professioni.

È ragionevole aspettarsi che un designer specializzato nella progettazione di siti Web / app conosca abbastanza bene CSS e HTML per fornire file funzionanti e utilizzabili di quel tipo.

I designer che forniscono editor grafici WYSIWYG sono designer visivi o grafici. Esistono molti tipi diversi di designer.

Tuttavia, esistono anche diversi tipi di livelli di abilità, abilità ed esperienze. Chi progetta mobili può farlo esclusivamente su un computer con strumenti di progettazione 3D, nel qual caso la sua conoscenza di come girare un tornio o utilizzare un router CNC potrebbe essere del tutto teorica. Fanno i loro progetti e poi li inviano per essere realizzati da altri.

Al contrario, alcuni designer esperti possono avere il controllo dell'intero processo e avere la capacità e la conoscenza di costruire i loro mobili con un occhio per ogni dettaglio, forse anche artigianale.

Non sarai in grado di convincere il tuo amico a cambiare il suo modo di lavorare. Se preferisci avere un web designer con le competenze HTML e CSS per creare i propri progetti, dovrai trovarne uno.