Joel on Software

Joel on Software   Ο Ιωήλ περί Λογισμικού

 

Άλλα "Joel on Software" άρθρα στα Ελληνικά

Άλλα "Joel on Software" άρθρα στα Αγγλικά

Στείλτε μήνυμα ηλεκτρονικού ταχυδρομείου στο συγγραφέα (μόνο στα Αγγλικά)

 

Το Τεστ του Ιωήλ: 12 Βήματα για Καλύτερο Κώδικα


από τον Ιωήλ Σπολσκι
Μεταφραστής ο Αμοιρίδης Πέτρος
9 Αυγούστου 2000

Έχεις ακούσει ποτέ για το SEMA; Είναι ένα σύστημα για να μετράει κανείς πόσο καλή είναι μια ομάδα ανάπτυξης λογισμικού. Όχι, περίμενε! Μην ακολουθήσεις την παραπάνω σύνδεση! Θα σου πάρει περίπου έξι χρόνια μόνο για να καταλάβεις το υλικό. Γι'αυτό δημιούργησα το δικό μου, αρκούντως ανεύθυνο και τσαπατσούλικο τεστ για την αξιολόγηση της ποιότητας μιας ομάδας ανάπτυξης λογισμικού. Το καλύτερο σε αυτό το τεστ είναι ότι κρατάει περίπου 3 λεπτά. Στον υπόλοιπο χρόνο που κερδίζεις, μπορείς να σπουδάσεις ιατρική.

Το Τεστ του Ιωήλ

  1. Χρησιμοποιείς κάποια μέθοδο διαχείρισης πηγαίου κώδικα;
  2. Μπορείς να δημιουργήσεις παραδοτέο της εφαρμογής σου σε ένα βήμα;
  3. Δημιουργείς παραδοτέα σε καθημερινή βάση;
  4. Διατηρείς βάση δεδομένων σφαλμάτων;
  5. Διορθώνεις τα σφάλματα πριν να γράψεις νέο κώδικα;
  6. Έχεις ενημερωμένο χρονοδιάγραμμα;
  7. Έχεις προδιαγραφές;
  8. Έχουν οι προγραμματιστές αθόρυβες συνθήκες εργασίας;
  9. Έχεις τα καλύτερα εργαλεία ανάπτυξης λογισμικού που μπορείς να αγοράσεις;
  10. Έχεις ελεγκτές;
  11. Οι υποψήφιοι για πρόσληψη γράφουν κώδικα κατά τη διάρκεια της συνέντευξής τους;
  12. Κάνεις έλεγχο ευκολίας χρήσης των εφαρμογών στο διάδρομο;


Το ωραίο με το Τεστ του Ιωήλ είναι ότι μπορείς να πάρεις εύκολα σαν απάντηση ένα γρήγορο ναι ή όχι σε κάθε ερώτηση. Δε χρειάζεται να σκεφτείς γραμμές-κώδικα-την-ημέρα ή μέσο-αριθμό-σφαλμάτων-ανά-σημείο-αλλαγής. Δώσε στην ομάδα σου 1 βαθμό για κάθε "ναί". Το πρόβλημα με το Τεστ του Ιωήλ είναι ότι δεν πρέπει στα αλήθεια να το χρησιμοποιήσεις για να βεβαιωθείς ότι το λογισμικό ελέγχου του πυρηνικού εργοστασίου σου είναι ασφαλές.

Οι 12 βαθμοί είναι τέλειοι, οι 11 είναι υποφερτοί, αλλά με 10 ή λιγότερους βαθμούς έχεις σοβαρό πρόβλημα. Η αλήθεια είναι ότι οι περισσότερες εταιρείες παραγωγής λογισμικού λειτουργούν με βαθμολογία 2 ή 3 βαθμών και χρειάζονται οπωσδήποτε βοήθεια, διότι εταιρείες όπως η Microsoft λειτουργούν συνέχεια με την βαθμολογία των 12 βαθμών. 
Φυσικά, αυτοί δεν ειναι οι μόνοι παράγοντες που καθορίζουν την επιτυχία ή την αποτυχία: ειδικότερα, αν έχεις μια υπέροχη ομάδα ανάπτυξης λογισμικού η οποία δουλεύει σε ένα προϊόν που δε θέλει κανένας, βασικά... κανένας δε θα το θέλει. Είναι πιθανό να φανταστείς μια ομάδα "πιστολάδων" που δεν κάνει τίποτα από όλα τα παραπάνω αλλά καταφέρνει και παράγει φανταστικό λογισμικό που αλλάζει τον κόσμο. Πάντως, ανεξαρτήτως, αν εκτελέσεις αυτά τα 12 σημεία σωστά, θα έχεις μια πειθαρχημένη ομάδα που μπορεί να ανταπεξέλθει με συνέπεια σε όλες τις απαιτήσεις.
1. Χρησιμοποιείς κάποια μέθοδο διαχείρισης πηγαίου κώδικα;
Έχω χρησιμοποιήσει εμπορικά πακέτα διαχείρισης πηγαίου κώδικα και έχω χρησιμοποιήσει το CVS, το οποίο είναι δωρεάν, και επίτρεψέ μου να σου πω ότι το CVS είναι μια χαρά. Αν, όμως, δε χρησιμοποιείς κάποια εφαρμογή διαχείρισης πηγαίου κώδικα, θα ζοριστείς προσπαθώντας να καταφέρεις τους προγραμματιστές να συνεργαστούν. Οι προγραμματιστές δε θα έχουν τρόπο να μάθουν τι έκαναν οι υπόλοιποι. Τα σφάλματα δε θα μπορούν εύκολα να επιδιορθωθούν. Το καλό με τα συστήματα διαχείρισης πηγαίου κώδικα είναι ότι ο πηγαίος κώδικας δουλεύεται τοπικά στο σκληρό δίσκο του κάθε προγραμματιστή -- δεν έχω ακούσει κάποιο έργο μέχρι τώρα στο οποίο να χρησιμοποιούνταν σύστημα διαχείρισης πηγαίου κώδικα αλλά πάραυτα να έχει χαθεί σημαντικό ποσοστό αυτού κώδικα.
2. Μπορείς να δημιουργήσεις παραδοτέο της εφαμοργής σου σε ένα βήμα;
Μ'αυτό εννοώ: πόσα βήματα σου παίρνει για να φτιάξεις ένα παραδοτέο της εφαρμογής από το πιο πρόσφατο αντίγραφο του πηγαίου κώδικά της; Στις καλές ομάδες, υπάρχει ένα μοναδικό αρχείο με εντολές το οποίο μπορεί να εκτελεστεί και να πάρει όλα τα αρχεία πηγαίου κώδικα της εφαρμογής, να μεταγλωτίσει κάθε γραμμή κώδικα, να δημιουργήσει τα εκτελέσιμα αρχεία - σε όλες τις εκδόσεις τους, γλώσσες και συνδυασμούς #ifdef- να δημιουργήσει το πακέτο εγκατάστασης και να δημιουργήσει το τελικό μέσο διανομής -- CDROM, διαδικτυακή τοποθεσία λήψης της εφαρμογής, κλπ.
Αν για την ολοκλήρωση της διαδικασίας χρειάζονται περισσότερα βήματα, αυξάνονται οι πιθανότητες για περισσότερα λάθη. Όταν πλησιάζει η ημερομηνία έκδοσης, θέλεις να έχεις ένα γρήγορο κύκλο επιδιόρθωσης του "τελευταίου" σφάλματος, δημιουργίας των τελικών εκτελέσιμων, κλπ. Αν παίρνει 20 βήματα να μεταγλωτίσεις των κώδικα, να τρέξεις την εφαρμογή δημιουργίας εγκατάστασης, κλπ., θα τρελαθείς στο τέλος και θα κάνεις ηλίθια λάθη.
Γι'αυτόν ακριβώς το λόγο, η τελευταία εταιρεία στην οποίο δούλευα άλλαξε από WISE σε InstallShield: θέλαμε η διαδικασία δημιουργίας πακέτου εγκατάστασης να μπορεί να εκτελεστεί, από ένα αρχείο εντολών, αυτόματα, κατά τη διάρκεια της νύχτας, χρησιμοποιώντας τον NT scheduler, αλλά το WISE δε μπορούσε να τρέξει από τον NT scheduler κατά τη διάρκεια της νύχτας και τελικά το πετάξαμε. (Οι ευγενικοί άνθρωποι της WISE με διαβεβαιώνουν ότι η τελευταία έκδοση υποστηρίζει νυχτερινές δημιουργίες πακέτων εγκατάστασης.)
3. Δημιουργείς παραδοτέα σε καθημερινή βάση;
Όταν χρησιμοποιείς εργαλείο διαχείρισης πηγαίου κώδικα, μερικές φορές ένας προγραμματιστής καταλάθος αλλάζει κάτι που σαν αποτέλεσμα έχει τη μη ολοκλήρωση της δημιουργίας του παραδοτέου. Για παράδειγμα, ο προγραμματιστής πρόσθεσε ένα νέο αρχείο πηγαίου κώδικα και όλα μεταγλωτίζονται μια χαρά στον υπολογιστή του, αλλά ξέχασε να προσθέσει το αρχείο και στον κεντρικό υπολογιστή όπου το εργαλείο διαχείρισης πηγαίου κώδικα διατηρεί την αποθήκη πηγαίου κώδικα. Έτσι, κλειδώνει τον υπολογιστή του και πηγαίνει σπίτι του, ανυποψίαστος και χαρούμενος. Όμως, κανένας άλλος δε μπορεί να δουλέψει, έτσι πρέπει και αυτοί να πάνε στο σπίτι τους, δυστυχισμένοι.
Η μη ολοκλήρωση δημιουργίας του παραδοτέου είναι κάτι τόσο άσχημο (μα τόσο συνηθισμένο), που είναι καλό να γίνεται καθημερινή δημιουργία των παραδοτέων, ώστε να διασφαλίζεται πως κανένα πρόβλημα δε θα περάσει απαρατήρητο. Σε μεγάλες ομάδες, ένας καλός τρόπος να διασφαλιστεί η άμεση επιδιόρθωση των προβλημάτων κατά τη δημιουργια των παραδοτέων είναι αυτή να εκτελείται κάθε μεσημέρι κατά τη διάρκεια, ας πούμε, του μεσημεριανού γεύματος. Όλοι προσπαθούν να τοποθετήσουν τις τελευταίες αλλαγές τους στο εργαλείο διαχείρισης πηγαίου κώδικα πριν το φαγητό. Όταν επιστρέφουν, η δημιουργία του παραδοτέου έχει τελειώσει. Αν δούλεψε, θαυμάσια! Όλοι λαμβάνουν την τελευταία έκδοση του πηγαίου κώδικα και συνεχίζουν τη δουλειά. Αν η δημιουργία του παραδοτέου απέτυχε, το διορθώνεις, αλλά όλοι μπορούν να συνεχίσουν να δουλεύουν με την προηγούμενη σωστή έκδοση του πηγαίου κώδικα.
Στην ομάδα του Excel είχαμε έναν κανόνα: όποιος έκανε τη διαδικασία δημιουργίας του παραδοτέου να σταματήσει με προβλήματα, ως "τιμωρία", ήταν υπεύθυνος να ελέγχει τη διαδικασία μέχρι να τη χαλάσει κάποιος άλλος. Αυτό ήταν ένα καλό κίνητρο για να μη προκαλείς τη διακοπή της δημιουργίας του παραδοτέου και ένας καλός τρόπος για να εναλλάσσονται όλοι γύρω από τη διαδικασία δημιουργίας του παραδοτέου μέχρι να μάθουν όλοι πως λειτουργεί. 
Διάβασε περισσότερα σχετικά με την καθημερινή δημιουργία παραδοτέων στο άρθρο μου Οι Καθημερινές Δημιουργίες Παραδοτέων είναι ο Φίλος σου.
4. Διατηρείς βάση δεδομένων σφαλμάτων;
Δε με νοιάζει τι λες. Αν αναπτύσσεις κώδικα, ακόμα και σε ομάδα του ενός ατόμου, δίχως να έχεις μια οργανωμένη βάση δεδομένων με όλα τα γνωστά σφάλματα του κώδικα, θα εκδόσεις κώδικα χαμηλής ποιότητας. Πολλοί προγραμματιστές πιστεύουν ότι μπορούν να κρατήσουν τη λίστα με τα σφάλματα στο μυαλό τους. Ανοησίες. Εγώ δε μπορώ να θυμάμαι δύο ή τρια σφάλματα τη φορά και το επόμενο πρωί, στη βιασύνη της έκδοσης, ξεχνιούνται και αυτά. Πρέπει οπωσδήποτε να παρακολουθείτε μεθοδικά τα σφάλματα.
Οι βάσεις δεδομένων σφαλμάτων μπορεί να είναι πολύπλοκες ή απλές. Για να είναι χρήσιμη, μια βάση δεδομένων σφαλμάτων πρέπει να περιέχει τα παρακάτω στοιχεία για κάθε σφάλμα:
  • όλα τα βήματα για την αναπαραγωγή του σφάλματος
  • αναμενόμενη συμπεριφορά
  • παρατηρούμενη (εσφαλμένη) συμπεριφορά
  • σε ποιον έχει ανατεθεί
  • αν έχει επιδιορθωθεί ή όχι

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

Για περισσότερα σχετικά με την παρακολούθηση σφαλμάτων, διάβασε Ανώδυνη Παρακολούθηση Σφαλμάτων.

5. Διορθώνεις τα σφάλματα πριν να γράψεις νέο κώδικα;
Η πρώτη έκδοση του Microsoft Word για Windows θεωρήθηκε έργο τύπου "death march". Πήρε αιώνες για να ολοκληρωθεί. Συνεχώς απέκλινε από το πρόγραμμα. Όλη η ομάδα δούλευε απαράδεκτες ώρες, το έργο καθυστερούσε ξανά, και ξανά, και ξανά και το άγχος ήταν απίστευτο. Όταν χρόνια αργότερα το αναθεματισμένο τελικά βγήκε στην αγορά, η Microsoft έστειλε όλη την ομάδα για διακοπές στο Κανκούν και έπειτα εξέτασε προσεκτικά τι πήγε στραβά με στόχο την αναθεώρηση των εσωτερικών της πρακτικών.

Αυτό που αντιλήφθηκαν ήταν ότι οι διευθυντές έργων επέμεναν τόσο πολύ στην τήρηση του "χρονοδιαγράμματος", που οι προγραμματιστές απλά εκτελούσαν τη διαδικασία της υλοποίησης βιαστικά, γράφοντας εξαιρετικά άσχημο κώδικα, διότι η φάση επιδιόρθωσης σφαλμάτων δεν ήταν μέρος του επίσημου χρονοδιαγράμματος. Δε γινόταν καμία προσπάθεια να κρατηθεί χαμηλός ο αριθμός των σφαλμάτων. Εντελώς το αντίθετο. Υπάρχει μια ιστορία για έναν προγραμματιστή, που έπρεπε να γράψει τον κώδικα που να υπολογίζει το ύψος μιας γραμμής κειμένου και αυτός έγραψε απλά "return 12;" και περίμενε την αναφορά σφάλματος να έρθει που να λέει πως η ρουτίνα του δεν ήταν πάντα σωστή. Το χρονοδιάγραμμα ήταν απλά ένας κατάλογος από χαρακτηριστικά που περίμεναν να μετατραπούν σε σφάλματα. Στη νεκροψία, αναφερόντουσαν στην παραπάνω κατάσταση ως "η μεθοδολογία με τα άπειρα ελαττώματα".

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

Γενικότερα, όσο περισσότερο περιμένεις πριν διορθώσεις ένα σφάλμα, τόσο αυξάνεται το κόστος (σε χρόνο και χρήμα) της επιδιόρθωσής του.

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

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

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

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

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

Αυτός είναι ένας λόγος να επιδιορθώνεις τα σφάλματα τάχιστα: διότι παίρνει λιγότερο χρόνο. Υπάρχει και άλλος λόγος ο οποίος σχετίζεται με το γεγονός ότι είναι ευκολότερο να προβλέπεις πόσο θα πάρει για να γραφτεί νέος κώδικας από ότι για να επιδιορθωθεί ένα υπάρχον σφάλμα. Για παράδειγμα, αν σου ζητούσα να προβλέψεις πόσο καιρό θα έπαιρνε για να γραφτεί ο κώδικας που ταξινομεί ένα κατάλογο, θα μου έδινες μια αρκετά καλή εκτίμηση. Αλλά αν σου ζητούσα να προβλέψεις πόσο θα έπαιρνε η επιδιόρθωση εκείνου του σφάλματος όπου ο κώδικάς σου δε λειτουργεί αν ο Internet Explorer 5.5 είναι εγκατεστημένος, δε θα μπορούσες ούτε να μαντέψεις, διότι δε θα ήξερες (εξ'ορισμού) από τι προκαλείται το σφάλμα. Θα μπορούσε να πάρει 3 μέρες για να αποκαλυφθεί ή θα μπορούσε να πάρει 2 λεπτά.

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

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

6. Έχεις ενημερωμένο χρονοδιάγραμμα;
Το οποίο μας φέρνει στα χρονοδιαγράμματα. Αν ο κώδικάς σου είναι σημαντικός για την επιχείριση, υπάρχουν πολλοί λόγοι για τους οποίους είναι σημαντικό για την επιχείριση να γνωρίζει πότε θα είναι έτοιμος ο κώδικας. Οι προγραμματιστές είναι υπερβολικά δύστροποι όταν τους ζητούν να δημιουργήσουν χρονοδιαγράμματα. "Θα είναι έτοιμο όταν θα είναι έτοιμο!" ουρλιάζουν στους επιχειρηματίες.

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

Ένας άλλος σημαντικός λόγος να κρατάς ένα χρονοδιάγραμμα, είναι ότι σου επιβάλλει να αποφασίσεις ποια χαρακτηριστικά θα υλοποιήσεις και στη συνέχεια σου επιβάλλει να επιλέξεις τα πιο ασήμαντα και να τα κόψεις αντί να διολισθήσεις προς την ασθένεια των υπερβολικών νέων χαρακτηριστικών (featuritis) (γνωστή και ως scope creep (το φαινόμενο να αλλάζουν συνέχεια οι απαιτήσεις προσθέτοντας περισσότερη δουλειά δίχως να αλλάζει το χρονοδιάγραμμα)).

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

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

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

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

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

Μάθε τα πάντα σχετικά με τη συγγραφή προδιαγραφών διαβάζοντας τη σειρά τεσσαρών άρθρων.

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

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

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

Η άλλη δυσκολία είναι ότι πως μπορείς πολύ εύκολα να πεταχτείς εκτός ζώνης. Θόρυβος, τηλέφωνα, έξοδοι για μεσημεριανό, ξοδεύοντας μισή ώρα στα Goody's της γειτονιάς για να πάρεις ένα καφέ "στο πακέτο" και διακοπές από τους συναδέλφους -- ειδικά οι διακοπές από συναδέλφους -- όλα αυτά σε πετάνε εκτός ζώνης. Αν ένας συνάδελφος σε ρωτήσει κάτι, προκαλώντας διακοπή ενός λεπτού, αλλά αυτό σε πετάξει από τη ζώνη τόσο άσχημα που σου παίρνει μισή ώρα να ξαναγίνεις παραγωγικός, τότε η συνολική παραγωγικότητά σου είναι προβληματική. Αν βρίσκεσαι σε ένα θορυβώδες περιβάλλον μεγάλο σε έκταση όπως συνηθίζουν να δημιουργούν οι νέες εταιρείες τεχνολογίας (dotcoms) με την καφεΐνη να ξεχειλίζει από τα αυτιά των εργαζόμενων, με τους τύπους του μαρκετινγκ να κραυγάζουν στο τηλέφωνο δίπλα στους προγραμματιστές, η παραγωγικότητά σου πιάνει πάτο καθώς οι εργαζόμενοι διακόπτονται συνέχεια μη μπορώντας να μπουν στη ζώνη ποτέ.

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

Εδώ λοιπόν είναι η απλή άλγεβρα. Ας πούμε (όπως φαίνεται από τις αποδείξεις) ότι αν διακόψουμε έναν προγραμματιστή, ακόμα και για ένα λεπτό, καταστρέφουμε στην ουσία 15 λεπτά παραγωγικής εργασίας. Για αυτό το παράδειγμα ας πάρουμε δύο προγραμματιστές, τον Τζεφ και τον Ματ, σε δύο σταθμούς εργασίας (ξέρετε... αυτά τα κουβούκλια 1 επί 1 με ανοιχτή οροφή που είναι αραδιασμένα σε ένα τεράστιο όροφο δίχως τοίχους) δίπλα - δίπλα. Ο Ματ δε μπορεί να θυμηθεί το όνομα της συνάρτησης strcpy στην έκδοσή της για Unicode. Θα μπορούσε να το ψάξει, που χρειάζεται 30 δευτερόλεπτα ή να ρωτήσει τον Τζεφ, που χρειάζεται 15 δευτερόλεπτα. Μια και κάθεται δίπλα στον Τζεφ, τον ρωτάει. Αποσπάται η προσοχή του Τζεφ και χάνει 15 λεπτά παραγωγικής εργασίας (για να γλιτώσει από τον Ματ 15 δευτερόλεπτα).

Ας τους μεταφέρουμε τώρα σε ξεχωριστά γραφεία με τοίχους και πόρτες. Τώρα όποτε ο Ματ δε μπορεί να θυμηθεί το όνομα εκείνης της συνάρτησης, θα μπορούσε να το ψάξει, κάτι που εξακολουθεί να χρειάζεται 30 δευτερόλεπτα ή θα μπορούσε να ρωτήσει τον Τζεφ, κάτι που χρειάζεται 45 δευτερόλεπτα πλέον και προϋποθέτει να σηκωθείς από την καρέκλα σου (όχι κάτι εύκολο αν αναφερθούμε στη μέση φυσική κατάσταση ενός προγραμματιστή!). Οπότε, το ψάχνει. Άρα τώρα ο Ματ χάνει 30 δευτερόλεπτα παραγωγικής εργασίας, αλλά γλιτώνει 15 λεπτά από τον Τζεφ. Αααα! (χειροκροτήματα)

9. Έχεις τα καλύτερα εργαλεία ανάπτυξης λογισμικού που μπορείς να αγοράσεις;
Η συγγραφή κώδικα σε γλώσσα προγραμματισμού που χρειάζεται μετάφραση σε κώδικα μηχανής και παραγωγή εκτελέσιμου αρχείου είναι από τα τελευταία πράγματα που δε μπορούν να γίνουν τάχιστα στον υπολογιστή του ψιλικατζή της γειτονιάς σου. Αν η διαδικασία της μετάφρασης διαρκεί περισσότερο από μερικά δευτερόλεπτα, αγοράζοντας τον τελευταίο και καλύτερο υπολογιστή σου γλιτώνει χρόνο. Αν η διαδικασία διαρκεί έστω και 15 δευτερόλεπτα, οι προγραμματιστές βαριούνται όσο περιμένουν να εκτελεστεί ο μεταφραστής και αρχίσουν να διαβάζουν The Onion, που τους απορροφά και χάνονται ώρες παραγωγικής εργασίας.

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

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

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

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

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

10. Έχεις ελεγκτές;
Αν η ομάδα σου δεν έχει αποκλειστικούς ελεγκτές, τουλάχιστο έναν για κάθε δύο ή τρεις προγραμματιστές, τότε είτε πουλάς προβληματικά προϊόντα ή σπαταλάς χρήματα βάζοντας προγραμματιστές των 100� την ώρα να κάνουν την ίδια εργασία που μπορεί να γίνει από ελεγκτές των 30� την ώρα. Το να τσιγκουνεύεται κάποιος μη χρησιμοποιώντας ελεγκτές είναι μια τόσο εξοργιστικά λανθασμένη οικονομική πολιτική που απλά πέφτω από τα σύννεφα όταν πολλοί άνθρωποι δεν το αναγνωρίζουν.

Διάβασε Οι Πέντε Πρώτοι (Λάθος) Λόγοι που Δεν Εχεις Ελεγκτές, ένα άρθρο που έγραψα για αυτό το θέμα.

11. Οι υποψήφιοι για πρόσληψη γράφουν κώδικα κατά τη διάρκεια της συνέντευξής τους;
Θα προσλάμβανες έναν μάγο δίχως να του ζητήσεις να σου δείξει μερικά μαγικά κόλπα; Όχι, φυσικά!

Θα έκλεινες μια υπηρεσία διογράνωσης δεξιώσεων για τον γάμο σου δίχως να δοκιμάσεις το φαγητό τους; Αμφιβάλλω. (Εκτός και αν ήταν η θεία Βαρβάβα, η οποία θα σε μισούσε για πάντα αν δεν την άφηνες να ετοιμάσει τα "διάσημα" κεφτεδάκια της).

Κι όμως, κάθε μέρα, προσλαμβάνονται προγραμματιστές σε συνεντεύξης διότι είτε είχαν εντυπωσιακό βιογραφικό ή το άτομο που έπαιρνε τη συνέντευξη απόλαυσε τη συζήτηση μαζί τους. Ή τους ρωτάνε ασήμαντες ερωτήσεις ("ποια η διαφορά ανάμεσα στην CreateDialog() και DialogBox();") που θα μπορούσαν να απαντηθούν κοιτάζοντας την "Βοήθεια". Δε σε ενδιαφέρει αν έχουν αποστηθίσει χιλιάδες ασήμαντες γνώσεις για τον προγραμματισμό, σε ενδιαφέρει αν μπορούν να παράγουν κώδικα. Ή ακόμα χειρότερα, τους ρωτάνε ερωτήσεις πασιφανείς: Ερωτήσεις που φαίνεται εύκολο να απαντηθούν αν γνωρίζεις την απάντηση, αλλά αν δεν τη γνωρίζεις είναι αδύνατο να απαντηθούν.

Σας παρακαλώ, σταματήστε να το κάνετε αυτο. Κάνε ότι θέλεις κατά τη διάρκεια μιας συνέντευξης, αλλά δώσε την ευκαιρία στον υποψήφιο να γράψει λίγο κώδικα. (Για περισσότερες συμβουλές, διάβασε Οδηγός Guerrilla για Συνεντεύξεις)

12. Κάνεις έλεγχο ευκολίας χρήσης της εφαρμογής στο διάδρομο;
Οέλεγχος ευκολίας χρήσης του διαδρόμου συμβαίνει όταν αρπάζεις το πρώτο άτομο που περνάει εκείνη τη στιγμή από τον διάδρομο και τον αναγκάζεις να δοκιμάσει τον κώδικα που μόλις έγραψες. Αν θα το κάνεις αυτό σε πέντε άτομα, θα μάθεις το 95% όλων των προβλημάτων χρηστικότητας της εφαρμογής σου.

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

Αλλά το πιο σημαντικό πράγμα σχετικά με τα γραφικά περιβάλλοντα εφαρμογών είναι ότι αν δείξεις την εφαρμογή σου σε ένα μάτσο ανθρώπους, (βασίκα, πέντε ή έξι είναι αρκετοί) θα ανακλύψεις πολύ γρήγορα τα μεγαλύτερα προβλήματα που έχουν αυτοί οι άνθρωποι. Διάβασε το άρθρο του Ιάκοβου Νιλσεν που εξηγεί γιατί. Ακόμα και αν δεν είσαι ο ικανότερος σχεδιαστής γραφικού περιβάλλοντος, αρκεί να επιβάλλεις στον εαυτό σου να κάνει ελέγχους διαδρόμου, που είναι δωρεάν, και το γραφικό περιβάλλον σου θα είναι πολύ, πολύ καλύτερο.

Τέσσερις Τρόποι να Χρησιμοποιήσεις το Τεστ του Ιωήλ

  1. Βαθμολόγησε τη δική σου εταιρεία παραγωγής λογισμικού και πες μου τον βαθμό για να μπορώ να σε κουτσομπολεύω.
  2. Αν είσαι ο επικεφαλής μιας ομάδας προγραμματιστών, χρησιμοποίησέ το σαν λίστα ελέγχου για να εξασφαλίσεις ότι η ομάδα σου δουλεύει όσο πιο καλά γίνεται. Όταν θα αρχίσεις να βαθμολογείς με 12, μπορείς να αφήσεις του προγραμματιστές μόνους τους και να επικεντρωθείς πλήρως στο να σταματάς τους ανθρώπους της μέσης διοίκησης από το να τους ενοχλούν.
  3. Αν προσπαθείς να αποφασίσεις αν θα δουλέψεις κάπου ως προγραμματιστής, ρώτα τον υποψήφιο εργοδότη σου τι βαθμό παίρνουν σε αυτό το τεστ. Αν είναι πολύ χαμηλός, βεβαιώσου ότι θα έχεις την αρμοδιότητα να διορθώσεις τα προβλήματα. Διαφορετικά θα είσαι δυστυχής και μη παραγωγικός.
  4. Αν είσαι ένας επενδυτής που κρίνει την αξία μιας ομάδας προγραμματιστών ή αν η δική σου εταιρεία παραγωγής λογισμικού σκέφτεται να συγχωνευτεί με μια άλλη, αυτό το τεστ μπορεί να αποτελέσει ένα γενικό κανόνα.


Το άρθρο αυτό πρώτο-εμφανίστηκε στα Αγγλικά με το όνομα The Joel Test: 12 Steps to Better Code  

Ο Ιωήλ Σπολσκι είναι ο ιδρυτής της Fog Creek Software, μιας μικρής εταιρείας λογισμικού στη Νέα Υόρκη. Αποφοίτησε από το Πανεπιστήμιο του Γεηλ και εργάστηκε ως προγραμματιστής και στέλεχος διοίκησης στις εταιρείες Microsoft, Viacom και Juno.


Τα περιεχόμενα αυτών των σελίδων αντιπροσωπεύουν τις γνώμες ενός ατόμου.
Όλα τα περιεχόμενα Copyright ©1999-2005  του Ιωήλ Σπολσκι (Joel Spolsky). All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky