In quale ordine le persone costruiscono siti Web? [chiuso]

Inizialmente, un sito web è come qualsiasi altro progetto IT.

1. Inizia con i requisiti; analizzare questi requisiti; formulare le esigenze e gli obiettivi del sito Web, ovvero ciò che deve raggiungere.

2. Dopo questa fase è necessario averlo progettato e realizzato. Avendo lavorato in questo settore per molti anni, ho trovato che l'approccio migliore è lavorare dall'esterno in.

3. Le immagini devono essere progettate per prime, progettazioni piatte, per far apparire il sito esattamente come dovrebbe essere, tutto sull'interfaccia che deve essere lì, nel modo in cui lo si desidera.

4. Una volta che l'interfaccia è stata interamente progettata, può iniziare la build strutturale HTML / CSS / Flash / Silverlight. Questo ha il framework up, questo dovrebbe includere tutti i pezzi varianti del puzzle, le sezioni che sono nascoste, i componenti che vanno e vengono, si spostano, ecc.

5. Infine, è possibile inserire la funzionalità, controllando tutte le parti con il necessario controllo dello stato anteriore e posteriore per ottenere la risposta desiderata dall'interfaccia.

   Si noti che il codice back-end su cui si basa l'interfaccia può essere fatto in genere contemporaneamente alla build strutturale, poiché una volta che l'interfaccia è stata interamente progettata, i requisiti back-end per la fornitura all'interfaccia possono essere generalmente stabiliti.

6. Lo strato intermedio del codice di controllo tra la build strutturale e il codice backend è l'ultima cosa, in ogni caso, poiché è l'ultimo accoppiamento tra i livelli in termini di cosa deve essere finito prima di poter iniziare (il percorso critico).

NB. Questo modello ha il vantaggio di creare un assembly della linea di produzione tra i lavoratori se hai consulenti, grafici, sviluppatori / sviluppatori di software e ingegneri del software . Passandoci attraverso in questo ordine.

L'unico aspetto negativo è che possono esserci problemi di backlog se un determinato sito Web è più impegnativo in una particolare fase che rallenta il team corrispondente. Se lo stesso stadio è regolarmente più significativo, questo problema diventa sostanziale. Non sempre controllabile assumendo più persone in quella sezione.

La tua prima preoccupazione dovrebbe essere il contenuto che sarà sul sito web. Una buona idea per Google è "Content First". (Ecco un articolo che discute di lavorare sui tuoi contenuti in tandem con la tua struttura: link )

Per costruire effettivamente il sito, ritengo sia meglio ottenere la funzionalità (logica, eventi, output) che hai menzionato e poi passare al CSS e metterlo in pratica. (Lavoro come sviluppatore web front-end)

L'importante è pianificare ciò che stai per costruire prima di saltare e iniziare a imbrogliare il codice. La tua logica dovrebbe essere basata su una specifica e il tuo CSS dovrebbe essere basato su comps e wireframe, e tutto ciò dovrebbe essere basato sulla comunicazione con il tuo cliente e su quali esigenze hanno per il sito.

Se stai implementando un sito web per un cliente, inizia con wireframe. A meno che il tuo cliente non sia uno sviluppatore web o un web designer esperto, non avrà la possibilità di immaginare nulla sul web. Devi mostrare loro esattamente quello che vedranno, o qualcosa che è ovviamente un disegno di una pagina web. Cerca di convincerli a parlare di come verrà utilizzato il sito e di costruire alcuni scenari utente o "casi d'uso" da questo.

Quando senti di sapere cosa è richiesto, e sarà un sito interattivo, mi piace progettare il database prima perché è la parte più "a monte" dell'applicazione - tutto il resto dipende da esso. Le buone decisioni di progettazione rendono il resto del tuo lavoro molto più semplice (e viceversa). Se stai creando un blog o un sistema di gestione dei contenuti, forse è solo questione di scegliere un database NoSQL.

Una volta che il design del database sembra buono, torno ai wireframe e li implemento in HTML. L'ultima fase è scrivere il middleware che interroga i dati dal database e crea l'HTML per gli schermi.

L'ordine effettivo varia per i diversi progetti e c'è sempre un controspionaggio in cui una decisione di progettazione da qualche parte ti invia a una parte diversa dell'applicazione per compensare, ma questo è un buon piano predefinito da cui partire.

Per riepilogare:

• Raccolta dei requisiti
• Design Database
• Avvia front-end (HTML ecc.)
• Crea "Business Logic" intermedio per connettere il front-end al Database.

Leggendo questo argomento, dovrei raccomandarti di scrivere casi di test per la tua logica aziendale mentre lo codifichi. Quindi quando hai bisogno di cambiare qualcosa hai un modo per verificare che tutto il resto funzioni ancora. Alcuni test front-end devono essere eseguiti manualmente. Utilizza un validatore HTML e verifica (manualmente come utente) su diversi marchi di browser.

Vorrei aggiungere un commento ma sono troppo nuovo, questo è l'intero scopo dello SDLC (cosa tipo CMMI per i ragazzi del software). Il processo è ben definito a livello internazionale (nelle comunità di ingegneri) e all'interno di vari standard.

Raccolta dei requisiti > Indaga > Progetta > Codice / Sviluppo / (qualunque cosa) > Test > Costruire

Ogni passo è iterativo al passo precedente. Senza il passo precedente, non puoi fare il passo successivo. Esegui l'iter usando il modello che desideri (RUP, RAD, Waterfall, ecc.) ... il concetto non cambia.

Dici che i requisiti sono noti in anticipo, ma direi che nessun progetto software di una complessità utile ha requisiti che sono definiti nella pietra.

Un progetto di sito Web è ancora un progetto software e di conseguenza beneficia di pratiche agili. Sviluppare in modo iterativo, dimostrare software di lavoro al cliente ogni una o due settimane. Inizia con il prodotto minimo di lavoro (non molto più di un mock-up), e ritaglia in modo iterativo le funzionalità / i contenuti mancanti. Adeguarsi ai mutevoli requisiti e consentire al cliente di decidere cosa costruire mentre lo si sta costruendo. Evita i processi di "linea di produzione" e incoraggia invece una stretta collaborazione e responsabilità condivisa tra i membri del team. C'è un e-book gratuito che spiega le pratiche di scrum.

In un progetto in stile mischia non costruirai prima nessuno dei diversi livelli tecnici. Svilupperai in profondità, offrendo una funzionalità di lavoro dall'alto verso il basso e passando a quella successiva (in cui la funzione successiva potrebbe essere una versione riveduta di una funzione precedente). Non c'è quindi una risposta giusta su cosa fare prima, front-end o back-end, perché questo potrebbe cambiare da sprint a sprint e feature to feature.