Front end prima o Back end prima. Dei due che è una buona pratica di progettazione del sistema?

Al momento ho un cliente che mi richiede di sviluppare un sistema di iscrizione scolastica. Ora è la prima volta che ho questo tipo di sfida. La maggior parte dei software passati che ho creato non sono così complessi.

So che molti di voi hanno creato software complessi, voglio solo i vostri consigli su questo. Devo progettare prima il front-end o il back-end?

Grazie!

Ecco una conclusione di un articolo che ho trovato su Internet qualche tempo fa. Voglio solo condividere

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

Sviluppatori front-end e back-end (la mia opinione)

La mia opinione personale

Ancora una volta è una questione di allenamento, alcune generalizzazioni di ictus:

Sviluppatori front-end

• In genere non hanno un diploma CS o un diploma CS di una scuola di 3 ° livello.
• Lavora in lingue simili a quelle di base (vedi PHP è di base)
• Avere un'abilità visiva nella conversione di documenti Photoshop in CSS / HTML / ecc.
• Hanno un'alta tolleranza per la programmazione iterativa, grazie ai linguaggi liberi di tipo

Sviluppatori di back-end

• Avere una laurea in CS o molta esperienza
• Sono tendenzialmente più sistematico nel loro approccio alla risoluzione dei problemi
• Non preoccuparti di passare giorni a trovare l'unico oggetto che perde
• Prova a creare strumenti per risolvere i problemi

Se inizi dal retro e vai avanti, corri il rischio di fraintendere il cliente. Dal momento che creerai cose che non possono facilmente vedere e comprendere, non possono partecipare molto facilmente alla verifica della conformità ai requisiti. Ciò significa che potresti sprecare molto lavoro.

Se inizi dalla parte anteriore e vai indietro, corri il rischio che il cliente pensi che sia quasi finito, quando tutto ciò che hai fatto è disegnare un semplice modulo sullo schermo. Potrebbero quindi chiedersi perché sta impiegando così tanto tempo, dal momento che lo hai finito per lo più in pochi giorni. Corri anche il rischio di dipingerti in un angolo, quando ti rendi conto che devi fare un lavoro complicato per sposare la parte anteriore con la parte posteriore, quando un front-end più adatto sarebbe stato più semplice.

IMO, dovresti lavorarci su prima di tutto. Scrivi insieme front e back end, per ciascuna funzione del sistema. Ciò offre al cliente una maggiore visibilità dei progressi e offre loro l'opportunità di dire "no, non è quello che volevo dire", senza causare troppa angoscia.

Detto questo, se si tratta di un progetto molto ampio in cui è necessario considerare l'hardware del server o le capacità di qualsiasi software su cui si fa affidamento (ad es. Quale database si sta utilizzando), allora si dovrebbe probabilmente avere una buona idea prima di quella parte.

Esistono molte dimensioni del software, quindi un fronte-retro eccessivamente semplicistico è una domanda scadente ed è molto, molto difficile fornire una risposta sensata e utile.

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

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

Una terza vista sono i componenti architettonici, che si dividono naturalmente in strati, supportano casi d'uso e presentano costi e rischi.

Potrei continuare, ma il punto è questo.

Sviluppatori front-end e back-end (la mia opinione)

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

• Usa casi e attori

• Modello di dati logici a supporto di questi casi d'uso

• Processo eseguito come parte del caso d'uso

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

Questo è il motivo per cui la maggior parte delle persone afferma che è necessario decomporre il sistema in base alla storia dell'utente o al caso d'uso.

Non fare generalizzazioni generalizzate sulle persone che faranno sviluppo.

Né. Cosa deve fare la tua app? Assicurati che la valvola calda fornisca acqua calda, la valvola fredda fornisca acqua fredda, che l'acqua scorra in primo luogo, che puoi estendere i tubi ovunque sia necessario e quindi preoccuparti di implementare l'impianto idraulico reale in tutte le stanze della casa o di ciò che la casa farà in realtà sembrano esattamente.

La parte frontale è solo una maschera con alcuni interruttori e leve su di essa. Il back-end è solo una cosa che riceve richieste per recuperare ed elaborare i dati. Arrivare a un punto in cui è possibile implementare rapidamente entrambi in qualsiasi combinazione desiderata prima.

Ma qualunque cosa tu faccia, non lasciare che il design dell'uno imponga il design dell'altro. In questo modo sta la follia.

Metti in atto gli strumenti per consentire ai tuoi sviluppatori di costruire qualunque diavolo abbiano bisogno per il tuo cliente, indipendentemente da quante volte cambiano idea. Quindi costruiscilo secondo le specifiche e riattivalo fino a quando le piccole bestemmie sono finalmente felici.

Inoltre, il confronto tra gli sviluppatori front-end e gli sviluppatori back-end nel 2008 è molto tempo fa negli anni web. Per motivi di divertimento, mi piacerebbe correggere / aggiungere alcune cose a quella vecchia castagna poiché l'abbiamo collegata alla domanda, ma anche (si spera) incorporare alcuni suggerimenti in:

Sviluppatori front-end

In genere non hanno un diploma CS o un diploma CS di una scuola di 3 ° livello.

Manifestazione delle mani. A quante persone con gradi CS sono state insegnate 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 e gonfia per gestire la tecnologia in costante mutamento, quindi ha ricevuto ben poca attenzione "seria" nei college. Questo è stato eccellente per i fioristi in ritardo come me.

Lavora in lingue simili a quelle 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 che con Visual Basic, che ora non è più un problema permanente nel front-end e non lo è mai stato, ma è ancora disponibile per le applicazioni web .NET back-end? Il blog confronta gli sviluppatori web open source autodidatta con gli sviluppatori web laureati CS che usano 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 molto avanti lì.

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

Più attenzione ai dettagli che "abilità visiva" che è un po 'ampia. Non tutti noi abbiamo alcuna capacità di progettazione estetica. Ma sì, la maggior parte di noi deve imparare queste cose a livello Jr. ed è in realtà abbastanza critico per scrivere una buona UI che non usi i martelli JS quando lo faranno i bisturi CSS.

Hanno un'alta tolleranza per la programmazione iterativa, grazie ai linguaggi liberi di tipo

Questo è il motivo per cui vuoi che i pezzi di cui ho parlato prima siano al loro posto. Passiamo i pulsanti premuti, produci / recuperi la merce. Li imballiamo e li consegniamo. Non c'è motivo per cui queste cose siano in alcun modo strettamente legate l'una all'altra. Inoltre, la tipizzazione rigorosa non dovrebbe interferire con un processo iterativo se non fai schifo a OOP che la maggior parte delle persone a cui piace diventare altera su una lingua che non ha tecnicamente lezioni, in effetti, in genere lo fanno. Ma anche se puzzano, il front-end ha solo bisogno di un punto di accesso prevedibile e puoi fare qualunque cosa diavolo vuoi sul back-end fintanto che non fai qualcosa di stupido come scrivere dinamicamente JavaScript che non sia JSON o legare strettamente il comportamento back-end di successo alla struttura HTML essendo "proprio così". * tosse * java devs * / tosse *

Non esiste una sola risposta corretta a questo. Entrambi gli approcci possono essere buoni (e cattivi) in determinate situazioni.

Vi consiglio di prendere in considerazione l'approccio TDD, in cui uno è guidato da test (di accettazione e di unità).

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

Quindi approfondisci i dettagli, caratteristica per caratteristica : scrivi un test di accettazione per una specifica caratteristica / scenario, fallo fallire, quindi scrivi il codice per soddisfarlo. Questo ti fa lavorare verso l'interno dall'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. Sulla strada scoprirai i concetti di dominio e li rappresenterai con nuove classi, dall'interfaccia utente verso il livello di dominio e viceversa.

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

Prima l'API

Gli ingegneri di entrambi i team dovrebbero lavorare insieme sull'API tra il front-end e il back-end. Quindi entrambi i team possono iniziare a lavorare in base all'API progettata. Ciò ha il vantaggio che un altro team 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 apparire così:

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

Inizia con il frontend, ma prima, perché non riescono a trovare un'applicazione che esiste già? Ciò darebbe ulteriori informazioni su questo progetto. Hanno dei requisiti unici o pensano di poter costruire più economici?

Ottieni una comprensione completa delle loro aspettative di sicurezza e di ciò che la legge richiede. Non sono sicuro di che tipo di scuola sia, ma le informazioni degli studenti di solito richiedono un po 'di riservatezza.

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

Sulla base delle loro richieste, disegna i modelli del front-end. Se pensi che la GUI non sia diretta, potresti dover rendere funzionale qualcosa, in modo che possano vederlo in azione. Potrebbero vedere la registrazione come un tipo di "procedura guidata" che si dirama in diverse direzioni in base all'immissione dei dati.

Quindi è possibile iniziare a ottenere informazioni persistenti nel database.

Sì, ho capito che l'OP ha chiesto qualche tempo fa. Inizia dal back-end ma MOCK UP al front-end per consentire all'utente di vedere ciò che immagini. La parte frontale, per quanto ne valga la pena, sono solo le campane e i fischietti. Il back-end è dove sono i soldi, e una volta che hai quello dritto, la FE è solo il sugo sulla carne.

Espandendo il mio commento:

Prima raccogli i requisiti, poi trasformali in Casi d'uso e design.

Prima arriva una definizione dettagliata del database. Non mi interessa se il cliente non lo grugnisce completamente, li costringo a sedersi e guardarlo - e firmare su di esso (forse poi costringendo poi a rendersi conto 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 la FE manipola.

Ok, ci saranno problemi e modifiche successive, e io farlo d'accordo che è bene per ottenere un semplice, campione, GUI di fronte al cliente ASAP, dal momento che quel particolare punta dell'iceberg è ciò che la maggior parte la maggior parte capire.

Tuttavia, 1) sottolineo che questo è solo un mock up approssimativo, per discussioni di focene e 2) lo rende deliberatamente brutto, ma funzionale , in modo che coloro che non capiscono possano nitpick e dirmi di rendere quella casella di input esattamente 400px largo e lo sfondo azzurro.

Sono caduto sul fatto 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 una FE per manipolare una BE senza prima progettando che BE.