Tuesday, March 20, 2007

Δεν θα γίνεις database admin ποτέ..εφιάλτης στον δρόμο με τα JOIN!

Η πολύ καλή και έμπειρη (πρήων πια) συνάδελφος μου MA.D έγραψε σε κάποιες απο τις συνομιλίες μας περι ORM κάτι πολύ καλό το οποίο ιδεατά θα άρχιζε ένα paper περι βάσεων δεδομένων, ORM τεχνολογιών για προγραμματιστές.

Δεν είσαι database administrator...και δεν θα γίνεις ποτέ.
Απλό σύντομο και καταδικαστικό όπως σχολίασε αργότερα. Πόσο δίκιο έχει με αυτή την μικρή φράση. Απευθύνεται σε όλους τους enterprise και μη developers οι οποίοι καθημερινα δίνουν την μάχη της βάσης. Ναι ναι, το πως θα πάρεις, πως θα σώσεις, με πιο τρόπο θα σώσεις, και που θα σώσεις τα δεδομένα σου είναι ένα απο τα πιο σημαντικά κομμάτια επιτυχίας μια σύγχρονης enterprise level εφαρμογής.Το λεγόμενο database access ειναι ο σύγχρονος πονοκέφαλος των software developer οι οποίοι προσπαθούν να παλέψουν με το θηρίο ευγενικά και αναίμακτα αν και δεν είναι πάντα εφικτό!

Με την πάρωδο του χρόνο, ιδιαίτερα εμείς οι Java developers αποκτήσαμε κάποια όπλα στην μάχη μας με τις relational βασεις και το πως θα τις κανουμε manipulate. Τα όπλα αυτά ειναι όλες οι τεχνολογίες Object Relational Mapping, οι οποίες για πρώτη φορά προσπαθούσαν να ταιριάζουν την σχεσιακή λογική των βάσεων με την object oriented λογικη του προγραμματιστή. Οι τεχνολογίες αυτές δεν εμφανίστηκαν απο την μια μέρα στην άλλη, έχουν περάσει χρόνια και αρκετά στάδια ωρίμανσης για να μπορούμε αυτή την στιγμή τουλάχιστον στον κόσμο της Java να μιλάμε για standards και μηχανισμούς οι οποίοι θα περιγράφουν ολες αυτές τις τεχνολογίες κάτω απο κοινά API.

Όμως το ερώτημα είναι, τελικά οι ORM τεχνολογίες απελευεθέρωσαν τον Java Enterprise Developer.. τον J2ee technical leader απο τον πόνο της συσχέτισης με τη βάση και ότι αυτό συνεπάγεται. Η απάντηση είναι ναι και όχι. Πολλές φορές σε διάφορα project ανάλογα με τις συνθήκες οδηγούμαστε να πάρουμε τεχνικές και τεχνολογικές αποφάσεις οι οποίες θα προχωρήσουν το project μας ένα βήμα παραπέρα αλλα παράλληλα θα είναι ρεαλιστικές για την ομάδα μας.

Η χρήση του ORM για πολλούς developer σημαίνει την απελευθέρωση μας απο τον κακό database administrator. Τον άνθρωπο που σκέφτεται πινακες..ενω εμείς σκεφτόμαστε κλάσεις, τον άνθρωπο που σου δίνει σε μερικά λεπτα το παράξενο εκείνο sql statement να τρέξεις σε αντίθεση με κλήσεις σε κάποιο API του ORM σου..το οποίο θα παράξει αυτόματα κάτι παρόμοιο.

Η αλήθεια είναι ότι ανάλογα με το project και τις ανάγκες σου, το πρόβλημα της βάσης δεδομένων μπορεί να έχει πολλά πρόσωπα. Προσωπικά έχω δει project τα οποία πατήσανε σε ηδη αποδεδειγμένα object model και σχήματα και παίξανε ωραία, σε project τα οποία τους ζητήθηκε να στήσουν πάνω σε τεράτα τον 500 πινάκων και σε project που ειχαν λευκό χαρτί.

Υπάρχει η απόλυτη απάντηση για το πότε θα χρησιμοποιήσεις ORM; Όχι. Τις πιο πολλές φορές θα χρησιμοποιήσεις αλλά όχι το ιδιο. Πχ

Σε μικρά database σχήματα όπου ελέγχεις άριστα την βάση ένα ORM που θα έρθει να κάτσει απο πάνω ειναι ότι πρέπει. Ξέρεις την βάση ξέρεις τι πρέπει να κάνεις φέρνεις το ORM στα μέτρα σου και τελειώνει η υπόθεση.

Όταν βρίσκεις μπροστα σου τέρατα τον 500ων πινάκων τότε σίγουρα δεν μπορείς να σκεφτείς ότι θα βάλεις το hibernate απο πάνω και θα σου λύσει τα προβλήματα, κατα πάσα πιθανότητα είτε θα τα κάνεις ολα με το χέρι, λέγε με JDBC ή θα χρησιμοποιήσεις ORM λιγότερο hibernate - like λέγε με iBatis κτλ κτλ.

Όταν όμως πρέπει να τα ξεκινήσεις ολα απο την αρχή τι γίνεται; Εκεί ίσως είναι το μεγαλύτερο πρόβλημα. Μην γελίεσαι ότι ειναι καλύτερα για σένα. Φαινομενικά ίσως ουσιαστικά είναι ο εφιάλτης και το άγχος σου.

Έχεις 2 επιλογές λοιπόν στο άσπρο χαρτί, είτε να φορέσεις το προσωπείο του database administrator και να ζωγραφίζεις κανονικοποιημένα και έξυπνα σχήματα είτε να φορέσεις το προσωπείο του προγραμματιστή και να σκεφτείς κλάσεις. Ναι αυτό που άκουσες κλάσεις, και να αφήσεις το ORM να σκεφτεί την βέλτιστη μορφή της βάσης σου.

Η εμπειρία ειναι κάτι ανεκτίμητο σε όλες τις δουλειές οπότε πάντα λειτουργεί υπέρ σου. Βρέθηκα σε αυτό το δίλημμα λοιπόν ..όταν ήμουν με ένα άσπρο χαρτί για το τι πρέπει να ακολουθήσω. Μέχρι τώρα ως developer, πατούσα σε σχήματα τα οποία ήταν ευθήνη database administrator ή όπως τους λέγαμε expert. Οι άνθρωποι αυτοί, αυτοί που πραγματικά ξέρουν και όχι κάτι ξερόλες που κυκλοφορουν στην αγορά, σκέφτοντε με πίνακες με pks και fks. Σκέφτονται relational. Δεν ξέρουν να προγραματίζουν αλλά μπορουν να σου πουν ποιος είναι ο βέλτιστος τρόπος να δομήσεις την πληροφορία σου και φυσικα πως να την πάρεις.

Ομολογώ ότι database expert δεν είμαι και όπως αναφέρθηκε πιο πάνω, δεν θα γίνω ποτέ γιατί δεν είναι αυτή η δουλειά μου, ούτε η ειδικότητα μου. Άρα το να φορέσω ένα τέτοιο προσωπείο θα ήταν λάθος. Να κάνω μια παρένθεση, εσεις που δουλευεται εκει έξω σε μεγάλα μαγαζιά της αγοράς, πόσους database expert έχετε, γνωρίζω εξαιρετικά λίγα παραδείγματα εταιριών που χρησιμοποιουν ανθρώπους και το expertise τους για αυτό το τόσο νευραλγικό σημείο κάθε μεγάλης enteprise εφαρμογής. Πολλοί θα πουν δεν μπορούμε να έχουμε, οκ δεκτό.

Για να καταλήξω. Βρέθηκα στην κατάσταση να πάρω την απόφαση η λογικη είπε, κάνε apply αυτό που ξέρεις καλύτερα. Προτίμησα λοιπόν να σκεφτω object oriented (φυσικά δεν υπονοώ ότι αγνοώ 100% το τελικό αποτέλεσμα της βάσης η δεν μπήκα στην διαδικασία να την κανονικοποιήσω στον βαθμό που μπορούσα) παρόλα αυτά, πείρα τον Ο.Ο δρόμο και παρέα με το ORM (Hibernate) περπατάμε μαζί.

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

Οι ORM experts ή τέλος πάντων οι έμπειροι developers σίγουρα θα έχουν να θυμούντε ιστορίες με τον πονόκέφαλο του Lazy initialization , τις συσχετίσεις των αντικειμένων και το πως σηκώνοντε τελίκά οι πολύπλοκοι γράφοι στην μνήμη, τα FETCH JOIN για να φέρνεις στην επιφάνεια τα object σου ..και φυσικά./.όσο πιο πολυ O.O σκέφτεσαι τόσο πιο πολλές πιθανότητες έχεις να μπλεχτείς στον εφιάλτη του πως τελικά κάνουμε map ιεραρχικές δομές δεδομένων σε σχεσιακά μοντέλα βάσης.

Καθώς λοιπόν ο μπαμπας και τα παιδιά (συνηθως αποκαλουμε έτσι μια OneToMany σχέση...αποκτουν ξαφνικα σε άλλα επίπεδα ξαδερφάκια και εχουμε παιδάκια οι οποίοι ειναι μπαμπάδες και κρατάνε στην ζωή με την σειρά τους και άλλα παιδάκια..τότε ο εφιάλτης στον δρόμο με τα JOIN ξεκινάει.

Μαμά εγω δεν είμαι database administrator αλλά για να καταφέρω να φέρω αυτό το row απο την βάση θέλω διπλό JOΙΝ με πάγο - και κερασάκι on top.Εγώ δεν ημουν ποτέ database admin και ούτε θα γίνω..παρόλα αυτά το σεξ με κάθε λογής JPQL, HQL, EJBQL δεν το γλιτώνει κανένας μας σε αυτή την ζωή!

Βοήθεια μας!


5 comments:

  1. Αηδίες! Αυτό που γράφεις περιγράφει την αλλαζονία αλλά συνάμα και τη κατάντια του σύγχρονου developer.

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

    Είναι το συναίσθημα που έχεις όταν πας να γράψεις σε μια functional γλώσσα μετά από μήνες ή χρόνια χρήσης μιας procedural/OO. Όταν, για να 'επιβιώσεις', πρέπει να επαναπροσδιορίσεις τον τρόπο με τον οποίο σκέφθεσαι, να ξαναλύσεις μικρά καθημερινά προβλήματα με νέους τρόπου, όταν σε άλλες γλώσσες οι λύσεις ερχόντουσαν πλέον μηχανικά. Το ίδιο -- σε μικρότερο βαθμό -- συναίσθημα που έχεις όταν πας να γράψεις C ή C++ μετά από ένα ή δύο χρόνια ενασχόλησης με τη Java. Παλαιότερα είχα γράψει πως το πιο σημαντικό πράγμα για κάποιον που θέλει να επιβιώσει σε αυτή τη βιομηχανία είναι η ικανότητα προσαρμογής. Όσο περνάνε τα χρόνια γίνεται ολοένα πιο επιτακτική αυτή η ικανότητα.

    Η SQL (και πόσο μάλλον οι πιο εξωτικές γλώσσες περιγραφής σχέσεων δεδομένων κλπ.) είναι με βεβαιότητα βασικό μέρος της καθημερινότητας όλων των enterprise developers. Επιβάλλει δε έναν εντελώς διαφορετικό τρόπο σκέψης από αυτόν που συνηθίζουμε ως developers γλωσσών όπως η Java. Δυστυχώς, ο μέσος προγραμματιστής δεν ενδιαφέρεται ή τέλος πάντων δεν ασχολείται αρκετά ώστε να κατανοήσει/αφομοιώσει αυτόν τον τρόπο σκέψης. Προσπαθεί με αρπαχτές να κάνει τη δουλειά του, αδιαφορώντας για την ουσία. Εκεί είναι το πρόβλημα αγαπητέ.

    Τώρα, είναι αδιαμφισβήτητο γεγονός πως οι λύσεις ORM είναι βολικές και άξιες λόγου και χρήσης -- σε κάποιον βαθμό. Όμως σε αρκετές περιπτώσεις, παρ'ότι σίγουρα βοηθούν τον developer που αδυνατεί να κατανοήσει τη λειτουργία μιας βάσης δεδομένων ή τέλος πάντων καταπιάνεται με ιδιαίτερα πολύπλοκα schemata τα οποία θα καθυστερούσαν σημαντικά την ανάπτυξη του λογισμικού, πιστεύω πως απλώς 'βαραίνουν' μια εφαρμογή, τόσο λόγω του επιπλέον κώδικα, όσο και λόγω της δομής της εφαρμογής που διογκώνεται στα πλαίσια της ενσωμάτωσης των τεχνολογιών αυτών.

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

    My €0.02 :)

    ReplyDelete
  2. Δεν νομίζω ότι γράφω αηδίες, παρόλα αυτά ας πάρουμε απο την αρχή.

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

    Ξερόλλες υπάρχουν μονο θεωρητικου επιπέδου, δηλαδη αυτοί που στην θεωρία τα ξέρουν ολα..αλλα δεν έχουν κάτι ποτέ τιποτα στην πράξη.

    Απο την δικη μου εμπειρία, μεγάλες enteprise εφαρμογές εχουν τεχνικά προβλήματα above των γνώσεων που μπορεί να θεωρήσει κανείς..οτι ξέρει. Χρειάζοντε αυτο που λεμε expertise!

    Φυσικα κανείς δεν λέει ότι ο μέσως developer δεν πρεπει να εχει γνώσεις για την βάση. Παρόλα αυτά σε παρακαλώ υπόδειξε μου έναν επαγγελματία ο οποίος ξέρεις να μου κανει perfomance αναλυση για το πως εκτελεί η oracle τα store procedures και πως η MySQL και ποιος ειναι ο βέλτιστος τρόπος στην μια και στην άλλη να δομήσω τα indexes μου. Μπορείς να μου απαντήσεις με λεπτομέρια, πως υλοποιουντε ολα αυτά, και γιατι πρεπει να εχω link tables και οχι Fks για να υλοποιήσω μια σχέση master detail?

    το post αυτό γράφτηκε για να τονίσει την ανάγκη expertise σε αυτό το επίπεδο και όχι για το πως να γράφεις select statement, αν κατανοήσες κάτι τέτοιο νομίζω κάνεις λάθος.

    όσο αναφορά τα ORM. Δεν ξέρω ποια ειναι η δικη σου εμπειρία σε αυτά, η δικη μου ειναι απόλυτη με την έννοια οτι σε όποιοι μεγάλο project και να συμμετείχα ήταν εκεί. Δεν θα μπορουσα φυσικά να φανταστώ κανένα απο αυτα τα project να υλοποιούνται με απλή SQL θα ηταν εξαιρετικα χρονοβόρο. Απο την εμπειρία μου μπορώ να πω οτι το 90% των περιπτώσεων το ORM θα σου παράξει σωστή και ισως πιο optimized SQL απ'ότι θα έγραφες εσυ..εκτός και αν εχεις μια ομαδα απο dedicated ανθρώπους οι οποιοι το μόνο που κάνουν ειναι να ασχολουντε με το θηρίο.Εξαιρετικά λίγες εταιρίες ξέρω οι οποίες πραγματικά εχουν εξιδικευμένο προσωπικό.

    Για να καταλήξω. Αυτό το post λεει, ότι το expertise τουλάχιστον στο επίπεδο που το εννοω ειναι, αναγκαίο. Δεν έχω δει ακόμα expert developers σε τόσα field.Αν μπορείς παρακαλώ υπέδειξε μου J2EE developers οι οποίοι ειναι experts σε Oracle RDBMS.

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

    Δεν πιστεύω στους all around παίχτες..και οσοι θέλουν να παρουσιάζουν τον εαυτό τους - bob μαστορες τα κάνω ολα και συμφέρο μονο σε μικράκαι συγκεκριμένα project εχουν ζωή.

    ReplyDelete
  3. Δύο προβλήματα διακρίνω στη λογική σου:

    1. Ότι εξ'ορισμού οι γνώσεις και η ικανότητα κάποιου (συμπεριλαμβανομένου του εαυτού σου) που -- φαινομενικά -- χαρακτηρίζεται developer είναι κάπου/κάπως προσδιορισμένες από κάποια ανώτερη αρχή και όποιος τολμήσει να μην συμβιβαστεί με την μετριότητα που έχει πλέον φτάσει να συνεπάγεται ο όρος 'developer' αυτομάτως χαρακτηρίζεται 'ξερόλλας'.

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

    Και δε σε κατηγορώ ούτε διαφωνώ εν γένει μαζί σου. Είναι αξιοθαύμαστο να είσαι καλός σε αυτό που κάνεις και ταυτόχρονα μετριόφρων. Είναι επίσης όμως καλό το να μην βάζεις φραγμούς και πόσο μάλλον τόσο ανούσιους όπως αυτούς που εκλαμβάνω πως βάζεις στις δυνατότητες σου, ιδιαίτερα όταν μιλάμε για τόσο βασικά πράγματα. Σαν να λέμε "εγώ κανω πρόσθεση, διαίρεση δε κάνω γιατί θα ήμουν ξερόλλας". Έχουμε φτάσει, ως κοινότητα, στο σημείο να θεωρούμε ΠΤΥΧΙΟ την γνώση της λειτουργίας ενός router της Cisco. Ή τη χρήση και βελτιστοποίηση μιας βάσης Oracle. Αυτό πιστεύεις πως γίνεται επειδή είναι τόσο δύσκολα αυτά τα θέματα; Τόση πολλή αυτή η ύλη; Γιατί νομίζεις πως τα καλύτερα πανεπιστήμια του κόσμου ούτε καν ασχολούνται με αυτές τις αηδίες; Μαθαίνεις τις ΙΔΕΕΣ και αφου τις κατανοήσεις ασχολείσαι με ό,τι χρειάζεσαι (τα εργαλεία) για να κάνεις τη δουλειά σου). Και ασχολείσαι όσο χρειαστεί για να τη κάνεις σωστά. Ο εξευτελισμός του 'developer' μήπως γίνεται επειδή 1. βγάζουν κάποιοι λεφτά, 2. κάποιοι λιγότερο ικανοί συμπολίτες μας βρίσκουν ευκολότερα δουλειές έχωντας πολύ περιορισμένο γνωσιακό πεδίο και ένα χαρτί που λέει πως μπορούν να βελτιστοποιήσουν τη hot βάση της πενταετίας και 3. υπάρχει ζήτηση για το 'expertise' που αναφέρεις, χωρίς όμως τις αποσκευές (και απαιτήσεις) ενός full-fledged μηχανικού λογισμικού;

    Η δική μου άποψη και εμπειρία σχετικά με την τεχνολογία, λένε κάτι διαφορετικό:

    Αυτοί που πραγματικά αγαπούν τη δουλειά τους, που πραγματικά ενδιαφέρονται για την τεχνολογία και αξίζουν της προσοχής σου είναι αυτοί που ναι μεν δε βάζουν όρια, αλλά ταυτόχρονα δεν πουλάνε γνώση και μούρη, δεν είναι τσάμπα-μάγκες. Αν σήμερα τους πετάξεις Oracle μπροστά τους, θα ασχοληθούν με αυτή και θα τη μάθουν αρκετά καλά ώστε να κάνουν τη δουλειά τους όσο καλύτερα γίνεται. Δε θα σου πούν πως γνωρίζουν τα πάντα για όλες τις βάσεις δεδομένων που κυκλοφορούν εκεί έξω. Δε θα σου πούν πως γνωρίζουν κάτι που δε γνωρίζουν. Δε θα σου πούν τίποτα ή -- στη χειρότερη -- θα σου πούν πως γνωρίζουν ANSI SQL, πως έχουν εμπειρία με τις Χ, Υ, Ζ βάσεις και θα κάτσουν να κάνουν τη δουλειά. Γρήγορα, ήσυχα και -- προ πάντων -- σωστά.

    Δεν έχει νόημα να σου απαριθμήσω τις βάσεις με τις οποίες έχω δουλέψει. Σε καμία περίπτωση δε θα έλεγα πως είμαι παντογνώστης ή το swiss-army knife των βάσεων δεδομένων, αλλά πιστεύω πως γνωρίζω αρκετά για να κάνω τη δουλειά μου σωστά και να είμαι περήφανος για το αποτέλεσμα. Αν χρειαστώ κι άλλη γνώση θα την αποκτήσω ή θα συνεργαστώ με τους συναδέλφους μου. Το ζήτημα μου με τη προσέγγιση σου είναι η λογική και όχι η προσωπική εμπειρία του καθενός. Προφανώς δεν είχα (ή έχω) σκοπό να σε θίξω, αν αυτό εξέλαβες από το σχόλιό μου.

    Ένας καλός developer δε μυξοκλαίει για τις διαφορές μεταξύ της εκάστοτε βάσης, ούτε δικαιολογεί την ανικανότητα του με φράσεις όπως "στην Oracle αυτό το κάναμε έτσι, τι βλακεία αυτή η PostgreSQL", κ.ο.κ. Κάθεται και διαβάζει και κάνει τη δουλειά του. Αν κρίνει πως χρειάζεται ORM χρησιμοποιεί ORM. Αν όχι, τα απορρίπτει. Προφανώς δεν ισχυρίζομαι πως ένα άτομο μπορεί να έχει όλες τις απαιτούμενες γνώσεις για τα πάντα. Αλλά κατα την άποψη μου -- σχεδόν πάντα -- όλοι μπορούν να αποδώσουν καλύτερα απ'όσο θέλουν να πιστεύουν.

    Με εκνευρίζει απίστευτα αυτή η υποβάθμιση του ατόμου. Ίσως τα γράφω αυτά επειδή ασχολούμαι με προγραμματισμό σχεδόν 20 χρόνια (και είμαι σχεδόν 27), ίσως επειδή σπούδασα σε ένα πανεπιστήμιο που ακολούθησε μια -- κατα την άποψή μου -- εξαιρετική δομή διδασκαλίας αντί να μας παπαγαλίζουν με 'εφαρμοσμένες' μπούρδες όπως κάνουν τα εκάστοτε ΙΕΚ/Polytechnics/ΤΕΙ κ.ο.κ. Ένας έξυπνος, ικανός άνθρωπος δε χρειάζεται Oracle in 21 Days για να επιβιώσει. Και διακρίνω πως η εκπαίδευση, η νοοτροπία και η βιομηχανία της αγοράς λογισμικού έχει καταντήσει ακριβώς αυτό: ένα μεγάλο "Learn Some More Bullshit That's Going To Be Obsolete in 21 Days, in 21 Days" και εξειδικεύσου.

    Τώρα επειδή βλέπω πως με παρεξήγησες, η εμπειρία είναι τρομερά σημαντικό μέρος της επαγγελματικής ζωής ενός developer. Απλά πιστεύω πως είναι επίσης --- σε πάρα μα πάρα πολλές περιπτώσεις --- και ένα πέπλο πίσω από το όποιο κρύβουμε την 'μετριότητα'. Υποβιβάζει -- κατα την άποψη μου -- την αξία του developer να βασίζεται απολύτως στην εμπειρία του σε ένα πολύ συγκεκριμένο προϊόν ή τεχνολογία. Ίσως το πιστεύω αυτό επειδή είμαι ακόμη σχετικά νέος. Μπορεί στα 40 μου να έχω κουραστεί να μαθαίνω και να ασχολούμαι με διαφορετικά πράγματα. Πάντως απ'όσο έχω δεί το να βασίζεσαι μόνον σε ένα αντικείμενο είναι τρομερά επικίνδυνο σε μια βιομηχανία που μεταλλάσεται καθημερινά. Κάποτε, στα πλαίσια ενός σχετικά μικρού project σε μια μεγάλη εταιρία, είχα γνωρίσει έναν τρομερό προγραμματιστή C++. Φοβερός τύπος, απίστευτα εκκεντρικός και πανέξυπνος. Όμως παραπλανημένος. Σε κάποια φάση μιλουσαμε για generic programming και του έδειξα λίγο κώδικα από OCAML. Ήταν έτοιμος να πηδήξει από το παράθυρο. Με 10 γραμμές, και εντελώς διαφορετική προσέγγιση η OCAML έκανε αυτό που η C++ ήθελε πάρα μα πάρα πολλή σκέψη και δουλειά. Και το καλύτερο; Ήταν γρηγορότερη (το τελευταίο καρφί στο φέρετρο). Το ηθικό δίδαγμα: προσπάθησε να ανοίξεις το μυαλό σου όσο πιο πολύ μπορείς, έστω κι αν στη δουλειά σου καταπιάνεσαι με ένα, δύο ή πέντε μόνον εργαλεία. Το να μαθαίνεις δε σε κάνει ξερόλλα. Σε κάνει εξυπνότερο, ικανότερο και πιο καταρτισμένο να αντιμετωπίσεις περισσότερα προβλήματα. Σκέψου το ως μια εμπειρία, όπως η ενασχόληση σου με τη Ruby.

    Για τα ORM: τα χρησιμοποίησα τρείς φορές ως developer (και τη μια φορά ως Lead Developer/Architect) σε αρκετά εως πολύ μεγάλα projects (και πολλές περισσότερες σε μικρότερα). Τις πρώτες δυο ήταν απολύτως απαραίτητο. Τη τρίτη μάλλον όχι. Σε ό,τι αφορά τον βελτιστοποιημένο κώδικα που παράγουν τα ORM συμφωνώ. Και προσθέτω: Αλλοίμονο να μην προσέφεραν έστω αυτό. Παρα ταύτα, όσο βελτιστοποιημένος και να είναι ο κώδικας ενός ORM αυτό δε συνεπάγεται αυτομάτως βελτιστοποίηση του προγράμματος εν γένει. Μόνον η ύπαρξη ενός ORM, όπως μάλλον θα γνωρίζεις, πολλές φορές επηρεάζει τη δομή του προγράμματος με τρόπους που αλλάζουν τα χαρακτηριστικά του υποχρεώνοντας τον προγραμματιστή (ή σε μεγαλύτερα προγράμματα, αρχιτέκτονα) να ακολουθήσει πιο πολύπλοκες διαδικασίες επεξεργασίας των δεδομένων στη βάση απ'ότι θα έκανε διαφορετικά. Και όπως έγραψα, συμφωνώ, πάρα πολλές φορές αξίζει το overhead.

    Τώρα, ίσως γνωρίζεις εξαιρετικά λίγες εταιρίες με προσωπικό ικανό να χειρισθεί το 'θηρίο' επειδή --- όπως προανέφερα --- ο πιο πολύς κόσμος (ιδιαίτερα στην Ελλάδα) τείνει να αδιαφορεί για τη βάση δεδομένων ή πιστεύει πως θα 'δουλέψει' χωρίς πολλά πολλά. Τα πέντε-δέκα άτομα που γνώρισα στα πλαίσια κάποιων πρότζεκτ στην Ευρώπη ήταν απείρως πιο ενημερωμένα και ικανά από τους αρκετούς 'δήθεν' developers που έχω γνωρίσει στην Ελλάδα. Και μπορεί αυτά τα άτομα να μην κατείχαν το expertise ενός DBA, αλλά μια χαρά μπορούσαν να δομήσουν το πρόγραμμά τους σωστά ενώ ταυτόχρονα κατανοούσαν τη διαφορά μεταξύ linked-tables και foreign keys και μια χαρά επέλεγαν τα indices τους. Και αυτό είναι που μετράει στο τέλος.

    Άλλα 2 eurocents.

    ReplyDelete
  4. 1. ναι γενικότερα με κουράζουν οι ξερόλλες της αγοράς..ειναι καθαρά προσωπικη μου άποψη, δυστηχως εμμένω σε αυτη!

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

    Δεν έχω πληροφορίες ουτε για την εμπειρία σου ουτε για το πια project εχεις δουλέψει κτλ κτλ. Για μενα προσωπικά ένα ORM και το σωστό στησιμο του δεν ειναι κάτι απλό..θέλει δουλειά σκέψη..και ξανά δουλειά!

    Επίσης πράγματι δεν εχω τον άπειρο χρονο για να ειμαι expert σε Oracle και Postgres .

    Χωρίς να πολυλογώ διαφωνώ στην ευρήτερη λογικη σου.Μην υποβιβάζεις το θέμα σε απλά πράγματα κανείς δεν σου μίλησε για το πως να να φιάξεις SQL statement αλλά αυτη την στιγμή στον χώρο μου δεν ξέρω και πάρα πολλους developer οι οποίοι ξέρουν να μου πουν ποια η διαφορά του Lazy και Eager type of fetch στο Hibernate.

    Δεν κάθομαι να ασχοληθώ το πως θα κάνω detach ένα collection απο το Hibernate Session αγαπητε..το δείχνω σε εναν συναδελφο και το κάνει..loop-αρει. αλλα δεν μπορω να μην ομολογήσω ότι μου δημιουργεί πονοκέφαλο το να φιάξω σωστά και έξυπna select με πολλαπλά JOIN για να φέρνω πράγματα στην μνήμη που θα σπάνε το Lazyness των object!

    ειμαι ενας developer στο ελληνικό IT και αυτη ειναιη πραγματικότητα μου..όταν βρεθώ σε κανένα ευρενητικο της EU ..τότε θα μπορώ να σχολιάσω το επίπεδο άλλων συναδέλφων.

    ReplyDelete
  5. cosmix: αν ακόμα και μετά τον Architect ρόλο σου σε project με ORM (hibernate) πιστεύεις ότι "επηρεάζει τη δομή του προγράμματος με τρόπους που αλλάζουν τα χαρακτηριστικά του" τότε επέτρεψε μου, να υποθέσω οτι μάλλον κάτι έκανες λάθος.

    Φιλικά,
    Γιάννης

    ReplyDelete