Όταν ξεκινάμε ένα νέο project, το πρώτο πράγμα που κάνουμε οι περισσότεροι είναι λάθος: προσπαθούμε να αποφασίσουμε ποια τεχνολογία θα χρησιμοποιήσουμε. Αρχίζουμε να σκεφτόμαστε «React ή Vue, Postgres ή Mongo, monolith ή microservices». Όμως καμία από αυτές τις ερωτήσεις δεν έχει νόημα προτού απαντήσεις τις ερωτήσεις που πρέπει να προηγηθούν.

Σε αυτό το άρθρο θα περιγράψω με βάση τι παίρνω τις αποφάσεις αρχιτεκτονικής και τεχνολογίας όταν ξεκινώ ένα project — δηλαδή ποιες ερωτήσεις κάνω πριν διαλέξω εργαλείο. Ο στόχος εδώ δεν είναι να πω «χρησιμοποίησε αυτό το stack»· είναι να χτίσω ένα πλαίσιο σκέψης για το πώς να αποφασίζεις.

Ξεκίνα από ερωτήσεις, όχι από τεχνολογία

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

• Ποια είναι η κλίμακα; 100 χρήστες ή 1 εκατομμύριο; 10 αιτήματα την ημέρα ή 10.000 το δευτερόλεπτο; Η πραγματική απάντηση για τα περισσότερα project είναι πολύ μικρότερη απ' ό,τι νομίζεις — και αυτό απλοποιεί πολλά.
• Τι ξέρει η ομάδα; Όχι το «καλύτερο» εργαλείο, αλλά αυτό που ξέρει καλύτερα η ομάδα είναι συχνά η σωστή επιλογή. Το κόστος να ξεκινήσεις με μια τεχνολογία που δεν ξέρεις μπορεί να ξεπερνά το πλεονέκτημα που προσφέρει.
• Σε πόσο χρόνο πρέπει να βγει; Ένα MVP δύο εβδομάδων και ένα προϊόν που θα ζήσει πέντε χρόνια δεν παίρνουν τις ίδιες αποφάσεις.
• Πώς μοιάζουν τα δεδομένα; Είναι σχεσιακά (συνδέονται χρήστες, παραγγελίες, σχόλια μεταξύ τους), ή χαλαρά και χωρίς δομή; Αυτή η μία ερώτηση απαντά το μεγαλύτερο μέρος της απόφασης για τη βάση δεδομένων.
• Πόσο διαδραστικό / real-time είναι; Γράφεις ένα blog, ή μια εφαρμογή με ταυτόχρονη επεξεργασία;
• Ποιος θα το συντηρεί, και για πόσο; Θα συνεχίσεις εσύ το project σε έξι μήνες, ή θα το παραδώσεις;

Το να διαλέγεις τεχνολογία χωρίς να απαντήσεις αυτά μοιάζει με το να ράβεις κοστούμι χωρίς να πάρεις μέτρα.

Το πιο χρήσιμο πλαίσιο: είναι αναστρέψιμο;

Χωρίζω κάθε απόφαση που παίρνω με μία ερώτηση: είναι εύκολο ή δύσκολο να αναιρέσω αυτή την απόφαση αργότερα;

Κάποιες αποφάσεις είναι «μονόδρομες πόρτες» — μόλις περάσεις, η επιστροφή είναι πολύ ακριβή. Η αλλαγή της βάσης δεδομένων αφού το project έχει μεγαλώσει, το ξαναχτίσιμο του βασικού μοντέλου δεδομένων από την αρχή, η επαναφορά μιας αρχιτεκτονικής microservices πίσω σε monolith... Αυτές είναι μονόδρομες πόρτες και αξίζουν τον χρόνο σου.

Άλλες αποφάσεις είναι «αμφίδρομες πόρτες» — αν δεν σου αρέσει, γυρνάς εύκολα πίσω. Ένα CSS framework, μια βιβλιοθήκη logging, η δομή φακέλων... Το να συζητάς γι' αυτά για ώρες είναι σπατάλη· διάλεξε το πιο λογικό και προχώρα. Αν κάνεις λάθος, το αλλάζεις σε μισή μέρα.

Μεγάλο μέρος της διαφοράς ανάμεσα σε junior και senior developer είναι εδώ: ο έμπειρος developer ξεχωρίζει γρήγορα ποια απόφαση είναι ποια πόρτα και βάζει την ενέργειά του στο σωστό σημείο. Γρήγορος στις αμφίδρομες πόρτες, αργός και προσεκτικός στις μονόδρομες.

Επιλογή αρχιτεκτονικής: σχεδόν πάντα ξεκίνα με monolith

Η ερώτηση «microservices ή monolith» συζητιέται υπερβολικά στα νέα project. Η πρακτική μου απάντηση είναι ξεκάθαρη: ξεκίνα με monolith.

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

Ο σωστός δρόμος είναι αυτός: ξεκίνα με ένα monolith χωρισμένο σε καλά modules. Κράτα τα όρια καθαρά. Όταν έρθει η μέρα που ένα κομμάτι χρειάζεται πραγματικά να κάνει ανεξάρτητο scaling, τότε ξεχώρισέ το. Αυτό σημαίνει να ανοίγεις τη «μονόδρομη πόρτα» όσο πιο αργά γίνεται — και συνήθως δεν χρειάζεται να την ανοίξεις καθόλου.

Βάση δεδομένων: ας είναι το default σου σχεσιακή

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

Η NoSQL (όπως η Mongo) έχει τη θέση της — πραγματικά αδόμητα δεδομένα, πολύ μεγάλη κλίμακα, ή περιπτώσεις όπου το schema αλλάζει συνεχώς. Αλλά το να ξεκινήσεις με NoSQL «για να είσαι ευέλικτος» συνήθως σημαίνει να χάνεις τις σχέσεις και τις εγγυήσεις συνέπειας που θα αναγκαστείς να χτίσεις στο χέρι αργότερα. Αν έχεις σχέσεις — οι παραγγελίες ενός χρήστη, τα προϊόντα μιας παραγγελίας — η σχεσιακή βάση είναι ήδη σχεδιασμένη γι' αυτή τη δουλειά.

Κανόνας: διάλεξε NoSQL όχι επειδή είναι «cool», αλλά επειδή μια μετρήσιμη ανάγκη την καθιστά απαραίτητη.

Απέφυγε το over-engineering: λύσε το πρόβλημα του σήμερα

Το πιο ύπουλο λάθος στα νέα project είναι ο σχεδιασμός για ένα μέλλον που δεν υπάρχει ακόμη. Το να προσθέτεις πολυπλοκότητα σήμερα ρωτώντας «κι αν έρθουν εκατομμύρια χρήστες;» ή «κι αν προσθέσουμε αυτό το feature αργότερα;» είναι σχεδόν πάντα σπατάλη. Επειδή:

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

Ξεκίνα με την απλούστερη λύση που δουλεύει. Όταν νιώσεις πραγματικό πόνο — όταν πραγματικά επιβραδυνθείς, όταν πραγματικά φτάσεις σε όριο — τότε πρόσθεσε πολυπλοκότητα. Το πρόωρο optimization είναι ένας λογαριασμός που πληρώνεις προκαταβολικά για ένα πρόβλημα που δεν έχεις.

Στην πράξη: η checklist μου πριν ξεκινήσω

Να η σειρά που περνάω από το μυαλό μου πριν μπω σε ένα project:

1. Τι φτιάχνω, και για ποιον; Μπορώ να το εξηγήσω σε μία πρόταση;
2. Ποιοι είναι οι πραγματικοί περιορισμοί; Κλίμακα, χρόνος, ομάδα, σχήμα δεδομένων.
3. Ποιο κομμάτι είναι το πιο ριψοκίνδυνο / πιο αβέβαιο; Ξεκαθάρισέ το πρώτο· τα υπόλοιπα παίρνουν μορφή γύρω από αυτό.
4. Ποιες αποφάσεις είναι μονόδρομες πόρτες; Αφιέρωσε χρόνο σε αυτές, προχώρα γρήγορα στις υπόλοιπες.
5. Πώς το κάνω αυτό στην απλούστερη δυνατή μορφή; Κράτα την πολυπλοκότητα για αργότερα, για όταν πραγματικά χρειαστεί.

Συμπέρασμα

Η καλή αρχιτεκτονική δεν είναι να διαλέγεις τα νεότερα ή τα ισχυρότερα εργαλεία· είναι να δίνεις την απλούστερη απάντηση που ταιριάζει καλύτερα στους πραγματικούς περιορισμούς αυτού του project. Δεν υπάρχει «η καλύτερη αρχιτεκτονική» — υπάρχει η αρχιτεκτονική που ταιριάζει καλύτερα στο context της.

Γι' αυτό στο επόμενο project, αντί να ξεκινήσεις με «ποια τεχνολογία να χρησιμοποιήσω», ρώτα «ποιο είναι το πραγματικό πρόβλημα αυτού του project, ποια απόφαση είναι δύσκολο να αναιρεθεί, και ποιο είναι το απλούστερο πράγμα που δουλεύει». Η επιλογή τεχνολογίας θα προκύψει από μόνη της από τις απαντήσεις.

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