Πέντε Κόσμοι
From The Joel on Software Translation Project
από τον Ιωήλ Σπόλσκι
Μεταφραστής ο Δημήτρης Στάικος
Δευτέρα 6 Μαΐου 2002
Υπάρχει κάτι σημαντικό το οποίο σχεδόν ποτέ δεν αναφέρεται στη βιβλιογραφία του προγραμματισμού και της ανάπτυξης λογισμικού, με αποτέλεσμα μερικές φορές να μην συννενοούμαστε σωστά.
Είσαι ένας μηχανικός λογισμικού. Και εγώ επίσης. Αλλά μπορεί να μην έχουμε τους ίδιους στόχους και απαιτήσεις. Στην πραγματικότητα υπάρχουν διαφορετικοί κόσμοι στην ανάπτυξη λογισμικού, και διαφορετικοί κανόνες ισχύουν σε αυτούς τους διαφορετικούς κόσμους.
Διαβάζεις ένα άρθρο σχετικά με μοντελοποίηση UML, και δεν λέει πουθενά ότι δεν μπορεί να εφαρμοστεί στον προγραμματισμό device drivers. Ή διαβάζεις ένα άρθρο που λέει ότι "το runtime των 20MB του .NET δεν είναι και τόσο φοβερό πράγμα", και δεν αναφέρει το προφανές: αν προσπαθείς να γράψεις κώδικα για μια EPROM των 32KB σε ένα pager, είναι όντως πολύ σημαντικό ζήτημα.
Νομίζω ότι υπάρχουν πέντε κόσμοι, μερικές φορές επικαλυπτόμενοι, μερικές φορές όχι. Αυτοί είναι:
- Πακέτα
- Λογισμικό Εσωτερικής Χρήσης
- Ενσωματωμένο Λογισμικό
- Παιχνίδια
- Μιας χρήσης
Όταν διαβάσεις το πιο πρόσφατο βιβλίο σχετικά με το Extreme Programming, ή ένα από τα εξαιρετικά βιβλία του Steve McConnell, ή το Joel on Software , ή το περιοδικό Software Development, θα δεις πολλά σχετικά με το πώς πρέπει να κάνεις την ανάπτυξη λογισμικού, αλλά σπάνια θα δεις την οποιαδήποτε αναφορά για το τι είδους ανάπτυξη μιλάνε, κάτι το οποίο είναι ατυχές, γιατί μερικές φορές χρειάζεται να κάνεις διαφορετικά τα πράγματα στους διαφορετικούς κόσμους.
Ας δούμε αυτές τις κατηγορίες συνοπτικά.
Τα Πακέτα είναι οποιοδήποτε λογισμικό το οποίο θα χρησιμοποιηθεί από έναν μεγάλο αριθμό ανθρώπων. Μπορεί να είναι όντως τυλιγμένο σε σελοφάν και να πωλείται στο CompUSA, ή μπορεί να κατεβαίνει από το Internet. Μπορεί να είναι εμπορικό ή shareware ή ανοικτού κώδικα ή GNU ή οτιδήποτε -- το βασικό σημείο είναι ότι θα εγκατασταθεί και χρησιμοποιηθεί από χιλιάδες ή και εκατομμύρια ανθρώπων.
Τα πακέτα αντιμετωπίζουν ειδικά προβλήματα τα οποία πηγάζουν από δύο ειδικές τους ιδιότητες:
- Επειδή έχουν τόσους πολλούς χρήστες οι οποίοι συχνά έχουν εναλλακτικές επιλογές, για να είναι επιτυχημένα πρέπει η γραφική διαπροσωπεία τους να είναι πιο απλή από το μέσο όρο.
- Επειδή τρέχουν σε πάρα πολλούς υπολογιστές πρέπει ο κώδικας να είναι ασυνήθιστα ανθεκτικός σε παραλλαγές ανάμεσα στα συστήματα. Την προηγούμενη εβδομάδα κάποιος μου έστειλε με email ένα bug στο προϊόν CityDesk της εταιρείας μου, το οποίο εμφανίζεται μόνο με τα Πολωνικά Windows, εξαιτίας του τρόπου με τον οποίο χειρίζονται το δεξί Alt για να εισάγουν ειδικούς χαρακτήρες. Είχαμε κάνει δοκιμές σε Win95, 95OSR2, 98, 98SE, Me, NT 4.0, Win 2000, και Win XP Home και Pro. Κάναμε δοκιμές με IE 5.01, 5.5 και 6.0 εγκατεστημένο. Κάναμε δοκιμές σε Αγγλικά, Ισπανικά, Γαλλικά, Εβραϊκά και Παραδοσιακά Κινέζικα Windows. Αλλά δεν είχαμε φτάσει στα Πολωνικά ακόμα.
Τα πακέτα έχουν τρεις βασικές παραλλαγές.
Το λογισμικό Ανοικτού Κώδικα συχνά αναπτύσσεται χωρίς κανένας να πληρώνεται γι'αυτό κι αυτό αλλάζει τη δυναμική αρκετά. Για παράδειγμα, σε μια ομάδα που αποτελείται εξ ολοκλήρου από εθελοντές τα πράγματα που δε θεωρούνται "ωραία" συχνά δε γίνονται, και όπως εύγλωττα υπέδειξε ο Matthew Thomas, αυτό επηρεάζει άμεσα την ευχρηστία. Η ανάπτυξη είναι πολύ πιο πιθανό να είναι γεωγραφικά κατανεμημένη, κάτι που έχει σαν αποτέλεσμα μια ριζικά διαφορετική ποιότητα στην επικοινωνία της ομάδας. Είναι σπάνιο στον κόσμο του ανοικτού κώδικα να έχεις μια συζήτηση πρόσωπο με πρόσωπο γύρω από έναν πίνακα ενώ ζωγραφίζεις κουτάκια και βελάκια, γι'αυτό και σε αυτά τα έργα οι σχεδιαστικές αποφάσεις που ωφελούνται από κουτάκια και βελάκια συνήθως λαμβάνονται ατυχώς. Σαν αποτέλεσμα, οι γεωγραφικά κατανεμημένες ομάδες τα έχουν πάει πολύ καλύτερα στην αντιγραφή υπάρχοντος λογισμικού, όπου απαιτείται λίγη ή καθόλου σχεδίαση.
Το Consultingware είναι μια παραλλαγή των πακέτων η οποία απαιτεί τόση πολλή παραμετροποίηση και εγκατάσταση που χρειάζεσαι ένα στρατό από συμβούλους για να το στήσεις, με εξωφρενικό κόστος. Πακέτα CRM και CMS συχνά εμπίπτουν σε αυτήν την κατηγορία. Κανείς αρχίζει να υποπτεύεται ότι το ίδιο το λογισμικό δεν κάνει τίποτα στην πραγματικότητα· αποτελεί απλά μια δικαιολογία για να έρθει ένας στρατός από συμβούλους στην πόρτα σου και να σε χρεώνουν 300$ την ώρα. Παρά το ότι το consultingware μεταμφιέζεται σαν πακέτο, το υψηλό κόστος της υλοποίησης σημαίνει ότι μοιάζει περισσότερο με λογισμικό εσωτερικής χρήσης.
Εμπορικοί δικτυακοί τόποι όπως το Salesforce.com ή το eBay πρέπει να είναι εύκολοι στη χρήση και να τρέχουν σε πολλούς browsers. Παρόλο που οι προγραμματιστές έχουν (τουλάχιστον) κάποιον έλεγχο πάνω στο περιβάλλον "λειτουργίας" - τους υπολογιστές στο υπολογιστικό κέντρο - πρέπει να αντιμετωπίσουν έναν μεγάλο αριθμό από browsers και ένα μεγάλο αριθμό χρηστών, γι'αυτό και θεωρώ αυτού του είδους το λογισμικό μια παραλλαγή των πακέτων.
Το λογισμικό εσωτερικής χρήσης πρέπει να δουλέψει υπό συγκεκριμένες συνθήκες και στους υπολογιστές μιας εταιρείας. Αυτό το κάνει πολύ πιο εύκολο να αναπτυχθεί. Μπορείς να κάνεις πολλές ασφαλείς υποθέσεις για το περιβάλλον στο οποίο θα τρέχει. Μπορείς να απαιτήσεις μια συγκεκριμένη έκδοση του Internet Explorer, ή το Microsoft Office, ή των Windows. Αν χρειαστείς ένα γράφημα, άσε το Excel να το κάνει για σένα. Όλοι στο τμήμα μας έχουν Excel. (Αλλά δοκίμασέ το αυτό με ένα πακέτο και έχεις χάσει τους μισούς από τους πιθανούς πελάτες σου).
Εδώ η ευχρηστία έχει χαμηλή προτεραιότητα, γιατί ένας περιορισμένος αριθμός ανθρώπων θα χρειαστεί να χρησιμοποιήσει το λογισμικό, και αυτοί δεν έχουν καμία επιλογή στην όλη υπόθεση. Θα πρέπει απλά να το αντιμετωπίσουν. Η ταχύτητα ανάπτυξης είναι πιο σημαντική. Επειδή το κόστος της προσπάθειας ανάπτυξης διαμοιράζεται μόνο σε μια εταιρεία, το πλήθος προγραμματιστικών πόρων που μπορούν να δικαιολογηθούν είναι σημαντικά χαμηλότερο. Η Microsoft αντέχει να ξοδέψει 500.000.000$ για να αναπτύξει ένα λειτουργικό σύστημα που θα κοστίσει 80$ στο μέσο χρήστη. Αλλά όταν η Detroit Edison αναπτύσσει μια πλατφόρμα συνναλλαγών ενέργειας, αυτή η επένδυση πρέπει να έχει νόημα για μια εταιρεία. Για να επιτύχεις μια λογική απόδοση της επένδυσής σου, δεν μπορείς να ξοδέψεις όσα θα ξόδευες σε ένα πακέτο. Γι'αυτό είναι λυπηρό, αλλά η πλειοψηφία του λογισμικού εσωτερικής χρήσης έχει μαύρο χάλι.
Το Ενσωματωμένο Λογισμικό έχει τη μοναδική ιδιότητα ότι μπαίνει μέσα σε ένα κομμάτι υλικού και σχεδόν σε καμία περίπτωση δεν μπορεί να ενημερωθεί. Αυτός εδώ είναι ένας τελείως διαφορετικός κόσμος. Οι ποιοτικές απαιτήσεις είναι πολύ υψηλές, γιατί δεν υπάρχει δεύτερη ευκαιρία. Μπορεί να έχεις να κάνεις με έναν επεξεργαστή που τρέχει δραματικά πιο αργά από τον τυπικό επεξεργαστή ενός επιτραπέζιου συστήματος, γι'αυτό οι προγραμματιστές πρέπει να περάσουν πολύ χρόνο βελτιστοποιώντας και ρυθμίζοντας τον κώδικα. Ο γρήγορος κώδικας είναι πιο σημαντικός από τον όμορφο κώδικα. Οι συσκευές εισόδου και εξόδου που είναι διαθέσιμες μπορεί να είναι πολύ περιορισμένες. Το σύστημα GPS στο αυτοκίνητο που νοίκιασα την προηγούμενη εβδομάδα είχε τόσο απαράδεκτο σύστημα Ε/Ε που η ευχρησία ήταν τραγική. Έχετε δοκιμάσει ποτέ να εισάγετε μια διεύθυνση σε μια συσκευή που δεν έχει πληκτρολόγιο; Εμφάνιζαν ένα "πληκτρολόγιο" στην οθόνη και έπρεπε να χρησιμοποιήσεις τα βελάκια κατεύθυνσης για να επιλέξεις γράμματα από πέντε μικρούς πίνακες των 9 γραμμάτων ο καθένας. (Ακολουθήστε το σύνδεσμο για περισσότερες φωτογραφίες αυτού του UI. Το GPS στο δικό μου αμάξι έχει μια οθόνη αφής που κάνει τη διαπροσωπεία δραματικά καλύτερη. Αλλά παρασύρομαι).
Τα παιχνίδια είναι μοναδικά για δύο λόγους. Πρώτα απ'όλα τα οικονομικά των παιχνιδιών είναι πολύ περισσότερο προσανατολισμένα στα "hits". Μερικά παιχνίδια είναι "hits", πολύ περισσότερα παιχνίδια είναι αποτυχίες, και αν θέλεις να κάνεις λεφτά στα παιχνίδια, αναγνωρίζεις αυτό το γεγονός και φροντίζεις να έχεις ένα χαρτοφυλάκιο με παιχνίδια, ώστε το hit που θα σπάσει τα ταμεία να καλύψει τη χασούρα από όλες τις αποτυχίες. Αυτό μοιάζει περισσότερο με τις ταινίες παρά με το λογισμικό.
Το μεγαλύτερο ζήτημα με την ανάπτυξη παιχνιδιών είναι ότι υπάρχει μόνο μια έκδοση. Όταν κάποιος έχει παίξει το Duke Nukem 3D μέχρι το τέλος, δεν πρόκειται να αναβαθμίσει στο Duke Nukem 3.1D μόνο και μόνο για να πάρει μερικές διορθώσεις και νέα όπλα. Με μερικές εξαιρέσεις όταν κάποιος έχει παίξει ένα παιχνίδι μέχρι το τέλος, βρίσκει βαρετό το να το παίξει ξανά. Γι'αυτό τα παιχνίδια έχουν τις ίδιες απαιτήσεις ποιότητας με το ενσωματωμένο λογισμικό και ένα απίστευτο οικονομικό κίνητρο να το κάνουν σωστά, με την πρώτη. Αντιθέτως, οι προγραμματιστές πακέτων έχουν την πολυτέλεια να ξέρουν ότι αν η έκδοση 1.0 δεν ικανοποιεί τις ανάγκες του κόσμου και δεν πουλάει, μπορούν να κάνουν τη 2.0 καλύτερη και ο κόσμος μπορεί να την αγοράσει.
Ο κώδικας Μιας Χρήσης είναι κώδικας τον οποίο δημιουργείς μόνο και μόνο με το σκοπό να πετύχεις κάτι άλλο, και δεν πρόκειται να τον χρησιμοποιήσεις ξανά μόλις πετύχεις αυτό το άλλο. Για παράδειγμα, μπορεί να γράψεις ένα μικρό shell script το οποίο επεξεργάζεται ένα αρχείο εισόδου που έχεις, και το μετατρέπει στη μορφή που θέλεις για κάποιο άλλο λόγο, και αυτό είναι μια λειτουργία που θα γίνει άπαξ.
Πιθανότατα υπάρχουν και άλλοι κόσμοι ανάπτυξης λογισμικού τους οποίους ξεχνάω.
Να ένα σημαντικό πράγμα που πρέπει να ξέρετε. Κάθε φορά που διαβάζετε ένα από αυτά τα βιβλία για προγραμματιστικές μεθοδολογίες, γραμμένο από έναν πλήρους απασχόλησης γκουρού/σύμβουλο ανάπτυξης λογισμικού, το πιθανότερο είναι ότι θα μιλάει για ανάπτυξη λογισμικού εσωτερικής χρήσης σε μεγάλες εταιρείες. Όχι για πακέτα, όχι για ενσωματωμένο λογισμικό, και βέβαια όχι για παιχνίδια. Γιατί; Μα επειδή οι μεγάλες εταιρείες είναι αυτές που προσλαμβάνουν αυτούς τους γκουρού. Αυτοί πληρώνουν το λογαριασμό. (Πιστέψτε με, η id Software δεν πρόκειται να προσλάβει τον Ed Yourdon να μιλήσει για δομημένη ανάλυση).
Την προηγούμενη εβδομάδα ο Kent Beck ισχυρίστηκε ότι στην πράξη δεν χρειάζεσαι μια βάση παρακολούθησης σφαλμάτων όταν ακολουθείς το Extreme Programming, γιατί ο συνδιασμός προγραμματισμού σε ζευγάρια (με συνεχείς επανεξετάσεις του κώδικα) και της ανάπτυξης οδηγούμενης από περιπτώσεις ελέγχου (με εξασφαλισμένη 100% κάλυψη των αυτοματοποιημένων περιπτώσεων ελέγχου) συνεπάγεται ότι σχεδόν ποτέ δεν έχεις σφάλματα. Αυτό δεν μου ακούστηκε και πολύ σωστό. Έριξα μια ματιά στη δική μας βάση παρακολούθησης σφαλμάτων εδώ στη Fog Creek για να δω τι είδη σφαλμάτων την απασχολούσαν.
Ανακάλυψα ότι πολύ λίγα από τα σφάλματα εκεί μέσα θα είχαν ανακαλυφθεί με προγραμματισμό σε ζευγάρια ή με ανάπτυξη οδηγούμενη από περιπτώσεις ελέγχου. Πολλά από τα "σφάλματά" μας είναι βασικά αυτό που το XP ονομάζει ιστορίες -- στην πραγματικότητα τίποτα άλλο από λειτουργικές δυνατότητες. Χρησιμοποιούμε τη βάση παρακολούθησης σφαλμάτων σαν έναν τρόπο να θυμόμαστε, να θέτουμε προτεραιότητες και να διαχειριζόμαστε όλες τις μικροβελτιώσεις αλλά και τις σημαντικές λειτουργικές δυνατότητες που θέλουμε να υλοποιήσουμε.
Πολλά από τα σφάλματα ανακαλύφθηκαν μόνο μετά από εκτενή χρήση από τους χρήστες. Για παράδειγμα το ζήτημα με το Πολωνικό πληκτρολόγιο. Δεν υπάρχει περίπτωση να το έβρισκε αυτό ο προγραμματισμός σε ζευγάρια. Όπως επίσης και τα λογικά σφάλματα τα οποία ποτέ δεν σκεφτήκαμε στον τρόπο με τον οποίο διαφορετικές δυνατότητες συνδιάζονται μαζί. Όσο πιο μεγάλο και πολύπλοκο είναι ένα πρόγραμμα, τότε πιο πολλές οι αλληλεπιδράσεις μεταξύ των δυνατοτήτων του τις οποίες δεν θα έχετε σκεφτεί. Ένας ιδιαίτερα σπάνιος συνδιασμός χαρακτήρων ({${?, αν θέλετε να ξέρετε) ο οποίος μπερδεύει τον λεκτικό αναλυτή. Μερικοί εξυπηρετητές ftp παράγουν σφάλμα αν προσπαθήσεις να διαγράψεις ένα αρχείο το οποίο δεν υπάρχει (ο δικός μας εξυπηρετητής ftp δεν παραπονιόταν και γι'αυτό δεν το είχαμε σκεφτεί ποτέ).
Μελέτησα προσεκτικά κάθε σφάλμα. Από τα 106 σφάλματα που διορθώσαμε για την διορθωτική έκδοση του CityDesk, ακριβώς 5 από αυτά θα μπορούσαν να είχαν αποφευχθεί με τη χρήση προγραμματισμού σε ζευγάρια ή σχεδίασης οδηγούμενης από τις περιπτώσεις ελέγχου. Είχαμε περισσότερα σφάλματα από αυτά που ξέραμε και νομίζαμε σημαντικά (μόνο και μόνο για να μας διορθώσουν οι πελάτες μας!) σε σχέση με τα σφάλματα τα οποία θα είχαν πιάσει οι μέθοδοι XP.
Αλλά ο Kent έχει δίκιο, για άλλους τύπους ανάπτυξης. Για τις περισσότερες εφαρμογές εσωτερικής χρήσης, κανένα από τα παραπάνω πράγματα δεν θα θεωρείτο σφάλμα. Το πρόγραμμα κρασάρει όταν η είσοδος είναι μη έγκυρη; Τρέχτο ξανά, και αυτή τη φορά πρόσεξε τα {${? ! Και έχουμε μόνο 'Ενα Είδος εξυπηρετητή FTP και κανείς στην εταιρεία μας δεν χρησιμοποιεί Πολωνικά Windows.
Τα περισσότερα πράγματα στην ανάπτυξη λογισμικού είναι τα ίδια, ανεξάρτητα από τον τύπο του έργου στο οποίο δουλεύεις, αλλά όχι όλα. Όταν κάποιος σου μιλά για μεθοδολογία, σκέψου πώς αυτή μπορεί να εφαρμοστεί στη δουλειά που κάνεις εσύ. Αναλογίσου από που προέρχεται αυτός που σου μιλάει. Ο Steve McConnell, ο Steve Maguire, και εγώ ερχόμαστε από μια πολύ μικρή γωνιά: τον κόσμο των πακετοποιημένων φύλλων εργασίας τα οποία γράφονται στο Redmond της Washington. Έτσι έχουμε υψηλότερες απαιτήσεις από την ευκολία χρήσης και χαμηλότερες απαιτήσεις από το πλήθος των σφαλμάτων. Οι περισσότεροι από τους υπόλοιπους ειδικούς των μεθοδολογιών βγάζουν το ψωμί τους παρέχοντας συμβουλευτικές υπηρεσίες στην ανάπτυξη εσωτερικού λογισμικού, και γι'αυτό το πράγμα μιλάνε. Σε κάθε περίπτωση, μπορούμε να μάθουμε ο ένας από τον άλλον.
Το άρθρο αυτό πρώτο-εμφανίστηκε στα Αγγλικά με το όνομα Five Worlds
