Η ανάπτυξη λογισμικού είναι υπέροχη, αλλά… νομίζω ότι μπορούμε όλοι να συμφωνήσουμε ότι μπορεί να είναι λίγο συναισθηματικό rollercoaster. Στην αρχή, όλα είναι υπέροχα. Προσθέτετε νέες λειτουργίες το ένα μετά το άλλο σε λίγες ημέρες, αν όχι ώρες. Είστε σε ρολό!

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

Χειροτερεύει. Αρχίζετε να ανακαλύπτετε πολλά σφάλματα στην εφαρμογή σας. Συχνά, η επίλυση ενός σφάλματος δημιουργεί δύο νέα. Σε αυτό το σημείο, μπορείτε να αρχίσετε να τραγουδάτε:

99 μικρά σφάλματα στον κώδικα. 99 μικρά σφάλματα. Βγάλτε ένα, βάλτε το γύρω,

… 127 μικρά σφάλματα στον κώδικα.

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

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

Λόγοι για τους οποίους η ανάπτυξη λογισμικού επιβραδύνεται με την πάροδο του χρόνου

Λοιπόν, ποιος είναι ο λόγος για αυτό το πρόβλημα;

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

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

Big Ball of Mud και πώς να το μειώσετε

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

Λοιπόν, τι ακριβώς είναι αυτό το αντι-μοτίβο; Με απλά λόγια, παίρνετε μια μεγάλη μπάλα λάσπης όταν κάθε στοιχείο έχει μια εξάρτηση με άλλα στοιχεία. Παρακάτω, μπορείτε να δείτε ένα γράφημα των εξαρτήσεων από το γνωστό έργο ανοιχτού κώδικα Apache Hadoop. Για να απεικονίσετε τη μεγάλη μπάλα λάσπης (ή μάλλον τη μεγάλη μπάλα του νήματος), σχεδιάζετε έναν κύκλο και τοποθετείτε τάξεις από το έργο ομοιόμορφα πάνω του. Απλώς σχεδιάστε μια γραμμή μεταξύ κάθε ζεύγους τάξεων που εξαρτώνται το ένα από το άλλο. Τώρα μπορείτε να δείτε την πηγή των προβλημάτων σας.

Η «μεγάλη μπάλα της λάσπης» του Apache Hadoop

Λύση με αρθρωτό κώδικα

Γι 'αυτό έθεσα στον εαυτό μου μια ερώτηση: Θα ήταν δυνατόν να μειώσω την πολυπλοκότητα και να διασκεδάσω όπως στην αρχή του έργου; Αλήθεια, δεν μπορείτε να εξαλείψετε όλα της πολυπλοκότητας. Εάν θέλετε να προσθέσετε νέες δυνατότητες, θα πρέπει πάντα να αυξήσετε την πολυπλοκότητα του κώδικα. Ωστόσο, η πολυπλοκότητα μπορεί να μετακινηθεί και να διαχωριστεί.

Πώς άλλοι κλάδοι λύνουν αυτό το πρόβλημα

Σκεφτείτε τη μηχανική βιομηχανία. Όταν κάποιο μικρό μηχανολογικό κατάστημα δημιουργεί μηχανήματα, αγοράζουν ένα σύνολο τυπικών στοιχείων, δημιουργούν μερικά προσαρμοσμένα και τα συνδυάζουν. Μπορούν να φτιάξουν αυτά τα συστατικά εντελώς ξεχωριστά και να συγκεντρώσουν τα πάντα στο τέλος, κάνοντας μόνο λίγες τροποποιήσεις. Πώς είναι αυτό δυνατόν? Ξέρουν πώς κάθε στοιχείο θα ταιριάζει από κοινού με καθορισμένα πρότυπα της βιομηχανίας, όπως μεγέθη μπουλονιών, και αποφάσεις εκ των προτέρων όπως το μέγεθος των οπών στερέωσης και η απόσταση μεταξύ τους.

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

Μπορούμε να το επαναλάβουμε στη βιομηχανία λογισμικού;

Σίγουρα μπορούμε! Χρησιμοποιώντας διεπαφές και αντιστροφή της αρχής ελέγχου. το καλύτερο μέρος είναι το γεγονός ότι αυτή η προσέγγιση μπορεί να χρησιμοποιηθεί σε οποιαδήποτε αντικειμενοστραφή γλώσσα: Java, C #, Swift, TypeScript, JavaScript, PHP - η λίστα συνεχίζεται και συνεχίζεται. Δεν χρειάζεστε φανταχτερό πλαίσιο για να εφαρμόσετε αυτήν τη μέθοδο. Πρέπει απλώς να ακολουθήσετε μερικούς απλούς κανόνες και να παραμείνετε πειθαρχημένοι.

Η αντιστροφή του ελέγχου είναι ο φίλος σας

Όταν άκουσα για πρώτη φορά την αντιστροφή του ελέγχου, συνειδητοποίησα αμέσως ότι βρήκα μια λύση. Είναι μια ιδέα της λήψης υπαρχουσών εξαρτήσεων και της αντιστροφής τους χρησιμοποιώντας διεπαφές. Οι διεπαφές είναι απλές δηλώσεις μεθόδων. Δεν παρέχουν συγκεκριμένη εφαρμογή. Ως αποτέλεσμα, μπορούν να χρησιμοποιηθούν ως συμφωνία μεταξύ δύο στοιχείων σχετικά με τον τρόπο σύνδεσής τους. Μπορούν να χρησιμοποιηθούν ως αρθρωτά βύσματα, αν θέλετε. Εφόσον ένα στοιχείο παρέχει τη διεπαφή και ένα άλλο στοιχείο παρέχει την υλοποίησή του, μπορούν να συνεργαστούν χωρίς να γνωρίζουν ο ένας τον άλλον. Είναι υπέροχο.

Ας δούμε σε ένα απλό παράδειγμα πώς μπορούμε να αποσυνδέσουμε το σύστημά μας για να δημιουργήσουμε αρθρωτό κώδικα. Τα παρακάτω διαγράμματα έχουν εφαρμοστεί ως απλές εφαρμογές Java. Μπορείτε να τα βρείτε σε αυτό Αποθήκη GitHub .

Πρόβλημα

Ας υποθέσουμε ότι έχουμε μια πολύ απλή εφαρμογή που αποτελείται μόνο από ένα Main τάξη, τρεις υπηρεσίες και μία Util τάξη. Αυτά τα στοιχεία εξαρτώνται το ένα από το άλλο με πολλούς τρόπους. Παρακάτω, μπορείτε να δείτε μια εφαρμογή χρησιμοποιώντας την προσέγγιση 'big ball of mud'. Τα μαθήματα απλώς καλούν το ένα το άλλο. Είναι σφιχτά συνδεδεμένα και δεν μπορείτε απλά να αφαιρέσετε ένα στοιχείο χωρίς να αγγίξετε άλλα. Οι εφαρμογές που δημιουργούνται με αυτό το στυλ σας επιτρέπουν να αναπτύξετε αρχικά γρήγορα. Πιστεύω ότι αυτό το στυλ είναι κατάλληλο για έργα δοκιμαστικής έννοιας, καθώς μπορείτε να παίζετε με πράγματα εύκολα. Ωστόσο, δεν είναι κατάλληλο για λύσεις έτοιμες για παραγωγή, επειδή ακόμη και η συντήρηση μπορεί να είναι επικίνδυνη και οποιαδήποτε αλλαγή μπορεί να δημιουργήσει απρόβλεπτα σφάλματα. Το παρακάτω διάγραμμα δείχνει αυτήν την μεγάλη αρχιτεκτονική λάσπης.

Γιατί η Έγχυση Εξάρτησης το κατάλαβε

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

Η μόνη διαφορά μεταξύ της τρέχουσας κατάστασης και μιας μεγάλης μπάλας λάσπης είναι το γεγονός ότι τώρα, αντί να καλούμε τάξεις απευθείας, τα καλούμε μέσω των διεπαφών τους. Βελτιώνει ελαφρώς τα διαχωριστικά στοιχεία μεταξύ τους. Εάν, για παράδειγμα, θέλετε να επαναχρησιμοποιήσετε Service A σε ένα διαφορετικό έργο, θα μπορούσατε να το κάνετε αυτό λαμβάνοντας το Service A το ίδιο, μαζί με Interface A, καθώς και Interface B και Interface Util. Όπως μπορείτε να δείτε, Service A εξαρτάται ακόμη από άλλα στοιχεία. Ως αποτέλεσμα, εξακολουθούμε να αντιμετωπίζουμε προβλήματα με την αλλαγή κώδικα σε ένα μέρος και τη βλάβη της συμπεριφοράς σε άλλο. Δημιουργεί ακόμα το ζήτημα ότι εάν τροποποιήσετε Service B και Interface B, θα πρέπει να αλλάξετε όλα τα στοιχεία που εξαρτώνται από αυτό. Αυτή η προσέγγιση δεν λύνει τίποτα. κατά τη γνώμη μου, προσθέτει απλώς ένα επίπεδο διεπαφής πάνω από στοιχεία. Δεν πρέπει ποτέ να κάνετε ένεση εξαρτήσεων, αλλά αντίθετα θα πρέπει να τα απαλλαγείτε μια για πάντα. Ζήτω για ανεξαρτησία!

Η λύση για τον αρθρωτό κώδικα

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

η στρατηγική είναι ο σχεδιασμός ενός επιχειρηματικού μοντέλου

Λάβετε υπόψη ότι, σε αυτήν την αρχιτεκτονική, μόνο το Main τάξη έχει πολλές εξαρτήσεις. Συνδέει όλα τα στοιχεία μαζί και ενσωματώνει την επιχειρηματική λογική της εφαρμογής.

Οι υπηρεσίες, από την άλλη πλευρά, είναι εντελώς ανεξάρτητα στοιχεία. Τώρα, μπορείτε να αφαιρέσετε κάθε υπηρεσία από αυτήν την εφαρμογή και να τις χρησιμοποιήσετε ξανά κάπου αλλού. Δεν εξαρτώνται από οτιδήποτε άλλο. Αλλά περιμένετε, γίνεται καλύτερο: Δεν χρειάζεται να τροποποιήσετε ξανά αυτές τις υπηρεσίες, αρκεί να μην αλλάξετε τη συμπεριφορά τους. Όσο αυτές οι υπηρεσίες κάνουν ό, τι έπρεπε να κάνουν, μπορούν να παραμείνουν ανέγγιχτες μέχρι το τέλος του χρόνου. Μπορούν να δημιουργηθούν από έναν επαγγελματία μηχανικός λογισμικού ή ένας κωδικοποιητής για πρώτη φορά που παραβιάστηκε από τον χειρότερο κώδικα μακαρονιών που έχει μαγειρευτεί ποτέ με goto δηλώσεις που αναμιγνύονται. Δεν έχει σημασία, επειδή η λογική τους είναι ενσωματωμένη. Όσο φρικτό μπορεί να είναι, δεν θα διαρρεύσει ποτέ σε άλλες τάξεις. Αυτό σας δίνει επίσης τη δύναμη να διαχωρίζετε την εργασία σε ένα έργο μεταξύ πολλών προγραμματιστών, όπου κάθε προγραμματιστής μπορεί να εργάζεται στο δικό του στοιχείο ανεξάρτητα χωρίς να χρειάζεται να διακόψετε κάποιον άλλο ή ακόμη και να μάθετε για την ύπαρξη άλλων προγραμματιστών.

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

Στοιχείο

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

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

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

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

Ας ρίξουμε επίσης μια ματιά σε ένα απλό παράδειγμα 'Hello World' που δημιουργήθηκε στην Java.

public class Main { interface ElementListener { void printOutput(String message); } static class Element { private ElementListener listener; public Element(ElementListener listener) { this.listener = listener; } public void sayHello() { String message = 'Hello World of Elements!'; this.listener.printOutput(message); } } static class App { public App() { } public void start() { // Build listener ElementListener elementListener = message -> System.out.println(message); // Assemble element Element element = new Element(elementListener); element.sayHello(); } } public static void main(String[] args) { App app = new App(); app.start(); } }

Αρχικά, ορίζουμε ElementListener για να καθορίσετε τη μέθοδο που εκτυπώνει την έξοδο. Το ίδιο το στοιχείο ορίζεται παρακάτω. Κατά την κλήση sayHello στο στοιχείο, εκτυπώνει απλά ένα μήνυμα χρησιμοποιώντας το ElementListener. Παρατηρήστε ότι το στοιχείο είναι εντελώς ανεξάρτητο από την εφαρμογή printOutput μέθοδος. Μπορεί να εκτυπωθεί στην κονσόλα, σε φυσικό εκτυπωτή ή σε ένα φανταχτερό περιβάλλον χρήστη. Το στοιχείο δεν εξαρτάται από αυτήν την εφαρμογή. Λόγω αυτής της αφαίρεσης, αυτό το στοιχείο μπορεί να επαναχρησιμοποιηθεί εύκολα σε διαφορετικές εφαρμογές.

Τώρα ρίξτε μια ματιά στο κύριο App τάξη. Εφαρμόζει τον ακροατή και συναρμολογεί το στοιχείο μαζί με συγκεκριμένη εφαρμογή. Τώρα μπορούμε να αρχίσουμε να το χρησιμοποιούμε.

Μπορείτε επίσης να εκτελέσετε αυτό το παράδειγμα σε JavaScript εδώ

Αρχιτεκτονική Στοιχείων

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

Η δομή μιας εφαρμογής ιστού πλήρους στοίβας που θέλω να χρησιμοποιήσω έχει ως εξής:

src ├── client │ ├── app │ └── elements │ └── server ├── app └── elements

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

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

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

Παράδειγμα hands-on

Πιστεύοντας ότι η πρακτική είναι πάντα η θεωρία ατού, ας ρίξουμε μια ματιά σε ένα πραγματικό παράδειγμα που δημιουργήθηκε στο Node.js και το TypeScript.

Παράδειγμα πραγματικής ζωής

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

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

Είναι ένα βασικό παράδειγμα που δείχνει ότι μπορείτε να ξεκινήσετε την εισαγωγή στοιχείων στη δική σας εφαρμογή σήμερα. Μπορείτε να ξεκινήσετε τη διάκριση ανεξάρτητων στοιχείων και να διαχωρίσετε τη λογική τους. Δεν έχει σημασία πόσο ακατάστατος είναι ο κώδικας στον οποίο εργάζεστε.

πώς να κάνετε το ρομπότ

Αναπτύξτε ταχύτερα, επαναχρησιμοποιήστε πιο συχνά!

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

• Πολλά προβλήματα στο λογισμικό συμβαίνουν λόγω των εξαρτήσεων μεταξύ πολλών στοιχείων.

• Κάνοντας μια αλλαγή σε ένα μέρος, μπορείτε να εισαγάγετε απρόβλεπτη συμπεριφορά κάπου αλλού.

Τρεις κοινές αρχιτεκτονικές προσεγγίσεις είναι:

• Η μεγάλη μπάλα λάσπης. Είναι εξαιρετικό για ταχεία ανάπτυξη, αλλά όχι τόσο καλό για σταθερούς παραγωγικούς σκοπούς.

• Ενεση εξάρτησης. Είναι μια μισή ψημένη λύση που πρέπει να αποφύγετε.

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

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

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

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

Επίσης, εάν βρεθείτε να βελτιστοποιείτε πρόωρα τον κωδικό σας, διαβάστε Πώς να αποφύγετε την κατάρα της πρόωρης βελτιστοποίησης από τους συναδέλφους ApeeScapeer Kevin Bloch.

Σχετίζεται με: Βέλτιστες πρακτικές JS: Δημιουργήστε ένα Disc Disc Bot με TypeScript και Dependency Injection

Κατανόηση των βασικών

Τι δυσκολεύει τη συντήρηση του μη προγραμματισμένου κώδικα και είναι επιρρεπές σε σφάλματα;

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

Τι είναι η αρθρωτή αρχιτεκτονική;

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

Ποιοι είναι οι διαφορετικοί τύποι αρχιτεκτονικών κώδικα που χρησιμοποιούν οι προγραμματιστές;

Οι κοινές αρχιτεκτονικές προσεγγίσεις είναι: 1) Η μεγάλη μπάλα λάσπης: Μεγάλη για ταχεία ανάπτυξη, αλλά όχι τόσο κατάλληλη για σταθερούς σκοπούς παραγωγής. 2) Έγχυση εξάρτησης: Ένα μισό ψημένο διάλυμα που πρέπει να αποφύγετε. 3) Αρχιτεκτονική στοιχείων: Είναι διατηρήσιμο και εξαιρετικό για σταθερές κυκλοφορίες παραγωγής.