Front end prima o back end prima. Dei due che è un buon sistema di progettazione del sistema?

Se inizi dietro e vai avanti, corri il rischio di fraintendere il cliente. Poiché creerai cose che non possono facilmente vedere e comprendere, non potranno partecipare molto facilmente alla verifica della conformità ai requisiti. Ciò significa che potresti perdere un sacco di lavoro.

Se inizi in prima fila e vai indietro, corri il rischio che il cliente penserà che è quasi finito, quando tutto ciò che hai fatto è disegnare un semplice modulo sullo schermo. Potrebbero quindi chiedersi perché ci sia voluto così tanto tempo, dal momento che l'hai finito per lo più in pochi giorni. Rischia anche di dipingere te stesso in un angolo, quando ti rendi conto che devi fare un lavoro complicato per sposare la parte anteriore a quella posteriore, quando un front-end più adatto sarebbe stato più semplice.

IMO, dovresti lavorarci sopra feature-first. Scrivi insieme la parte anteriore e quella posteriore, per ciascuna caratteristica del sistema. Ciò offre al cliente una maggiore visibilità dei progressi e dà loro l'opportunità di dire "no, non è quello che intendevo", senza causare troppa angoscia.

Detto questo, se si tratta di un progetto molto ampio in cui è necessario considerare l'hardware del server o le funzionalità di qualsiasi software su cui si basa (ad esempio quale database si sta utilizzando), probabilmente si dovrebbe riflettere prima parte.

Ci sono molte dimensioni del software, quindi un front-vs-back troppo semplicistico è una domanda difficile ed è molto, molto difficile fornire una risposta utile e sensata a.

Una vista è la struttura statica dei dati. Ci sono almeno tre dimensioni su questa vista: strati architettonici ("front-to-back"), casi d'uso e attori, nonché costi o rischi di implementazione.

Una vista è la struttura dinamica dell'elaborazione. Ci sono almeno tre dimensioni per questa vista, anche.

Una terza vista sono i componenti architettonici, che ricadono naturalmente in livelli, supportano i casi d'uso e hanno costi e rischi.

Potrei andare avanti, ma il punto è questo.

Front-end vs. back-end developers (my take)

È approssimativamente il modo meno utile per esaminare il problema. Gli sviluppatori reali - e le vostre opinioni su di essi - contano molto, molto poco qui. Ciò che conta è

• Usa casi e attori

• Modello dati logici per supportare questi casi d'uso

• Processo eseguito come parte del caso d'uso

• Componenti che utilizzerai per costruire gli elementi logici e di elaborazione del caso d'uso.

Questo è il motivo per cui la maggior parte della gente dice che è necessario decomporre il sistema per user story o use case.

Non effettuare generalizzazioni a tratto ampio sulle persone che faranno lo sviluppo.

Nessuno dei due. Che cosa deve essere in grado di fare la tua app? Assicurati che la valvola calda fornisca acqua calda, che la valvola fredda fornisca acqua fredda, che l'acqua scorra in primo luogo, che tu possa estendere i tubi ovunque sia necessario e quindi preoccuparti di implementare l'impianto idraulico effettivo in tutte le stanze della casa o quello che la casa in realtà sembra esattamente.

Il front-end è solo una maschera con alcuni interruttori e leve su di esso. Il back-end è solo una cosa che riceve richieste per recuperare ed elaborare i dati. Raggiungi un punto in cui puoi implementare rapidamente entrambi in qualsiasi combinazione desiderata.

Ma qualunque cosa tu faccia, non lasciare che il design di uno determini il design dell'altro. In questo modo giace la pazzia.

Ottieni gli strumenti per consentire ai tuoi sviluppatori di realizzare qualsiasi cosa di cui abbiano bisogno per il tuo cliente, indipendentemente da quante volte cambiano idea. Quindi costruiscilo secondo le specifiche e riscrivilo fino a quando le piccole maledizioni sono finalmente felici.

Inoltre, confrontando gli sviluppatori front end con gli sviluppatori back-end nel 2008 è molto tempo fa negli anni web. Per motivi di divertimento, vorrei correggere / aggiungere alcune cose a quel vecchio castagno poiché lo abbiamo collegato nella domanda, ma anche (si spera) inserire alcuni suggerimenti all'interno di:

Sviluppatori front-end

In genere non hai un diploma CS o una laurea in CS da una scuola di terzo livello.

Manifestazione di mani. Quante persone con diplomi CS hanno imparato le migliori pratiche sul front-end? O come non fare casino con JavaScript? O come gestire i problemi CSS da IE6-IE9? L'industria dei libri di testo, che gestisce il mondo accademico, è troppo grassa, pigra e gonfia per gestire la tecnologia in continuo mutamento, quindi ha ricevuto un'attenzione molto "seria" nelle università. Questo è stato eccellente per i fioristi ritardatari come me.

Lavora in linguaggi simili a quelli di base (vedi PHP è di base)

Perché PHP è la tecnologia lato client? O perché JavaScript, che è stato ispirato principalmente da Scheme, ha più in comune con Basic e Visual Basic, che ora non è più un problema per il front end e non è mai esistito ma è ancora disponibile per le applicazioni Web .NET di back-end? Il blog mette a confronto gli sviluppatori web open source autodidatti con gli sviluppatori di CS grad Web utilizzando la tecnologia aziendale popolare a questo punto, penso. Mi sono imbattuto in insopportabile e competente in parti uguali su entrambi i lati di quel particolare combattimento, ma è ancora così OT lì.

Avere un'abilità visiva nella conversione dei documenti di Photoshop in CSS / HTML / etc.

Più attenzione ai dettagli rispetto alla "abilità visiva" che è un po 'ampia. Non tutti abbiamo capacità estetiche di design. Ma sì, molti di noi devono imparare questa roba al livello Jr. ed è in realtà abbastanza fondamentale per scrivere una buona interfaccia utente che non usi i martelli JS quando i bisturi CSS faranno.

Hai una tolleranza elevata per la programmazione iterativa, a causa del tipo di lingue libere

Questo è il motivo per cui desideri i pezzi che ho menzionato prima in precedenza. Passiamo i pulsanti premuti, produci / recuperi le merci. Li impacchettiamo e li consegniamo. Non c'è alcuna ragione per cui queste cose possano in alcun modo essere strettamente legate l'una all'altra. Inoltre, la tipizzazione rigorosa non dovrebbe interferire con un processo iterativo se non si fa schifo a OOP che la maggior parte delle persone a cui piace essere altezzosa in una lingua che non ha tecnicamente le lezioni, in realtà lo fa, in genere. Ma anche se fanno puzzare, il front-end ha solo bisogno di un punto di accesso prevedibile e puoi fare tutto ciò che vuoi sul back-end se non fai qualcosa di sciocco come scrivere in modo dinamico JavaScript che non è JSON o legare strettamente il comportamento di back-end di successo alla struttura HTML "proprio così". * cough * java devs * / cough *

Non c'è una sola risposta giusta a questo. Entrambi gli approcci possono essere buoni (e negativi) in determinate situazioni.

Ti consiglio di considerare l'approccio TDD, in cui uno è guidato dai test (accettazione e unità).

Inizia mettendo insieme uno scheletro del sistema: l'infrastruttura di base, con la funzionalità minima assoluta. Questo è solo per mostrare che il tuo concetto funziona e le diverse componenti sono in grado di lavorare insieme. Ciò include anche un'interfaccia utente bare bone (se applicabile), quanto basta per fare e / o mostrare qualcosa di minimo.

Quindi arricchisci i dettagli, funzione per caratteristica : scrivi un test di accettazione per una specifica funzione / scenario, fallo fallire, quindi scrivi il codice per soddisfarlo. Questo ti rende lavorare dall'interno verso l'esterno : il sistema riceve un messaggio di input, quindi devi gestire / convertire quel messaggio, fare qualcosa con esso, quindi propagare i risultati all'interfaccia utente. Lungo la strada scoprirai i concetti del dominio e li rappresenterai con nuove classi, dall'interfaccia utente verso il livello del dominio e ritorno.

Per questo approccio, la lettura consigliata è Software orientato agli oggetti in crescita, guidato dai test .

Inizia con il frontend, ma prima, perché non riescono a trovare un'applicazione che esiste già? Ciò darebbe ulteriori informazioni su questo progetto. Hanno delle esigenze particolari o pensano di poter costruire meno?

Ottieni una comprensione completa delle loro aspettative in materia di sicurezza e di quanto richiesto dalla legge. Non sei sicuro di quale tipo di scuola sia, ma le informazioni degli studenti di solito richiedono una certa riservatezza.

Se i potenziali studenti stanno inserendo i dati su un sito Web, la progettazione grafica sarà più un problema.

In base alle loro richieste, disegna i mock up del front-end. Se pensi che la gui non sia diretta, potresti dover fare qualcosa di funzionale, in modo che possano vederlo in azione. Potrebbero vedere l'iscrizione come un tipo di "procedura guidata" che si dirama in direzioni diverse in base alla voce di dati.

Quindi puoi iniziare a ricevere informazioni permanenti nel database.

Sì, mi sono reso conto che l'OP ha richiesto un po 'di tempo fa. Inizia dalla parte posteriore ma MOCK UP il front-end per consentire all'utente di vedere ciò che si immagina. Il front end, per quello che vale, è solo il suono delle campane e dei fischietti. Il back-end è dove sono i soldi, e una volta che hai una scala, la FE è solo il sugo sulla carne.

Espansione sul mio commento:

Prima raccogli i requisiti, quindi trasformali in Casi di utilizzo & design.

Prima viene una definizione dettagliata del database. Non m'importa se il cliente non lo masturba completamente, li costringo a sedermi e ampli; guardatelo e firmatelo (possibilmente forzandolo poi per capire che una volta i loro ragazzi più esperti di tecnologia dovrebbero farlo), prima di procedere.

Come puoi iniziare con FE, senza BE? FE per cosa ??? Definisci il tuo database !! Questo è ciò che manipola la FE.

Ok, ci saranno problemi e amp; ritocchi successivi, e I do sono d'accordo sul fatto che sia bene avere una GUI semplice, di esempio, di fronte al cliente ASAP, dal momento che quel particolare suggerimento dell'iceberg è ciò che più capisce.

Tuttavia, I 1) stress che questo è solo un mock up approssimativo, per le focene di discussione e 2) deliberatamente renderlo brutto, ma funzionale , in modo che quelli che non capiscono possano fare il nitpick & dimmi di fare quella casella di input esattamente 400px di larghezza e amp; lo sfondo blu chiaro.

Sono caduto che la maggior parte delle risposte qui (e le ho seguite) tendono a concentrarsi troppo sul cliente, ma, da un punto di vista puramente s / w, sostengo che non è possibile progettare un FE per manipolare un BE senza prima progettare quello BE.

API prima

Gli ingegneri di entrambi i team dovrebbero collaborare all'API tra il front-end e il back-end. Quindi entrambi i team possono iniziare a lavorare sulla base dell'API progettata. Questo ha il vantaggio che un altro team di front-end può anche iniziare il lavoro (forse mobile, dopo il client web) oltre all'ovvio vantaggio che i team possono iniziare a lavorare in parallelo.

Combina con un approccio iterativo e dovrebbe assomigliare a questo:

1. Progetta una semplice API
2. Entrambi i team sviluppano e testano in base all'API
3. Test di integrazione
4. Mostra al cliente e ricevi feedback.
5. Migliora API e ripeti.