Pak:

 Εγώ, για παράδειγμα, δεν θα μπορούσα ποτέ να είμαι System/Network Engineer. Παραείμαι απρόσεχτος για αυτή τη δουλειά. Γιατί άλλο πράγμα να κάνεις λαθος στο κώδικα(το πιό πιθανό είναι να το πιάσει ο compiler η το τέστινγκ) και άλλο πράγμα να κάνεις λάθος σε Permissions η Group Policy η Backup (Το πιό πιθανόν είναι όταν το πάρεις χαμπάρι να είναι αργά).

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

---

Γιώργος Σακαλής

@Sakalis

Να σε θυμίσω ότι στο Software Develepment Lifecycle υπάρχει ένα τεράστιο κεφάλαιο που λέγεται TESTING. Τα λάθη που οδηγούν σε αυτά που ανέφερες σχεδον ποτέ δεν οφείλονται σε απροσεξίες αλλά σχεδόν πάντα σε κακή σχεδίαση και κακό έλεγχο. Δεν φαντάζομαι να ισχυρίζεσαι ότι ο κώδικας σου είναι αλάνθαστος!

Από την άλλη στον χώρο του ΙΤ infrastructure το testing δεν έχει ωριμάσει και τόσο...

---

Coding at Mediterranean Acoustics

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

---

Γιώργος Σακαλής

Ε τότε για ποιό λόγο υπάρχει το testing αν όχι για να ελέγχει ότι η εφαρμογή έχει υλοποιηθεί σωστά; Από την ώρα που υπάρχουν διαδικασίες όπως το unit testing, pair programming, code reviewing και τόσα αλλα επίπεδα testing(regression, integration etc) όταν ένα λάθος φτάσει σε production περιβάλλον τότε η ευθύνη δεν μπορεί να αποδοθεί σε ένα και μόνο άτομο. Οπόταν διαφωνώ κάθετα μαζι σου στο ότι ένας απρόσεχτος προγραμματιστής μπορεί να σκοτώσει άνθρωπο. Μάλλον μια ανεύθυνη επιχείρηση η μια ανίκανη ομάδα θα είναι η αιτία. Τελοσπάντων, ξεφευγουμε εκτός θέματος, αν θές ανοίγουμε άλλη συζήτηση...

---

Coding at Mediterranean Acoustics

Όχι, το testing δεν υπάρχει για να ελέγξει ότι η εφαρμογή υλοποιήθηκε σωστά και να διορθώσει σχεδιαστηκά λάθη του προγραμματιστή κλπ. Υπάρχει για να επιβεβαιώσει ότι η υλοποίηση ΤΟΥ ΚΩΔΙΚΑ δουλεύει σωστά.

Για παράδειγμα, μια function μπορεί να επιστρέφει σωστό αποτέλεσμα σε όλα τα στάδια testing αλλα η υλοποίησή της να είναι τέτοια, ώστε κάποια στιγμή, κάπως, να επιστρέψει λάθος, κι εάν αυτό το λάθος είναι ένα μηδενικό παραπάνω σε τραπεζική εφαρμογή, καταλαβαίνεις τι μπορεί να συμβεί.

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

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

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

Παναγιώτη δεν θέλω η συζήτηση να καταλήξει σε debate Defensive Programming Vs Testing. ENNOΕΙΤΑΙ ότι είναι και τα δύο βασικές αρχές του Software Development και είναι υπέραναγκαία για την κάθε υλοποίηση.

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

if(a>b){...do someting...}

γράφουμε

if(a>=b){...do something...}

Είναι αυτό φυσιολογικό; Πιστεύω πως ναί! Όλοι το έχουμε κάνει; Πιστεύω πως ναί! Είναι καταδικαστέο; Νομίζω πως όχι. Τυγχαίνει και στους καλύτερους Architects. Από εκεί και πέρα, από την ώρα που θα πατήσουμε το πράσινο τριγωνάκι στην πάνω μπάρα του VS(Run που λέμε, για να δούμε τι έκανα) τότε ξεκινάει το testing. Είναι από εκεί και πέρα επιτρεπτό αυτό να μας ξεφύγει; OXI!! Όταν λέω testing εννοώ κάθε διαδικασία επαλήθευσης πάνω στον κώδικα η οποία εκτελείται πέραν της αρχικής πληκτρολόγησης, από το αρχικό προσωπικό μας code review και unit testing μέχρι και το integration και stress testing.

 Από την άλλη ας δώσω το αντίστοιχο παράδειγμα στο χώρο του System engineering/Administration. Σας έτυχε ποτέ να κάνετε restore σε λάθος βάση; Στο interface του Restore του SQL Server 2005 υπάρχει μια σοβαρή σχεδιαστική αδυναμία. Με το που ανοιγει είναι προεπιλεγμένο το dropdownlist με τις βάσεις δεδομένων. Αν τώρα αγγίξεις αναιπέσθητα το scroll του ποντικιού τότε σου αλλάζει η βάση και δεν παίρνεις χαμπάρι! Αν τώρα πατήσεις το restore χωρίς να διπλότσεκάρεις την βάση(αυτό εννοώ απροσεξία), την έβαψες! Εδώ δεν υπάρχει επαλήθευση(τέστινγ)

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

Τα λάθη του System Engineer μπορούν να αποβούν θανατηφόρα από το πρώτο κλίκ σε αντίθεση με τα λάθη του Software Developer που πρέπει να περάσουν από μύρια κύματα μέχρι να βγούν στο production

---

Coding at Mediterranean Acoustics

Και ας δεχτούμε ότι έχεις δίκιο σε όσα λες

Στα παραπάνω postσ παρουσιάσες 2 διαφορετικές καταστάσεις. Από τη μία ένα περιβάλλον ανάπτυξης λογισμικού με πλήρη διαδικασία όπως unit tests, testing team, beta testing κτλ κτλ. και από την άλλη έναν κακόμοιρο admin που θα κάνει restore μια βάση σε παραγωγικό σύστημα έτσι απλά με το πάτημα ενός κουμπιού. Σε ποιο σοβαρό περιβάλλον δε θα υπάρχει ένα σύστημα αντίγραφο της παραγωγής όπου πρώτα εκεί θα δοκιμαστεί οποιαδήποτε αλλαγή ώστε να παίζει σωστά, να χτιστεί ένα script που θα κάνει αυτόματα τη δουλειά, και αυτό μετά θα τρέξει ομαλά στην παραγωγή? Η ποιος σοβαρός admin να κάνει μια αλλαγή σε ένα σύστημα εν ώρα λειτουργίας, ώστε οι αλλαγές να γίνουν άμεσα αντιληπτές, χωρίς να έχει χρόνο να δοκιμάσει ότι όλα είναι σωστά?

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

Ίσως να μη καταλάβαμε και οι 2 καλά τι είπες στα προηγούμενα post. H μπορεί να μη το εξέφρασες σωστά. Πάντως το επιχείρημα αν είσαι αρκετά αφηρημένος γίνει Software Engineer αλλιώς αν δεν είσαι γίνει System Engineer είναι επιεικώς αστείο.

---

Γιώργος Σακαλής

@Sakalis

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

Από εκεί και πέρα ας είμαστε ρεαλιστες. Ένα testing περιβάλλον υπάρχει ακόμα και single developer projects, στο software development. Από την άλλη δεν ξέρω πόσες εταιρίες ξέρεις μέχρι και μεσαιου μεγέθους έχουν αντίγραφο κάπου του infrastructure τους για να κάνουν test διάφορες αλλαγές που προτιθενται να κάνουν. Αν για παράδειγμα, θες να αλλάξεις ένα Group Policy στο Domain της εταιρίας θα υποχρεώσεις τους χρήστες να χρησιμοποιουν το test περιβαλλον για μια βδομαδα για να δεις αν όλα πάνε καλά; Ας μην γελιόμαστε, οι περισσότεροι admin δουλευουν σε production περιβαλλοντα και ας με διαψευσουν.

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

 Ένας Developer έχει περισσότερο την ψυχοσύνθεση ενός καλλιτέχνη. Θα σχεδιασει στο χαρτί, θα σκίσει, θα ξανασχεδιάσει, θα ξανασχίσει μέχρι να βρεί το ιδανικό. Έχει στα χέρια του  μοναδικά εργαλεία που λέγονται Iteration και Verification.

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

Ελπίζω να έγινα πιό κατανοητός

---

Coding at Mediterranean Acoustics

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

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

Όσον αφορά τις ψυχοσυνθέσεις και τη σύγκριση με καρδιοχειρούργο, επίσης διαφωνώ. Απλά να σου πω ότι το μοντέλο της ομάδας του καρδιοχειρούργου το έχει αναφέρει ο Fred Brooks από το 1970 ως μοντέλο οργάνωσης για .... developers. Είτε για IT μιλάς όμως, είτε για Software development, και στις δύο περιπτώσεις υπάρχει σχεδίαση. Κανείς (στα σωστά του) δεν πρόκειται να βασιστεί σε ενέργειες της στιγμής, στις οποίες δεν υπήρχε χρόνος προετοιμασίας και στις οποίες δεν υπάρχουν εναλλακτικές.

Επειδή και ο Γιώργος ο Σακαλής, και εγώ, δουλεύουμε στενά με τα IT τμήματα τραπεζών (διαφορετικών!) εδώ και 2 χρόνια, μπορώ να σε διαβεβαιώσω ότι ακολουθείται πάντα σχεδίαση των ενεργειών και αμέτρητες, ατελείωτες, συναντήσεις πριν δωθεί το OK για να γίνει κάποια ενέργεια όπως π.χ. να βγει μία εφαρμογή στην παραγωγή, ή ακόμα και να ξεκινήσει η ανάπτυξη της. Τί traffic έχει η εφαρμογή? Το αντέχουν τα δίκτυα? Τί αλλαγές ασφαλείας απαιτούνται αν είναι web εφαρμογή? Ποιά accounts? Τί backup procedures θα υλοποιηθούν? Ποιοί θα αναλάβουν το administration? Ποιοί θα αναλάβουν το monitoring? Τί μηχανήματα χρειάζονται, γιατί οι παραγγελίες καθυστερούν?
Τί εναλλακτικές έχουμε αν καθυστερήσει η παράδοση ενός server?
Δεν είναι λίγες οι φορές που μία εφαρμογή έπρεπε να σχεδιαστεί ξανά επειδή κρίθηκε απαράδεκτο το φορτίο που έβαζε στα δίκτυα ή σε άλλες εφαρμογές. Επίσης, δεν είναι λίγες οι φορές που ένα λάθος των προγραμματιστών δημιούργησε πρόβλημα στο deployment και ... έγινε του Ζαχαρία.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos