Γεια σας φίλοι. Εν όψει της έναρξης του μαθήματος , παραδοσιακά μοιράζομαι μαζί σας τη μετάφραση χρήσιμου υλικού.
Το λογισμικό επιλύει όλο και περισσότερες καθημερινές εργασίες, ενώ γίνεται όλο και πιο περίπλοκο. Όπως είπε κάποτε ο Marc Andressen, καταναλώνει τον κόσμο.
Ως αποτέλεσμα, ο τρόπος ανάπτυξης και παράδοσης των εφαρμογών έχει αλλάξει δραματικά τα τελευταία χρόνια. Αυτές ήταν μετατοπίσεις τεκτονικής κλίμακας που κατέληξαν σε ένα σύνολο αρχών. Αυτές οι αρχές έχουν αποδειχθεί χρήσιμες για τη δημιουργία ομάδας, το σχεδιασμό, την ανάπτυξη και την παράδοση της εφαρμογής σας στους τελικούς χρήστες.
Οι αρχές μπορούν να συνοψιστούν ως εξής: η εφαρμογή θα πρέπει να είναι μικρή, βασισμένη στο web και να έχει αρχιτεκτονική με επίκεντρο τον προγραμματιστή. Έχοντας υπόψη αυτές τις τρεις αρχές, μπορείτε να δημιουργήσετε μια στιβαρή, ολοκληρωμένη εφαρμογή που μπορεί να παραδοθεί γρήγορα και με ασφάλεια στον τελικό χρήστη και να είναι εύκολα επεκτάσιμη και επεκτάσιμη.
Κάθε μία από τις προτεινόμενες αρχές έχει έναν αριθμό πτυχών που θα συζητήσουμε για να δείξουμε πώς κάθε αρχή συμβάλλει στον απώτερο στόχο, που είναι η ταχεία παράδοση αξιόπιστων εφαρμογών που είναι εύκολες στη συντήρηση και στη χρήση. Θα εξετάσουμε τις αρχές σε σχέση με τα αντίθετά τους για να διευκρινίσουμε τι σημαίνει, ας πούμε, «Βεβαιωθείτε ότι χρησιμοποιείτε αρχή της μικρότητας».
Ελπίζουμε ότι αυτό το άρθρο θα σας ενθαρρύνει να χρησιμοποιήσετε τις προτεινόμενες αρχές για τη δημιουργία σύγχρονων εφαρμογών, οι οποίες θα παρέχουν μια ενοποιημένη προσέγγιση στο σχεδιασμό στο πλαίσιο μιας συνεχώς αναπτυσσόμενης στοίβας τεχνολογίας.
Εφαρμόζοντας αυτές τις αρχές, θα εκμεταλλευτείτε τις τελευταίες τάσεις στην ανάπτυξη λογισμικού, συμπεριλαμβανομένου του για την ανάπτυξη και παράδοση εφαρμογών, τη χρήση κοντέινερ (για παράδειγμα, ) και πλαίσια ενορχήστρωσης κοντέινερ (για παράδειγμα, ), τη χρήση μικροϋπηρεσιών (συμπεριλαμβανομένης της Αρχιτεκτονικής Microservice и για εφαρμογές microservice.
Τι είναι μια σύγχρονη εφαρμογή;
Σύγχρονες εφαρμογές; Σύγχρονη στοίβα; Τι ακριβώς σημαίνει «μοντέρνο»;
Οι περισσότεροι προγραμματιστές έχουν μόνο μια γενική ιδέα για το τι αποτελείται μια σύγχρονη εφαρμογή, επομένως είναι απαραίτητο να οριστεί με σαφήνεια αυτή η έννοια.
Μια σύγχρονη εφαρμογή υποστηρίζει πολλούς πελάτες, είτε πρόκειται για μια διεπαφή χρήστη βιβλιοθήκης React JavaScript, μια εφαρμογή για κινητές συσκευές Android ή iOS ή μια εφαρμογή που συνδέεται με άλλο API. Μια σύγχρονη εφαρμογή συνεπάγεται απροσδιόριστο αριθμό πελατών για τους οποίους παρέχει δεδομένα ή υπηρεσίες.
Μια σύγχρονη εφαρμογή παρέχει ένα API για πρόσβαση στα ζητούμενα δεδομένα και υπηρεσίες. Το API θα πρέπει να είναι αμετάβλητο και σταθερό και να μην είναι γραμμένο ειδικά για ένα συγκεκριμένο αίτημα από έναν συγκεκριμένο πελάτη. Το API είναι διαθέσιμο μέσω HTTP(S) και παρέχει πρόσβαση σε όλες τις λειτουργίες που είναι διαθέσιμες στο GUI ή στο CLI.
Τα δεδομένα πρέπει να είναι διαθέσιμα σε κοινά αποδεκτή, διαλειτουργική μορφή, όπως JSON. Ένα API εκθέτει αντικείμενα και υπηρεσίες με καθαρό, οργανωμένο τρόπο, όπως το RESTful API ή το GraphQL που παρέχουν μια αξιοπρεπή διεπαφή.
Οι σύγχρονες εφαρμογές βασίζονται στη σύγχρονη στοίβα και η σύγχρονη στοίβα είναι η στοίβα που υποστηρίζει τέτοιες εφαρμογές, αντίστοιχα. Αυτή η στοίβα επιτρέπει σε έναν προγραμματιστή να δημιουργήσει εύκολα μια εφαρμογή με διεπαφή HTTP και εκκαθάριση τελικών σημείων API. Η επιλεγμένη προσέγγιση θα επιτρέψει στην εφαρμογή σας να λαμβάνει και να στέλνει εύκολα δεδομένα σε μορφή JSON. Με άλλα λόγια, η σύγχρονη στοίβα αντιστοιχεί στα στοιχεία της Εφαρμογής Twelve-Factor for .
Οι δημοφιλείς εκδόσεις αυτού του τύπου στοίβας βασίζονται σε , , , , и . Αρχιτεκτονική Microservice αντιπροσωπεύει ένα παράδειγμα μιας σύγχρονης στοίβας που υλοποιείται σε καθεμία από τις αναφερόμενες γλώσσες.
Λάβετε υπόψη ότι δεν υποστηρίζουμε μια προσέγγιση αποκλειστικά μικροϋπηρεσιών. Πολλοί από εσάς εργάζεστε με μονόλιθους που πρέπει να εξελιχθούν, ενώ άλλοι ασχολείστε με εφαρμογές SOA που επεκτείνονται και εξελίσσονται για να γίνουν εφαρμογές microservice. Άλλοι πάλι κινούνται προς εφαρμογές χωρίς διακομιστή και κάποιοι εφαρμόζουν συνδυασμούς των παραπάνω. Οι αρχές που περιγράφονται στο άρθρο ισχύουν για καθένα από αυτά τα συστήματα με λίγες μόνο μικρές τροποποιήσεις.
Αρχές
Τώρα που έχουμε μια κοινή κατανόηση του τι είναι μια σύγχρονη εφαρμογή και μια σύγχρονη στοίβα, ήρθε η ώρα να βουτήξουμε στις αρχές αρχιτεκτονικής και ανάπτυξης που θα σας εξυπηρετήσουν καλά στην ανάπτυξη, την εφαρμογή και τη διατήρηση μιας σύγχρονης εφαρμογής.
Μια από τις αρχές ακούγεται σαν "κάντε μικρές εφαρμογές", ας την ονομάσουμε αρχή της μικρότητας. Υπάρχουν απίστευτα πολύπλοκες εφαρμογές που αποτελούνται από πολλά κινούμενα μέρη. Με τη σειρά του, η δημιουργία μιας εφαρμογής από μικρά, διακριτά στοιχεία καθιστά ευκολότερο το σχεδιασμό, τη συντήρηση και την εργασία μαζί της ως σύνολο. (Σημειώστε ότι είπαμε «απλοποιεί» όχι «απλοποιεί»).
Η δεύτερη αρχή είναι ότι μπορούμε να αυξήσουμε την παραγωγικότητα των προγραμματιστών βοηθώντας τους να επικεντρωθούν στις δυνατότητες που αναπτύσσουν, ενώ τους απαλλάσσουμε από ανησυχίες σχετικά με την υποδομή και το CI/CD κατά την υλοποίηση. Έτσι, με λίγα λόγια, η προσέγγισή μας επικεντρώνεται στους προγραμματιστές.
Τέλος, τα πάντα σχετικά με την εφαρμογή σας πρέπει να είναι συνδεδεμένα στο δίκτυο. Τα τελευταία 20 χρόνια, έχουμε κάνει μεγάλα βήματα προς ένα δικτυωμένο μέλλον καθώς τα δίκτυα γίνονται ταχύτερα και οι εφαρμογές πιο περίπλοκες. Όπως έχουμε ήδη δει, μια σύγχρονη εφαρμογή πρέπει να χρησιμοποιείται μέσω δικτύου από πολλούς διαφορετικούς πελάτες. Η εφαρμογή της δικτυακής σκέψης στην αρχιτεκτονική έχει σημαντικά οφέλη που συμβαδίζουν αρχή της μικρότητας και την έννοια της προσέγγισης, προσανατολισμένη στον προγραμματιστή.
Εάν έχετε υπόψη σας αυτές τις αρχές κατά το σχεδιασμό και την υλοποίηση μιας εφαρμογής, θα έχετε ένα αναμφισβήτητο πλεονέκτημα στην ανάπτυξη και την παράδοση του προϊόντος σας.
Ας δούμε αυτές τις τρεις αρχές με περισσότερες λεπτομέρειες.
Αρχή της μικρότητας
Είναι δύσκολο για τον ανθρώπινο εγκέφαλο να αντιληφθεί ταυτόχρονα μεγάλο όγκο πληροφοριών. Στην ψυχολογία, ο όρος γνωστικό φορτίο αναφέρεται στο συνολικό ποσό της νοητικής προσπάθειας που απαιτείται για τη διατήρηση πληροφοριών στη μνήμη. Η μείωση του γνωστικού φόρτου στους προγραμματιστές αποτελεί προτεραιότητα, επειδή τους επιτρέπει να επικεντρωθούν στην επίλυση του προβλήματος αντί να διατηρούν το τρέχον περίπλοκο μοντέλο ολόκληρης της εφαρμογής και τις δυνατότητες που αναπτύσσονται στο μυαλό τους.
Οι εφαρμογές αποσυντίθενται για τους εξής λόγους:
- Μειωμένος γνωστικός φόρτος στους προγραμματιστές.
- Επιτάχυνση και απλοποίηση των δοκιμών.
- Γρήγορη παράδοση αλλαγών στην εφαρμογή.
Υπάρχουν διάφοροι τρόποι για να μειώσετε το γνωστικό φορτίο στους προγραμματιστές και εδώ είναι που παίζει ρόλο η αρχή της μικρότητας.
Ακολουθούν λοιπόν τρεις τρόποι για να μειώσετε το γνωστικό φορτίο:
- Μειώστε το χρονικό πλαίσιο που πρέπει να λάβουν υπόψη όταν αναπτύσσουν ένα νέο χαρακτηριστικό – όσο μικρότερο είναι το χρονικό πλαίσιο, τόσο χαμηλότερο είναι το γνωστικό φορτίο.
- Μειώστε τον αριθμό του κωδικού στον οποίο εκτελείται μια εφάπαξ εργασία - λιγότερος κωδικός - λιγότερο φορτίο.
- Απλοποιήστε τη διαδικασία των σταδιακών αλλαγών σε μια εφαρμογή.
Μείωση του χρονικού πλαισίου ανάπτυξης
Ας επιστρέψουμε στις μέρες που η μεθοδολογία waterfall ήταν το πρότυπο για τη διαδικασία ανάπτυξης και τα χρονικά πλαίσια από έξι μήνες έως δύο χρόνια για την ανάπτυξη ή την ενημέρωση μιας εφαρμογής ήταν κοινή πρακτική. Συνήθως, οι μηχανικοί θα διάβαζαν πρώτα σχετικά έγγραφα όπως τις απαιτήσεις προϊόντος (PRD), το έγγραφο αναφοράς συστήματος (SRD), το σχέδιο αρχιτεκτονικής και άρχιζαν να συνδυάζουν όλα αυτά τα πράγματα μαζί σε ένα γνωστικό μοντέλο, σύμφωνα με το οποίο κωδικοποίησαν. Καθώς οι απαιτήσεις και, κατά συνέπεια, η αρχιτεκτονική άλλαξαν, έπρεπε να γίνει μια σοβαρή προσπάθεια να ενημερωθεί ολόκληρη η ομάδα για ενημερώσεις στο γνωστικό μοντέλο. Μια τέτοια προσέγγιση, στη χειρότερη, θα μπορούσε απλώς να παραλύσει το έργο.
Η μεγαλύτερη αλλαγή στη διαδικασία ανάπτυξης εφαρμογών ήταν η εισαγωγή της ευέλικτης μεθοδολογίας. Ένα από τα κύρια χαρακτηριστικά της μεθοδολογίας agile είναι μια επαναληπτική εξέλιξη. Με τη σειρά του, αυτό οδηγεί σε μείωση του γνωστικού φορτίου των μηχανικών. Αντί να απαιτείται από την ομάδα ανάπτυξης να εφαρμόσει την εφαρμογή σε έναν μακρύ κύκλο, agile Η προσέγγιση σάς επιτρέπει να εστιάσετε σε μικρές ποσότητες κώδικα που μπορούν να δοκιμαστούν και να αναπτυχθούν γρήγορα, ενώ λαμβάνετε επίσης σχόλια. Το γνωστικό φορτίο της εφαρμογής έχει μετατοπιστεί από ένα χρονικό πλαίσιο έξι μηνών σε δύο χρόνια με τεράστιο όγκο προδιαγραφών για μια προσθήκη ή αλλαγή χαρακτηριστικών δύο εβδομάδων με στόχο μια πιο θολή κατανόηση μιας μεγάλης εφαρμογής.
Η μετατόπιση της εστίασης από μια τεράστια εφαρμογή σε συγκεκριμένα μικρά χαρακτηριστικά που μπορούν να ολοκληρωθούν σε ένα σπριντ δύο εβδομάδων, έχοντας κατά νου περισσότερο από ένα χαρακτηριστικό πριν από το επόμενο σπριντ, είναι μια σημαντική αλλαγή. Αυτό μας επέτρεψε να αυξήσουμε την αναπτυξιακή παραγωγικότητα μειώνοντας παράλληλα το γνωστικό φορτίο, το οποίο κυμαινόταν συνεχώς.
Στη μεθοδολογία agile Η τελική εφαρμογή αναμένεται να είναι μια ελαφρώς τροποποιημένη έκδοση της αρχικής ιδέας, επομένως το τελικό σημείο ανάπτυξης είναι αναγκαστικά διφορούμενο. Μόνο τα αποτελέσματα κάθε συγκεκριμένου σπριντ μπορούν να είναι ξεκάθαρα και ακριβή.
Μικρές βάσεις κωδικών
Το επόμενο βήμα για τη μείωση του γνωστικού φορτίου είναι η μείωση της βάσης κωδικών. Κατά κανόνα, οι σύγχρονες εφαρμογές είναι τεράστιες - μια ισχυρή, εταιρική εφαρμογή μπορεί να αποτελείται από χιλιάδες αρχεία και εκατοντάδες χιλιάδες γραμμές κώδικα. Ανάλογα με τον τρόπο οργάνωσης των αρχείων, οι σύνδεσμοι και οι εξαρτήσεις μεταξύ κώδικα και αρχείων μπορεί να είναι προφανείς ή το αντίστροφο. Ακόμη και η ίδια η εκτέλεση κώδικα εντοπισμού σφαλμάτων μπορεί να είναι προβληματική, ανάλογα με τις βιβλιοθήκες που χρησιμοποιούνται και το πόσο καλά τα εργαλεία εντοπισμού σφαλμάτων διακρίνουν μεταξύ βιβλιοθηκών/πακέτων/μονάδων και προσαρμοσμένου κώδικα.
Η δημιουργία ενός λειτουργικού νοητικού μοντέλου του κώδικα μιας εφαρμογής μπορεί να διαρκέσει εντυπωσιακό χρόνο και για άλλη μια φορά να επιφέρει μεγάλο γνωστικό βάρος στον προγραμματιστή. Αυτό ισχύει ιδιαίτερα για μονολιθικές βάσεις κώδικα, όπου υπάρχει μεγάλος αριθμός κώδικα, η αλληλεπίδραση μεταξύ των λειτουργικών στοιχείων του οποίου δεν είναι σαφώς καθορισμένη και ο διαχωρισμός των αντικειμένων προσοχής είναι συχνά ασαφής επειδή δεν τηρούνται τα λειτουργικά όρια.
Ένας από τους αποτελεσματικούς τρόπους μείωσης του γνωστικού φορτίου στους μηχανικούς είναι η μετάβαση σε μια αρχιτεκτονική μικροϋπηρεσιών. Σε μια προσέγγιση microservice, κάθε υπηρεσία εστιάζει σε ένα σύνολο χαρακτηριστικών. ενώ η έννοια της υπηρεσίας είναι συνήθως καθορισμένη και κατανοητή. Τα όρια μιας υπηρεσίας είναι επίσης σαφή - να θυμάστε ότι η επικοινωνία με μια υπηρεσία γίνεται μέσω ενός API, επομένως τα δεδομένα που παράγονται από μια υπηρεσία μπορούν εύκολα να μεταβιβαστούν σε μια άλλη.
Η αλληλεπίδραση με άλλες υπηρεσίες συνήθως περιορίζεται σε λίγες υπηρεσίες χρηστών και σε λίγες υπηρεσίες παρόχου που χρησιμοποιούν απλές και καθαρές κλήσεις API, όπως η χρήση REST. Αυτό σημαίνει ότι το γνωστικό φορτίο στον μηχανικό μειώνεται σοβαρά. Η μεγαλύτερη πρόκληση παραμένει η κατανόηση του μοντέλου αλληλεπίδρασης υπηρεσιών και του τρόπου με τον οποίο συμβαίνουν πράγματα όπως οι συναλλαγές σε πολλές υπηρεσίες. Ως αποτέλεσμα, η χρήση μικροϋπηρεσιών μειώνει το γνωστικό φορτίο μειώνοντας την ποσότητα του κώδικα, ορίζοντας σαφή όρια υπηρεσιών και παρέχοντας κατανόηση της σχέσης μεταξύ χρηστών και παρόχων.
Μικρές σταδιακές αλλαγές
Το τελευταίο στοιχείο της αρχής μικρότητα είναι η διαχείριση της αλλαγής. Είναι ένας ιδιαίτερος πειρασμός για τους προγραμματιστές να κοιτάξουν τη βάση κώδικα (ακόμη και τον δικό τους, παλαιότερο κώδικα) και να πουν, "Αυτό είναι χάλια, πρέπει να τα ξαναγράψουμε όλα." Μερικές φορές αυτή είναι η σωστή απόφαση και μερικές φορές όχι. Φέρνει το βάρος της αλλαγής του παγκόσμιου μοντέλου στην ομάδα ανάπτυξης, η οποία με τη σειρά της οδηγεί σε τεράστιο γνωστικό φορτίο. Είναι καλύτερο για τους μηχανικούς να επικεντρωθούν στις αλλαγές που μπορούν να κάνουν κατά τη διάρκεια του σπριντ, ώστε να μπορέσουν να αναπτύξουν την απαραίτητη λειτουργικότητα έγκαιρα, έστω και σταδιακά. Το τελικό προϊόν θα πρέπει να μοιάζει με το προσχεδιασμένο, αλλά με ορισμένες τροποποιήσεις και δοκιμές για να ταιριάζει στις ανάγκες του πελάτη.
Κατά την επανεγγραφή μεγάλων τμημάτων κώδικα, μερικές φορές δεν είναι δυνατή η γρήγορη παράδοση της αλλαγής επειδή μπαίνουν στο παιχνίδι άλλες εξαρτήσεις του συστήματος. Για να ελέγξετε τη ροή των αλλαγών, μπορείτε να χρησιμοποιήσετε την απόκρυψη χαρακτηριστικών. Κατ 'αρχήν, αυτό σημαίνει ότι η λειτουργικότητα είναι υπό παραγωγή, αλλά δεν είναι διαθέσιμη χρησιμοποιώντας τις ρυθμίσεις μεταβλητής περιβάλλοντος (env-var) ή κάποιον άλλο μηχανισμό διαμόρφωσης. Εάν ο κωδικός έχει περάσει όλες τις διαδικασίες ποιοτικού ελέγχου, τότε μπορεί να καταλήξει στην παραγωγή σε λανθάνουσα κατάσταση. Ωστόσο, αυτή η στρατηγική λειτουργεί μόνο εάν η δυνατότητα είναι τελικά ενεργοποιημένη. Διαφορετικά, θα γεμίσει μόνο τον κώδικα και θα προσθέσει ένα γνωστικό φορτίο που θα πρέπει να αντιμετωπίσει ο προγραμματιστής για να είναι παραγωγικός. Η διαχείριση αλλαγών και οι ίδιες οι σταδιακές αλλαγές συμβάλλουν στη διατήρηση του γνωστικού φορτίου των προγραμματιστών σε προσιτό επίπεδο.
Οι μηχανικοί πρέπει να ξεπεράσουν πολλές δυσκολίες ακόμα και με την απλή εισαγωγή πρόσθετης λειτουργικότητας. Από την πλευρά της διοίκησης, θα ήταν συνετό να μειωθεί η περιττή επιβάρυνση της ομάδας, ώστε να μπορεί να επικεντρωθεί σε βασικά λειτουργικά στοιχεία. Υπάρχουν τρία πράγματα που μπορείτε να κάνετε για να βοηθήσετε την ομάδα ανάπτυξής σας:
- Χρησιμοποιήστε μεθοδολογία
agileνα περιορίσει το χρονικό πλαίσιο στο οποίο η ομάδα πρέπει να επικεντρωθεί σε βασικά χαρακτηριστικά. - Υλοποιήστε την αίτησή σας ως πολλαπλές μικροϋπηρεσίες. Αυτό θα περιορίσει τον αριθμό των χαρακτηριστικών που μπορούν να εφαρμοστούν και θα ενισχύσει τα όρια που διατηρούν το γνωστικό φορτίο στην εργασία.
- Προτιμήστε τις σταδιακές αλλαγές από τις μεγάλες και δυσκίνητες, αλλάξτε μικρά κομμάτια κώδικα. Χρησιμοποιήστε την απόκρυψη λειτουργιών για να εφαρμόσετε αλλαγές ακόμα κι αν δεν είναι ορατές αμέσως μετά την προσθήκη τους.
Εάν εφαρμόσετε την αρχή της μικρότητας στην εργασία σας, η ομάδα σας θα είναι πολύ πιο χαρούμενη, θα επικεντρωθεί καλύτερα στην εφαρμογή των απαραίτητων λειτουργιών και θα είναι πιο πιθανό να πραγματοποιήσει ποιοτικές αλλαγές πιο γρήγορα. Αλλά αυτό δεν σημαίνει ότι η εργασία δεν μπορεί να γίνει πιο περίπλοκη, μερικές φορές, αντίθετα, η εισαγωγή νέας λειτουργικότητας απαιτεί την τροποποίηση αρκετών υπηρεσιών και αυτή η διαδικασία μπορεί να είναι πιο δύσκολη από παρόμοια σε μια μονολιθική αρχιτεκτονική. Σε κάθε περίπτωση, τα οφέλη από την προσέγγιση της μικρότητας αξίζουν τον κόπο.
Τέλος πρώτου μέρους.
Σύντομα θα δημοσιεύσουμε το δεύτερο μέρος της μετάφρασης και τώρα περιμένουμε τα σχόλιά σας και σας προσκαλούμε , που θα πραγματοποιηθεί σήμερα στις 20.00.
Πηγή: www.habr.com