Ο πίνακας ελέγχου του χρήστη στην εφαρμογή μας, Ευθυγράμμιση

Πώς δημιουργήσαμε την πρώτη εφαρμογή πλήρους στοίβας της JavaScript σε τρεις εβδομάδες

Ένας απλός οδηγός βήμα προς βήμα για να μεταβείτε από την ιδέα στην αναπτυχθείσα εφαρμογή

Οι τρεις μήνες μου κωδικού bootcamp στο πρόγραμμα Grace Hopper Program έχουν κλείσει και ο τίτλος αυτού του άρθρου δεν είναι πραγματικά αληθινός - έχω πλέον χτίσει τρεις πλήρεις εφαρμογές: ένα κατάστημα ηλεκτρονικού εμπορίου από το μηδέν, ένα προσωπικό hackathon έργου της επιλογής μου και, τέλος, ένα έργο τριάντα εβδομάδων. Εκείνο το έργο είναι πολύ πιο εντατικό - ένα ταξίδι τριών εβδομάδων με δύο συμπαίκτες - και είναι το πιο περήφανο επίτευγμα από το bootcamp. Είναι η πρώτη ισχυρή, πολύπλοκη εφαρμογή που έχω κατασκευάσει και σχεδιάσει πλήρως.

Όπως γνωρίζουν οι περισσότεροι προγραμματιστές, ακόμα και όταν ξέρετε πώς να κωδικοποιήσετε, μπορεί να είναι πολύ συντριπτική η έναρξη της δημιουργίας της πρώτης εφαρμογής πλήρους στοίβα. Το οικοσύστημα JavaScript είναι απίστευτα τεράστιο: με τους διαχειριστές πακέτων, τις ενότητες, τα εργαλεία κατασκευής, τα transpeller, τις βάσεις δεδομένων, τις βιβλιοθήκες και τις αποφάσεις που πρέπει να γίνουν για όλα αυτά, δεν είναι περίεργο ότι τόσοι πολλοί κωδικοποιητές δεν οικοδομούν τίποτα πέρα ​​από τα tutorials του Codecademy. Αυτός είναι ο λόγος για τον οποίο θέλω να σας οδηγήσω σε έναν βήμα-βήμα οδηγό των αποφάσεων και τα βήματα που πήρε η ομάδα μου για να δημιουργήσουμε τη ζωντανή εφαρμογή μας, Align.

Πρώτον, κάποιο πλαίσιο. Η ευθυγράμμιση είναι μια εφαρμογή ιστού που χρησιμοποιεί μια διαισθητική διεπαφή χρονικής γραμμής για να βοηθήσει τους χρήστες να θέσουν μακροπρόθεσμους στόχους και να τις διαχειριστούν με την πάροδο του χρόνου. Η στοίβα μας περιλαμβάνει Firebase για υπηρεσίες back-end και React στο front end. Οι συμπαίκτες μου και εγώ εξηγώ περισσότερο σε αυτό το σύντομο βίντεο:

Πώς λοιπόν πήγαμε από την Ημέρα 1, όταν μας ανατέθηκαν οι ομάδες μας, στην τελική ζωντανή εφαρμογή; Ακολουθεί μια ανασκόπηση των βημάτων που πήραμε:

Βήμα 1: Ιδεώστε

Το πρώτο βήμα ήταν να καταλάβουμε τι ακριβώς θέλαμε να χτίσουμε. Στην προηγούμενη ζωή μου ως σύμβουλος της IBM, έκανα εργαστήρια ιδεών με εταιρικούς ηγέτες. Αποσύροντας από αυτό, πρότεινα στην ομάδα μου την κλασική στρατηγική για την ανταλλαγή ιδεών μετά από αυτή, στην οποία όλοι μας γράφουμε όσο το δυνατόν περισσότερες ιδέες - ακόμα και «ανόητες» - ώστε οι ανθρώπινοι εγκέφαλοι να συνεχίσουν να κινούνται και κανείς να μην αποφεύγει να εκφράζει ιδέες από φόβος.

Αφού δημιουργήσαμε μερικές δεκάδες ιδέες εφαρμογών, τις ταξινομήσαμε σε κατηγορίες για να κατανοήσουμε καλύτερα ποια θέματα είχαμε συλλογικά ενθουσιασμένους. Στην ομάδα μας, είδαμε μια σαφή τάση προς τις ιδέες που περιβάλλουν την αυτο-βελτίωση, τον καθορισμό στόχων, τη νοσταλγία και την προσωπική ανάπτυξη. Από αυτό τελικά εξελίξαμε μια συγκεκριμένη ιδέα: ένα προσωπικό ταμπλό για τον καθορισμό και τη διαχείριση μακροπρόθεσμων στόχων, με στοιχεία της διατήρησης της μνήμης και της απεικόνισης δεδομένων με την πάροδο του χρόνου.

Από εκεί, δημιουργήσαμε μια σειρά από ιστορίες χρηστών - περιγραφές χαρακτηριστικών που θέλαμε να έχουμε, από την άποψη του τελικού χρήστη - για να διασαφηνίσουμε τι ακριβώς θέλαμε να κάνει η εφαρμογή μας.

Βήμα 2: Συρματόπλεγμα UX / UI

Στη συνέχεια, σε ένα λευκό πίνακα, αντλήσαμε τις βασικές απόψεις που προβλέψαμε στην εφαρμογή μας. Έχουμε ενσωματώσει το σύνολο των ιστοριών των χρηστών μας για να κατανοήσουμε πώς αυτές οι απόψεις θα λειτουργούσαν σε ένα σκελετικό πλαίσιο εφαρμογής.

Αυτά τα σκίτσα μας εξασφάλιζαν ότι βρισκόμασταν όλοι στην ίδια σελίδα και παρέχουμε ένα οπτικό σχέδιο για το τι ακριβώς προσπαθούσαμε όλοι.

Βήμα 3: Επιλέξτε μια δομή δεδομένων και έναν τύπο βάσης δεδομένων

Ήταν πλέον καιρός να σχεδιάσουμε τη δομή των δεδομένων μας. Με βάση τα wireframes και τις ιστορίες των χρηστών μας, δημιουργήσαμε μια λίστα σε ένα έγγραφο Google για τα μοντέλα που θα χρειαζόμασταν και ποια χαρακτηριστικά θα έπρεπε να συμπεριλάβουν. Γνωρίζαμε ότι χρειαζόμασταν ένα μοντέλο «στόχου», ένα μοντέλο «χρήστη», ένα μοντέλο «ορόσημο» και ένα μοντέλο «checkin», καθώς και ένα μοντέλο «πόρου» και ένα μοντέλο «ανεφοδιασμού».

Αρχικό σκίτσο των μοντέλων δεδομένων μας

Μετά από την ανεπίσημη σχεδίαση των μοντέλων, χρειαζόμασταν να επιλέξουμε έναν τύπο βάσης δεδομένων: 'relational' vs. 'non-relational' (a.k.a. 'SQL' vs. 'NoSQL'). Ενώ οι βάσεις δεδομένων SQL είναι βασισμένες σε πίνακα και έχουν προκαθορισμένο σχήμα, οι βάσεις δεδομένων NoSQL βασίζονται σε έγγραφα και έχουν δυναμικό σχήμα για μη δομημένα δεδομένα.

Για τη χρήση μας, δεν είχε σημασία αν χρησιμοποιήσαμε βάση δεδομένων SQL ή No-SQL, έτσι επιλέξαμε τελικά τη βάση δεδομένων Firebase NoSQL του cloud Google για άλλους λόγους:

  1. Θα μπορούσε να διατηρήσει μεταφορτώσεις εικόνων χρήστη στο αποθηκευτικό χώρο του cloud
  2. Περιέχει ενσωμάτωση WebSocket για ενημέρωση σε πραγματικό χρόνο
  3. Θα μπορούσε να χειριστεί τον έλεγχο ταυτότητας χρήστη και να προσφέρει εύκολη ενσωμάτωση του OAuth

Αφού επιλέξαμε μια βάση δεδομένων, ήρθε η ώρα να κατανοήσουμε τις σχέσεις μεταξύ των μοντέλων δεδομένων μας. Δεδομένου ότι το Firebase είναι NoSQL, δεν μπορούσαμε να δημιουργήσουμε πίνακες σύνδεσης ή να δημιουργήσουμε επίσημες σχέσεις όπως "Checkins belongTo Goals". Αντ 'αυτού, χρειαζόμασταν να καταλάβουμε τι θα δούλευε το δέντρο JSON και πώς τα αντικείμενα θα ήταν ένθετα (ή όχι). Τελικά, δομήσαμε το μοντέλο μας ως εξής:

Το τελικό σχήμα δεδομένων Firebase για το αντικείμενο στόχου. Σημειώστε ότι τα ορόσημα & οι επιταγές είναι ένθετες κάτω από τους στόχους.

(Σημείωση: Η Firebase προτιμά τις ρηχές, κανονικοποιημένες δομές δεδομένων για αποδοτικότητα, αλλά για την περίπτωση χρήσης μας έκανε πιο λογικό να το φωλιάζουμε, δεδομένου ότι ποτέ δεν θα τραβούσαμε έναν στόχο από τη βάση δεδομένων χωρίς τα παιδικά ορόσημα και checkins.)

Βήμα 4: Ρυθμίστε το Github και μια ευκίνητη ροή εργασιών

Γνωρίζαμε από την αρχή ότι η διατήρηση της οργάνωσης και η ευκίνητη ανάπτυξη θα μας εξυπηρετούσαν καλά. Δημιουργήσαμε ένα repo Github, στο οποίο παρεμποδίσαμε τη συγχώνευση για να καταφέρουμε να αναγκάσουμε τον εαυτό μας να αναθεωρήσει τον κώδικα του άλλου.

Δημιουργήσαμε επίσης ένα ευέλικτο board στο Waffle.io, το οποίο είναι δωρεάν και έχει εύκολη ενσωμάτωση με το Github. Στον πίνακα Waffle, αναφέραμε τις ιστορίες των χρηστών μας καθώς και τα σφάλματα που ήξερα ότι έπρεπε να διορθώσουμε. Αργότερα, όταν ξεκινήσαμε την κωδικοποίηση, θα δημιουργούσαμε καθένα από τα git branches για την ιστορία του χρήστη που εργαζόμαστε επί του παρόντος, κινούμαστε από τη λωρίδα κολύμβησης για να κολυμπήσουμε λωρίδα καθώς προχωρούμε.

Αρχίσαμε επίσης να πραγματοποιούμε "stand-up" συναντήσεις κάθε πρωί για να συζητήσουμε την πρόοδο της προηγούμενης ημέρας και τους αποκλεισμούς που όλοι μας συναντήσαμε. Αυτή η συνάντηση συχνά αποφάσισε τη ροή της ημέρας - ποιος θα ήταν προγραμματισμός ζευγαριών, και ποιος θα εργαστεί σε ένα θέμα σόλο.

Συστήνω ιδιαίτερα μια δομημένη ροή εργασίας όπως αυτή, καθώς μας επέτρεψε να καθορίσουμε με σαφήνεια τις προτεραιότητές μας και να πραγματοποιήσουμε αποτελεσματική πρόοδο χωρίς καμία διαπροσωπική σύγκρουση.

Βήμα 5: Επιλέξτε & κατεβάστε ένα boilerplate

Επειδή το οικοσύστημα JavaScript είναι τόσο περίπλοκο, επιλέξαμε να μην κατασκευάσουμε την εφαρμογή μας από το απόλυτο σημείο μηδέν. Ένιωσα περιττό να δαπανήσουμε πολύτιμο χρόνο καλωδίωσης για να δημιουργήσουμε δέσμες ενεργειών Webpack και φορτωτές και το σύζυγό μας που έδειχνε τον κατάλογο του έργου μας. Η ομάδα μου επέλεξε τον σκελετό Firebones επειδή ταιριάζει με τη χρήση της θήκης μας, αλλά υπάρχουν πολλές επιλογές σκελετού ανοιχτού κώδικα διαθέσιμες για να διαλέξετε.

Βήμα 6: Γράψτε τις διαδρομές API του back-end (ή τους ακροατές Firebase)

Αν δεν χρησιμοποιούσαμε μια βάση δεδομένων που βασίζεται σε σύννεφο, θα ήταν η κατάλληλη στιγμή να αρχίσουμε να γράφουμε τις γραμμές Express Express για να υποβάλουμε αιτήματα στη βάση δεδομένων μας. Αλλά από τη στιγμή που χρησιμοποιήσαμε τη Firebase, η οποία βρίσκεται ήδη στο σύννεφο και έχει διαφορετικό τρόπο επικοινωνίας με τον κώδικα, εργαστήκαμε ακριβώς για να δημιουργήσουμε τον πρώτο μας επιτυχημένο ακροατή βάση δεδομένων.

Για να εξασφαλίσουμε ότι ο ακροατής μας δούλευε, κωδικοποιήσαμε μια βασική φόρμα χρήστη για τη δημιουργία ενός στόχου και είδαμε ότι, όταν συμπληρώσαμε τη φόρμα, η βάση δεδομένων μας ενημερώθηκε ζωντανά. Ήμασταν συνδεδεμένοι!

Βήμα 7: Δημιουργήστε μια "Απόδειξη της έννοιας"

Το επόμενο βήμα ήταν να δημιουργήσουμε μια "απόδειξη της ιδέας" για την εφαρμογή μας ή ένα πρωτότυπο από τα πιο δύσκολα θεμελιώδη χαρακτηριστικά που θα μπορούσαμε να υλοποιήσουμε, αποδεικνύοντας ότι η εφαρμογή μας θα μπορούσε τελικά να υπάρχει. Για εμάς, αυτό σήμαινε την εύρεση μιας βιβλιοθήκης front-end για την ικανοποιητική απόδοση χρονικών ορίων και τη σύνδεσή της με το Firebase με επιτυχία για την εμφάνιση ορισμένων δεδομένων σπόρων στη βάση δεδομένων μας.

Βασικά χρονοδιαγράμματα Victory.JS

Βρήκαμε Victory.JS, μια βιβλιοθήκη React με βάση το D3 και πέρασα μια μέρα διαβάζοντας την τεκμηρίωση και βάζοντας μαζί ένα πολύ βασικό παράδειγμα ενός στοιχείου VictoryLine και ενός στοιχείου VictoryScatter για την οπτική εμφάνιση δεδομένων από τη βάση δεδομένων. Πράγματι, λειτούργησε! Ήμασταν έτοιμοι να χτίσουμε.

Βήμα 8: Κωδικοποιήστε τις δυνατότητες

Τέλος, ήρθε η ώρα να δημιουργήσουμε όλες τις συναρπαστικές λειτουργίες της εφαρμογής μας. Αυτό είναι ένα γιγαντιαίο βήμα που προφανώς ποικίλλει ευρέως ανάλογα με την εφαρμογή που χτίζετε προσωπικά. Εξετάσαμε τα wireframes μας και ξεκίνησαμε την κωδικοποίηση των ξεχωριστών ιστοριών των χρηστών στο Waffle. Αυτό περιλάμβανε συχνά την επαφή με τον κωδικό του μπροστινού και του τελικού κώδικα (για παράδειγμα, δημιουργώντας μια φόρμα front-end και συνδέοντάς την με τη βάση δεδομένων). Τα χαρακτηριστικά γνωρίσματά μας κυμαίνονταν από μεγάλα έως δευτερεύοντα και περιλάμβαναν πράγματα όπως:

  • δυνατότητα δημιουργίας νέων στόχων, ορόσημων και επιταγών
  • δυνατότητα να διαγράψετε τους στόχους, τα ορόσημα και τα checkins
  • δυνατότητα να αλλάξετε το όνομα, το χρώμα και τις λεπτομέρειες του χρονικού ορίζοντα
  • δυνατότητα μεγέθυνσης των χρονοδιαγραμμάτων
  • δυνατότητα προσθήκης συνδέσμων στους πόρους
  • δυνατότητα μεταφόρτωσης μέσων
  • την ικανότητα να διοχετεύουν τους πόρους και τα μέσα μαζικής ενημέρωσης από τα ορόσημα και τα checkins στους σχετικούς στόχους τους
  • πλούσια ενσωμάτωση επεξεργαστή κειμένου
  • εγγραφή χρήστη / έλεγχος ταυτότητας χρήστη / OAuth
  • για να προβάλετε τις επιλογές χρονικού ορίου
  • οθόνες φόρτωσης

Για προφανείς λόγους, αυτό το βήμα πήρε το μεγαλύτερο μέρος της εποχής μας - αυτή η φάση είναι εκεί όπου συνέβαινε το μεγαλύτερο μέρος του κωπηλατικού κώδικα και κάθε φορά που ολοκληρώσαμε ένα χαρακτηριστικό γνώρισμα, υπήρχαν πάντα περισσότερα για να οικοδομήσουμε!

Βήμα 9: Επιλέξτε και κωδικοποιήστε το σχέδιο σχεδιασμού

Μόλις είχαμε ένα MVP της λειτουργικότητας που θέλαμε στην εφαρμογή μας, ήταν καιρός να το καθαρίσουμε και να το κάνουμε όμορφο. Η ομάδα μου χρησιμοποίησε το υλικό-UI για στοιχεία όπως πεδία φόρμας, μενού και καρτέλες σύνδεσης, τα οποία εξασφάλιζαν ότι όλα έμοιαζαν κομψά, στιλβωμένα και συνεκτικά χωρίς πολύ βαθιά γνώση σχεδιασμού.

Αυτό ήταν ένα από τα αγαπημένα μου χαρακτηριστικά για να αποκωδικοποιήσω. Η ομορφιά της είναι τόσο ικανοποιητική!

Ξοδέψαμε μια στιγμή να επιλέξουμε ένα χρωματικό σχέδιο και να επεξεργαστούμε το CSS, το οποίο μας έδωσε ένα ωραίο διάλειμμα από την κωδικοποίηση των χαρακωμάτων. Σχεδιάσαμε επίσης ένα λογότυπο και φορτώσαμε ένα favicon.

Βήμα 10: Βρείτε και σκουίστε τα σφάλματα

Ενώ θα έπρεπε να χρησιμοποιούσαμε από την αρχή την εξέλιξη που οδήγησε στην εξέλιξη, οι χρονικοί περιορισμοί μας άφησαν πολύτιμο χρόνο για οτιδήποτε άλλο εκτός από τα χαρακτηριστικά. Αυτό σήμαινε ότι περάσαμε τις τελευταίες δύο ημέρες προσομοιώνοντας κάθε ροή των χρηστών που μπορούσαμε να σκεφτούμε και κυνηγώντας την εφαρμογή μας για σφάλματα.

Αυτή η διαδικασία δεν ήταν η πιο συστηματική, αλλά βρήκαμε πολλά σφάλματα για να μας κρατήσουμε απασχολημένους, συμπεριλαμβανομένου ενός σφάλματος στο οποίο η οθόνη φόρτωσης θα διαρκέσει επ 'αόριστον σε ορισμένες καταστάσεις και μία στην οποία το στοιχείο των πόρων είχε σταματήσει να λειτουργεί πλήρως. Η επίλυση σφαλμάτων μπορεί να είναι ενοχλητική, αλλά όταν τελικά λειτουργεί, είναι εξαιρετικά ικανοποιητική.

Βήμα 11: Εγκαταστήστε τη ζωντανή εφαρμογή

Το τελευταίο βήμα ήταν να αναπτύξουμε την εφαρμογή μας, ώστε να είναι διαθέσιμη ζωντανά! Επειδή χρησιμοποιήσαμε τη Firebase για την αποθήκευση των δεδομένων μας, αναπτύξαμε το Firebase Hosting, το οποίο ήταν διαισθητικό και απλό. Εάν το πίσω μέρος σας χρησιμοποιεί διαφορετική βάση δεδομένων, μπορείτε να χρησιμοποιήσετε το Heroku ή το DigitalOcean. Γενικά, οι οδηγίες εγκατάστασης είναι άμεσα διαθέσιμες στον ιστότοπο φιλοξενίας.

Αγόρασα επίσης ένα φτηνό όνομα τομέα στο Namecheap.com για να κάνουμε την εφαρμογή μας πιο γυαλισμένη και εύκολη στην εύρεση.

Και αυτό ήταν - είμαστε ξαφνικά οι συν-δημιουργοί μιας πραγματικής ζωντανής πλήρους στοίβας εφαρμογής που κάποιος θα μπορούσε να χρησιμοποιήσει! Εάν είχαμε μεγαλύτερο διάδρομο, το βήμα 12 θα ήταν να εκτελέσουμε δοκιμές A / B στους χρήστες, οπότε θα μπορούσαμε να καταλάβουμε καλύτερα τον τρόπο με τον οποίο οι πραγματικοί χρήστες αλληλεπιδρούν με την εφαρμογή μας και τι θα ήθελαν να δουν σε ένα V2.

Προς το παρόν, ωστόσο, είμαστε ευχαριστημένοι με το τελικό προϊόν και με την ανυπολόγιστη γνώση και κατανόηση που αποκτήσαμε σε όλη αυτή τη διαδικασία. Ελέγξτε έξω Ευθυγραμμίστε εδώ!

Ομάδα Align: Sara Kladky (αριστερά), Melanie Mohn (κέντρο), και εγώ.

- -
Εάν σας άρεσε αυτό το κομμάτι, θα το λάτρευα αν χτυπήσει την πράσινη καρδιά έτσι άλλοι μπορεί να σκοντάψουν σε αυτό. Μη διστάσετε να ελέγξετε τον πηγαίο κώδικα για την Align και ακολουθήστε με στο Github, καθώς και τα μέλη της ομάδας μου badass, Sara Kladky και Melanie Mohn.