Επειδή όλοι ήταν “optimization freaks” και ήταν και ένας cool τρόπος να δείξεις ότι μόνο εσύ μπορείς να μιλήσεις με την μηχανή.
Τα μηχανήματα δεν είχαν πάντα άφθονη RAM.
Οι servers δεν ήταν τόσο εύκολο να αναβαθμιστούν.
Οι browsers δεν είχαν την ίδια δύναμη.
Τα κινητά δεν μπορούσαν να σηκώσουν τα πάντα.
Και το “απλώς βάλε” δεν ήταν πάντα επιλογή.
Οπότε υπήρχε μια πιο έντονη αίσθηση ευθύνης.
Αν το πρόγραμμα ήταν βαρύ, φαινόταν.
Αν η σελίδα αργούσε, φαινόταν.
Αν ένα loop ήταν κακογραμμένο, φαινόταν.
Αν η εφαρμογή κατανάλωνε πολύ μνήμη, κάποια στιγμή το μηχάνημα θα σου το υπενθύμιζε.
Και σίγουρα θα στο υπενθύμιζε και ο end client.
Σήμερα, η κατάσταση έχει αλλάξει αρκετά.
Οι υπολογιστές είναι πολύ πιο δυνατοί.
Οι browsers μπορούν να σηκώσουν πολύ πιο σύνθετες εφαρμογές.
Οι servers αναβαθμίζονται πιο εύκολα.
Το cloud έκανε το scaling πιο προσβάσιμο.
Τα frameworks κάνουν μεγάλο μέρος της δουλειάς για εμάς.
Και οι χρήστες έχουν συνηθίσει σε πιο “βαριές” εμπειρίες.
Αυτό έχει πολλά θετικά.
Μπορούμε να φτιάξουμε πιο πλούσια interfaces.
Πιο γρήγορα interactive εφαρμογές , πλούσια σε στατιστικά dashboards, one export applications τύπου με Expo έχεις android , ios και web app .
Δεν χρειάζεται πλέον να σκεφτόμαστε κάθε γραμμή κώδικα σαν να γράφουμε για μηχάνημα με ελάχιστα resources που τελειώνουν σε κάθε λάθος κίνηση.
Και αυτό είναι πρόοδος ( για την τεχνολογία όχι τους devs :P ) .
Αλλά όπως γίνεται συχνά στην τεχνολογία, κάθε ευκολία δημιουργεί και μια νέα αδυναμία.
Πλέον, επειδή τα μηχανήματα αντέχουν περισσότερο, πολλές φορές ο κακός ή βαρύς κώδικας απλώς κρύβεται καλύτερα.
Δεν φαίνεται αμέσως , ούτε παρουσιάζει σημάδια.
Απλώς φορτώνει λίγο πιο αργά, το render κρύβεται πίσω από καλοστυμένο loader. Κανείς δεν ελέγχει το πόση μνήμη καταναλώνει πόσο μάλλον να ασχοληθεί για το γιατί. Οι φωτογραφίες που φορτώνουν μπορεί να μην έχουν γίνει καν compressed κάνοντας λίγο πιο αργό το response.
Και επειδή αυτό το “λίγο” δεν φαίνεται άμεσα, εύκολα το αγνοούμε.
Μέχρι να μαζευτεί.
Γιατί το πρόβλημα με το unoptimized software δεν είναι πάντα ότι αποτυγχάνει εντυπωσιακά.
Πολλές φορές απλώς γίνεται αργά, σιωπηλά και σταδιακά πιο βαρύ.
Και κάπου εκεί μπαίνει η σύγχρονη λογική:
“Δεν πειράζει, θα βάλουμε μεγαλύτερο server.” “ Ποιος έχει ακόμα αυτό το μοντέλου κινητού “
Το οποίο είναι γεγονός καταστροφικό . Γιατί από την αρχή περιορίζεις το κοινό σου. Κάθε κινητό ( εντός λογικών πλαισίων ) θα ήταν σωστό να τρέχει αυτό που δημιουργείς. Γιατί η μεγαλύτερη ικανοποίηση είναι στην συνεχή και ευρύ χρήσης της δημιουργίας σου.
Αυτή η λανθασμένη νοοτροπία του unoptimized κώδικα έχει γίνει αρκετά συνηθισμένη.
Πρέπει να είμαστε και δίκαιοι.
Το premature optimization είναι και αυτό πρόβλημα.
Αν προσπαθείς να κάνεις optimize κάτι πριν καν καταλάβεις αν χρειάζεται, μπορεί να χάσεις χρόνο, να κάνεις τον κώδικα πιο περίπλοκο και να δημιουργήσεις τεχνικό βάρος χωρίς λόγο.
Όμως άλλο πράγμα είναι να αποφεύγεις το premature optimization.
Και άλλο να γράφεις κώδικα χωρίς καμία σκέψη για performance, επειδή “κάπως θα το σηκώσει το μηχάνημα”.
Εκεί είναι η διαφορά.
Δεν χρειάζεται να κάνουμε optimization παντού.
Αλλά χρειάζεται να μην αδιαφορούμε.
Γιατί το performance δεν είναι μόνο τεχνικό θέμα.
Είναι εμπειρία χρήστη.
Ένας χρήστης που περιμένει πολύ να φορτώσει μια σελίδα, δεν σκέφτεται “μάλλον ο developer δεν έκανε lazy loading”.
Σκέφτεται απλώς ότι η εφαρμογή είναι αργή.
Ένας χρήστης που πατάει ένα κουμπί και καθυστερεί η απόκριση, δεν ενδιαφέρεται αν φταίει το frontend state, το backend query ή το API latency.
Απλώς νιώθει ότι κάτι δεν πάει καλά.
Ένας χρήστης με πιο παλιό κινητό δεν ενδιαφέρεται αν εμείς έχουμε MacBook, γρήγορο internet και local environment που τρέχει τέλεια.
Αν σε εκείνον η εφαρμογή κολλάει, τότε για εκείνον η εφαρμογή κολλάει.
Και εδώ είναι κάτι που ξεχνάμε εύκολα. Το οποίο είναι η μεγαλειώδης γκάμα συσκευών με internet και επεξεργαστική δύναμη .
Γιατί στο δικό μας μηχάνημα όλα φαίνονται γρήγορα. Μέχρι να το ανοίξει κάποιος άλλος και να μας ρωτήσει αν η σελίδα φορτώνει ή απλώς διαλογίζεται.
Η σημερινή άνεση των resources μάς έκανε πιο παραγωγικούς.
Αλλά ίσως μας έκανε και λίγο πιο απρόσεκτους.
Παλαιότερα, όταν κάτι ήταν βαρύ, αναγκαζόσουν να το κοιτάξεις. Δεν είχες πάντα την πολυτέλεια να το κρύψεις. Σήμερα, έχουμε περισσότερους τρόπους να καλύψουμε την αργή εμπειρία.
Και αυτό φαίνεται πολύ στο web.
Ένα site μπορεί να φορτώνει τεράστια JavaScript bundles για την δημιουργία animations και data tracking κάνοντας request συνέχεια για την βελτίωση τον cookies και να σε πείσουν να ψωνίσεις αλλά με τι κόστος ( πέρα ότι θα τινάξεις την κάρτα σου : D )
Και παρ’ όλα αυτά, στην αρχή να φαίνεται “εντάξει”.
Μέχρι να μεγαλώσει.
Μέχρι να μπουν περισσότεροι χρήστες.
Μέχρι να προστεθούν περισσότερα features.
Το ίδιο συμβαίνει και στο backend.
Ένα κακό query μπορεί να μη φαίνεται με 10 εγγραφές.
Με 10.000 αρχίζει να φαίνεται.
Με 1.000.000 γίνεται πρόβλημα.
Ένα API endpoint μπορεί να είναι αποδεκτό όταν το χτυπάει ένας developer στο local.
Αλλά όχι όταν το χτυπάνε πολλοί χρήστες ταυτόχρονα.
Ένα service μπορεί να φαίνεται απλό.
Μέχρι να αρχίσει να τρώει RAM, CPU και χρήματα.
Και εκεί έρχεται η άλλη πλευρά της αναβάθμισης.
Ναι, μπορείς να βάλεις μεγαλύτερο server.
Αλλά αυτό δεν σημαίνει ότι έλυσες το πρόβλημα.
Μερικές φορές απλώς αγόρασες χρόνο.
Ή χειρότερα, αγόρασες την ψευδαίσθηση ότι το πρόβλημα δεν υπάρχει.
Γιατί αν ο κώδικας είναι σπάταλος, το scaling απλώς κάνει τη σπατάλη ακριβότερη.
Και αυτό είναι αρκετά σημαντικό σήμερα, ειδικά σε cloud περιβάλλοντα.
Παλιά το βαρύ software κόστιζε κυρίως σε εμπειρία χρήστη και hardware.
Σήμερα κοστίζει και σε παρόχους σερβερ.
Όλα αυτά κάποια στιγμή μεταφράζονται σε κόστος.
Μπορεί όχι από την πρώτη μέρα.
Αλλά όσο μεγαλώνει ένα project, τόσο περισσότερο φαίνεται.
Και εδώ επιστρέφουμε στο βασικό ερώτημα.
Πρέπει να γράφουμε πάντα τον πιο optimized κώδικα;
Όχι.
Πρέπει όμως να γράφουμε κώδικα με συνείδηση.
Να ξέρουμε πότε κάτι είναι “αρκετά καλό”.
Αλλά και πότε το “αρκετά καλό” είναι απλώς δικαιολογία.
Να καταλαβαίνουμε πότε ένα animation βελτιώνει την εμπειρία.
Και πότε απλώς κρύβει ένα αργό interface.
Να ξέρουμε πότε το scaling είναι σωστή λύση.
Και πότε απλώς καλύπτει κακή αρχιτεκτονική.
Να ξέρουμε πότε αξίζει να κάνουμε optimize.
Και πότε απλώς κυνηγάμε μικροβελτιώσεις που δεν έχουν σημασία.
Αυτό, για μένα, είναι το σωστό balance.
Όχι εμμονή με το performance.
Αλλά σεβασμός στο performance.
Όχι να γράφουμε κώδικα σαν να είμαστε ακόμα σε μηχανήματα 20 χρόνια πίσω.
Αλλά ούτε και να γράφουμε κώδικα σαν οι πόροι να είναι άπειροι.
Γιατί δεν είναι.
Απλώς τώρα φαίνονται πιο άπειροι.
Ο καλός developer δεν είναι αυτός που κάνει τα πάντα optimized από την πρώτη γραμμή.
Ούτε αυτός που αγνοεί τελείως το optimization επειδή “οι υπολογιστές είναι γρήγοροι”.
Ο καλός developer είναι αυτός που καταλαβαίνει το context.
Ξέρει πότε να δώσει προτεραιότητα στην ταχύτητα ανάπτυξης.
Και ξέρει πότε απλώς προσπαθεί να τελειοποιήσει κάτι που δεν χρειάζεται.
Το optimization δεν πρέπει να είναι φόβος.
Πρέπει να είναι συνείδηση.
Γιατί στο τέλος, ο χρήστης δεν βλέπει τον κώδικα.
Βλέπει την εμπειρία.
Και αν η εμπειρία είναι αργή, βαριά ή κουραστική, δεν τον ενδιαφέρει αν πίσω από αυτό υπάρχει ωραίο framework, μοντέρνο stack ή όμορφο animation.
Θα νιώσει ότι κάτι δεν δουλεύει σωστά.
Και ίσως αυτό είναι το σημείο που πρέπει να κρατήσουμε.
Η τεχνολογία μάς έδωσε πιο δυνατά μηχανήματα, πιο εύκολο scaling και πιο γρήγορα εργαλεία.
Αλλά αυτό δεν πρέπει να μας κάνει να ξεχνάμε τη βασική ιδέα.
Ο κώδικας δεν πρέπει απλώς να δουλεύει.
Πρέπει να σέβεται και το μηχάνημα που τον τρέχει.
Και κυρίως, τον άνθρωπο που τον χρησιμοποιεί.