Corso Enterprise Node.js di HexSchool
Alcune riflessioni e pensieri sparsi dopo aver completato il Corso Enterprise Node.js di HexSchool.
Perché ho seguito questo corso? Quale problema cercavo di risolvere?
Si tratta di un corso costoso. Data la natura di HexSchool (non possono rifiutare studenti paganti per ragioni commerciali), i contenuti del corso devono per forza essere progettati su un livello più accessibile.
Con queste premesse, iscriversi potrebbe sembrare un cattivo affare. Ma in pratica, ci sono diversi aspetti che vale la pena considerare:
Lavoro di squadra
Il corso richiede la collaborazione in gruppo fin dall'inizio. Poiché la maggior parte dei partecipanti proviene da un background frontend e ha poca o nessuna esperienza backend, rappresenta un'opportunità per esercitare la comunicazione e il coordinamento nello sviluppo backend.
Da un altro punto di vista, le persone con cui collabori possono diventare futuri contatti che si aiutano a vicenda -- è un modo per costruire la propria rete professionale.
Costo irrecuperabile
Come ho detto, questo è un corso costoso. Anche se sei pigro come me, se non vuoi che quei soldi vadano sprecati, dovrai impegnarti dopo il lavoro per stare al passo con il progetto e rispettare le scadenze. In un certo senso, ti costringe ad essere disciplinato.
Nuove prospettive
L'intero progetto va dall'ideazione del design allo sviluppo, da cima a fondo. Oggettivamente, i contenuti sono piuttosto superficiali, ma permettono comunque a ogni membro di attraversare almeno una volta il flusso di lavoro di PM, UI/UX, frontend e backend. Questo offre nuove prospettive per il lavoro futuro.
Contenuti del corso
Oltre alle basi dei comandi MongoDB e all'implementazione delle API Node.js, la parte più preziosa, a mio avviso, è stata l'integrazione con servizi di terze parti -- cose come il login tramite terze parti e l'elaborazione dei pagamenti. Queste operazioni sono noiose per natura e richiedono tempo per consultare la documentazione del provider, quindi avere un insegnamento strutturato ti risparmia quello sforzo.
Inoltre, alcune parti del corso usano ancora MVC come architettura di esempio, quindi il team ha dovuto capire da solo la separazione frontend-backend durante il progetto. Anche questa è un'area che richiede tempo e riflessione.
Alcune sessioni erano essenzialmente affidate a docenti ospiti per l'insegnamento dal vivo, il che può creare lacune. Per esempio, la sessione sugli unit test forniva esempi solo per il frontend, quindi se volevi fare pratica con gli unit test backend, dovevi arrangiarti da solo.
Lavoro sul progetto (opinione molto soggettiva)
Il lavoro sul progetto è quella che considero la parte più preziosa di questo corso, e la chiave sta nella collaborazione interna del team e nella pianificazione.
Sii onesto prima di formare i team
Prima della formazione dei team, c'è un'autovalutazione delle proprie competenze. Se non hai familiarità con un ambito, sii onesto. Se il divario di competenze all'interno di un team è troppo grande, si arriva facilmente a seri disaccordi, e il progetto crolla.
Prevedi del tempo cuscinetto per lo sviluppo
Poiché la maggior parte delle persone sono sviluppatori frontend che si avventurano nel backend, ci sono molte insidie che rallentano le cose -- cose di cui gli sviluppatori frontend non hanno mai dovuto preoccuparsi prima. Per esempio, dopo aver integrato l'elaborazione dei pagamenti, inevitabilmente devi gestire gli ordini, e gli ordini comportano timestamp delle transazioni e altre complessità.
Per gli sviluppatori frontend, queste problematiche non erano mai state nel loro radar. Era sempre e solo chiamare API e renderizzare liste. Ma lato backend, sono cose a cui devi assolutamente pensare.
Punta a un progetto consegnato
Per favore, considera seriamente questi punti:
- I membri del team hanno tutti un lavoro diurno e possono investire solo tempo limitato (non puoi prevedere se qualcuno avrà urgenze lavorative o straordinari)
- La scadenza è molto stretta, con tempo di sviluppo effettivo limitato
- La maggior parte dei membri non avrà esperienza backend, quindi ci saranno inevitabilmente momenti di blocco
Quindi l'obiettivo della prima fase dovrebbe essere costruire qualcosa che funzioni, non qualcosa di perfetto. Non pensare troppo all'architettura, all'ottimizzazione o ai test in questa fase -- quelli vengono dopo.
Se insegui la perfezione, non solo rimarrai bloccato sui tempi di sviluppo, ma peggio ancora, potresti causare la frattura del team (conflitti nascosti ovunque, specialmente quando non puoi sapere se i compagni di squadra stanno affrontando pressioni lavorative durante il giorno). Una volta che un team si frattura, il progetto è morto al 94,87%. Consegnare una funzionalità brutta ma funzionante fa molto per rafforzare la fiducia di tutti.
In particolare, evita di espandere all'infinito lo stack tecnologico del team. Lato frontend, non dovresti mai trovarti a usare sia React che Vue contemporaneamente. Anche se qualcuno nel team è bravissimo con un framework, questo non significa che gli altri possano impararlo abbastanza velocemente da contribuire.
Espansione e ottimizzazione
Dopo che il progetto ha completato la sua prima funzionalità basata sui ruoli, puoi considerare conclusa la prima fase. Oltre a prenderti una pausa, puoi iniziare a pensare a funzionalità aggiuntive, incluse cose che vuoi provare tecnicamente o miglioramenti dell'UX.
Per il nostro progetto, abbiamo gradualmente aggiunto messaggistica websocket, supporto PWA, animazioni, un sistema di check-in e altro, arricchendo il sito complessivo.
Parole finali
Ecco gli URL di deploy e i repository del nostro progetto. Sentiti libero di dare un'occhiata.
Client
Admin
<!-- account e password di test -->
account : admin
password : 12345678