Code Quality Assurance. Η εκτίμηση βασίζεται πάντα σε δύο ειδών κριτήρια. Στα αντικειμενικά και στα ειδικά.

Transcript

1 Code Quality Assurance > MANAGEMENT 1. Εκτίμηση Κοστολόγηση Η εκτίμηση βασίζεται πάντα σε δύο ειδών κριτήρια. Στα αντικειμενικά και στα ειδικά. a. Αντικειμενικά είναι τα κριτήρια εκείνα που πρέπει να καλυφθούν τεχνικά και διαχειριστικά από την εκκίνηση εώς τη παράδοση του έργου. Πχ. Ένα δύσκολο slider με πολλές λειτουργίες b. Ειδικά θεωρούνται τα κριτήρια που είναι μοναδικά ανά πελάτη/έργο και πρέπει να λαμβάνονται υπ όψιν καθώς επειρεάζουν και αυτά στο χρόνο και τρόπο υλοποίησης. Πχ. Στο έργο υπάρχει συμμετοχη πολλών ατόμων από διαφορετικές εταιρίες για κρίσιμης σημασίας πράγματα. Συνυπολογισμός καθυστερήσεων. 2. Έγκριση Στην έγκριση, λαμβάνονται υπ όψιν όλοι οι παράμετροι της εκτίμησης και της κοστολόγησης για το έργο και λαμβάνεται η τελική απόφαση για την έναρξη ή μή του έργου. Πιαθνοί λόγοι για μή έναρξη έργου είναι a. Μεγάλο χρονικό διάστημα υλοποίησης λόγω αντικειμενικής τεχνικής περιπλοκότητας σε συνάρτηση με χαμηλότερη κοστολόγηση. b. Αντικειμενικές δυσκολίες τεχνικής φύσης που υπερβαίνουν το κανονικό για τον αριθμό ατόμων ή την εξειδίκευση τους σε σχέση με τις απαιτήσεις του έργου. c. Μή έγκριση για άλλους διαφορετικούς λόγους από τους παραπάνω, βάσει απόφασης του ceo. 3. Προτεραιότητα Δρομολόγηση a. Προτεραιότητα Ο συντονισμός της εκτέλεσης εργασιών που αφορούν στα έργα βρίσκεται στο CEO. Συνεπώς από αυτό προκύπτει και η προτεραιότητα ολοκλήρωσης των

2 έργων. b. Η δρομολήγηση, αφορά στην οριοθέτηση χρονικών σημείων στα οποία εκκινούμε ή παύουμε ένα έργο. Γενικά, η διαχείριση αυτή του χρόνου που αφιερώνουμε σε κάθε έργο γίνεται από εμάς, εκτός από περιπτώσεις που μας ζητείται να καλύψουμε έκτακτα το χρόνο μας με την ολοκλήρωση μίας εργασίας σε ένα έργο για άλλους λόγους, όπου και πρέπει να γίνεται επαναπροσαρμογή του προγράμματος μας βάσει των νέων δεδομένων που έχουν προκύψει. Σε περίπτωση που δεν μπορούμε να κρίνουμε πώς θα γίνει αυτή η αναπροσαρμογή του χρόνου για τα έργα κάνουμε συζήτηση με το CEO ώστε να μας κατευθύνει σε αυτό. > WEB DEVELOPMENT a. Θέματα Κώδικα i. Δεν γράφουμε πράγματα καρφί, δηλαδή δε δηλώνουμε τίποτα από τα παρακάτω στην απόλυτη μορφή τους ii. iii. iv. Server paths (πχ /var/www/ μέσα στο κώδικα μας!) Server environment variables (δε ξέρουμε ότι έχουν οριστεί σε άλλο μηχάνημα!) Ειδική προσοχή στα configurations! v. Γενικά, καλό είναι να κάνουμε προσπάθεια να βάζουμε ΟΛΑ τα configurations σε ένα κοινόχρηστο και κοινά προσβάσιμο αρχείο (ini κατά προτίμηση) από όλες τις εφαρμογές του φακέλου που εργαζόμαστε (πχ site root /site/conf.ini) vi. vii. viii. Το δυνατόν λιγότερος κώδικας για το δυνατόν περισσότερη λειτουργικότητα Δέν χρειάζομαι ποτέ μία μεγάλη library για να υποστηρίξω μία απλή λειτουργία. Προσεκτική ανάλυση και παρατήρηση του υπάρχοντος κώδικα όταν θέλουμε να προσθέσουμε λειτουργικότητα σε μία υπάρχουσα δομή/αλγόριθμο. Εξέταση όλων εκείνων των στοιχείων που μπορεί να φανούν χρήσιμα.

3 ix. Χρειάζομαι πραγματικά όλο το κώδικα που έχω? Μήπως υπάρχει κώδικας που απλώς υπάρχει και είναι ουσιαστικά άχρηστος? x. Υπάρχουν μεταβλητές που δε χρησιμοποιούνται? xi. xii. xiii. xiv. xv. xvi. Υπάρχουν αντικείμενα (arrays, objects κλπ) που δεν περιέχουν δεδομένα σε καμία περίπτωση και άρα δε χρησιμοποιούνται? Υπάρχουν συναρτήσεις οι οποίες δεν χρησιμοποιούνται πάνω από μία φορά ή είναι σίγουρο ότι δε θα χρησιμοποιηθούν πάνω από μία φορά? Μπορούν να δηλωθούν ώς μεταβλητές. Μήπως χρησιμοποιώ πολλά for, foreach, while? Εμφολεύω πάντα το κώδικα που θα χρησιμοποιήσω ξανά για να μήν επαναλαμβάνομαι. Εμφολεύω πάντα τη λογική μίας επέκτασης λειτουργίας λογισμικού (module, plugin, extension) σε επαναχρησιμοποιήσιμη μορφή για το συγκεκριμένο λογισμικό και τη συγκεκριμένη έκδοση του επάνω στην την οποία αναπτύσσω κώδικα τη στιγμή εκείνη, με σημείωση αυτών των πληροφοριών σε κάποιο σχόλιο ή ιδανικά στη καλύτερα εμφανή θέση που μπορώ να βρώ (ως πρός το σύνολο του λογισμικού) Δεν εφευρίσκω το τροχό κάθε φορά που θέλω να γράψω ένα κώδικα. Ψάχνω πάντα να βρώ επαναχρησιμοποιούμενο κώδικα που θα τον φέρω στα μέτρα της δικής μου ζητούμενης λειτουργικότητας και θα το κάνω μέρος της δικής μου λογικής. Για να γίνει αυτό σωστά, θα πρέπει να εκκινήσω σωστά τη διαδικασία αναζήτησης και να γνωρίζω με σχεδόν απόλυτη ακρίβεια τα εξής 1. Τη λογική εκτέλεσης του προγράμματος στο σύνολο 2. Τη λογική εκτέλεσης της συνάρτησης/αλγόριθμου που θα τοποθετήσω ή θα τροποποιήσω τη λογική, 3. Την ακριβή τροποποίηση που πρόκειται να εφαρμώσω 4. Το ακριβές αντίκτυπο της τροποποίησης μου, όχι μόνο να για υποστηρίξω τη νέα λειτουργία αλλά και στο σύνολο της ρουτίνας που περιέχετε αλλά και του συνόλου του λογισμικού. b. Διαχείριση πόρων και βέλτιστες πρακτικές ανάπτυξης Κατά την ανάπτυξη εφαρμογών (για το διαδίκτυο) εκτός από τη παραπάνω προσέγκιση που αφορά καθ ολοκληρία στο κώδικα, θα πρέπει να γίνονται και μία σειρά από άλλες ενέργειες που αφορούν στη διαχείριση διαφόρων πόρων.

4 Επίσης, θα πρέπει να υπάρχει μία τουλάχιστον καλή γνώση επάνω σε θέματα δομής λογισμικού. i. Ελέγχουμε πάντα να μή περιλαμβάνουμε εξωτερικούς πόρους μεταφερόμενους κυρίως με http καθώς επιβαρύνουμε σημαντικά το συνολικό χρόνο φόρτωσης της σελίδας και βάζουμε πιθανότητες να προκύψουν προβλήματα στη συμπεριφορά της σελίδας. Μερικά χαρακτηριστικά παραδείγματα είναι 1. Χρήση CDN για λήψη libraries (jacascript, css libraries όπως jquery) 2. Χρήση εξωτερικού συνδέσμου για λήψη γραμματοσειράς (πχ Google font) ii. iii. iv. Ελέγχω πόση μνήμη, δίσκο και δίκτυο χρησιμοποιεί μία εφαρμογή κατά την εκτέλεση της γενικά και ειδικά μετά από δικές μου παρεμβάσεις. Χρησιμοποιώ όλα τα διαθέσιμα και μή μέσα για τη παρατήρηση της συμπεριφοράς ενός λογισμικού. Όπως πχ 1. Debug σε επίπεδο server (x debug στο ubuntu για php Μέσω netbeans) 2. Network panel σε επίπεδο client (κίνηση δικτύου, ποιά αρχεία καθυστερούν και γιατί.) a. TTBT > είναι πολύ σημαντικός δείκτης καθώς μας δείχνει πόση ώρα κάνει ο server να επεξεργαστεί ένα αίτημα. Υποδηλώνει προβλήματα και καθυστερήσεις στο κώδικα μας κατά κύριο λόγο. b. Content Download > είναι ο χρόνος που χρειάστηκε για να κατέβει το περιεχόμενο του request από το διακομιστή στο client. Υποδηλώνει προβλήματα μεγάλου μεγέθους, μεγάλου latency range (θέμα δηλαδή server ή client cache) 3. Εργαλεία καταγραφής σφαλμάτων υπηρεσιών μηχανήματος (apache2, php κλπ) η εφαρμογής η δικά μας. Παράδειγμα, a. Apache2 access log για network requests tracking b. Apache2 error log για τα σφάλματα που αναφέρει ο handler της PHP στο επίπεδο που έχουμε ορίσει πχ errors, warnings, notices, info. c. Opencart (συνήθως system/storage/logs/error.txt στη v ) και αντίστοιχο access log στον ίδιο φάκελο. 4. Άλλα εργαλεία, παράδειγμα a. Υπηρεσίες παρατήρησης (πχ new relic) b. Υπηρεσίες αυτοματοποίησης (deploy.io) Γνωρίζω σε βάθος το τρόπο που είναι δομημένο ένα λογισμικό. Για να εκτελέσω οποιαδήποτε απλή ή πιο σύνθετη παρέμβαση σε ένα κώδικα, προαπαιτούμενο είναι η γνώση του τρόπου που το λογισμικό αυτό εκτελείται, να γνωρίσω δηλαδή το κύκλο ζωής (ροή) του προγράμματος.

5 Μόνο έτσι, μπορώ να παρεμβαίνω πάντα σωστά και στοχευμένα για την επίλυση οποιουδήποτε προβλήματος προκύψει ή την βέλτιστη ανάπτυξη της οποιαδήποτε επιπλέον λειτουργίας. Οι διαδεδομένοι και πλέον εμπλεκόμενοι τρόποι δόμησης εφαρμογής (design patterns) που περιέχονται και στα λογισμικά διαδικτύου είναι 1. MVC (MODEL VIEW CONTROLLER) 2. STRATEGY 3. SINGLETON v. Προσοχή στη διαχείριση έργου κατά τη μετάβαση σε παραγωγικό περιβάλλον 1. Δεν αφήνουμε configurations που είναι σχετικά με το Local περιβάλλον 2. Δεν αφήνουμε dev σχολιασμούς ειδικά αν κάνουν expose ευαίσθητες πτυχές της υλοποίησης. 3. Αφήνουμε σχόλια που αφορούν στο τί είναι αυτό που έχουμε γράψει και κυρίως τους περιγραφείς της γλώσσας. Πχ, αναπτύσουμε μία συνάρτηση. Μπορούμε να αναφέρουμε a. Ότι είναι πχ Protected b. Ότι έχει 2 ορίσματα, το τύπο δεδομένων των ορισμάτων, αν απαιτούν δεδομένα ή αρχικοποιούνται μόνα τους στη τιμή x. c. Ότι είναι Στατική (δυναμική από ορισμό) αφορά τη php. 4. Κάνουμε προσεκτικό έλεγχο σε όλα τα σημεία της εφαρμογής που παράγουν ή περιέχουν συνδέσμους. a. Στους εξωτερικούς συνδέσμους, ελέγχουμε αν χρειάζεται να ανοίγουν εκτός ή εντός εφαρμογής. b. Στους εσωτερικούς συνδέσμους, ελέγχουμε να είναι generic populated ώστε σε περίπτωση μετάβασης σε νέο domain name να μπορεί η εφαρμογή να τρέχει κανονικά. c. Ποτέ δε δηλώνουμε ή htts:// καθώς μπορεί να αλλάξει. Το δηλώνουμε συνήθως globally ώς ρύθμιση της εφαρμογής μας. c. Τεχνικές Λεπτομέρειες i. H html5 και το DOM είναι οι βασικοί πυλώνες γύρω από τους οποίους αναπτύσουμε κώδικα για το web. ii. Τα παρακάτω πρέπει να απαντώνται πρίν και κατά τη διάρκεια της διαδικασίας της εκτίμησης ενός έργου 1. Θα βασίζεται σε μία ή σε περισσότερες γλώσσες? Αφορά το χρόνο παράδοσης και όχι μετέπειτα. a. Με διαχείριση των λεκτικών από γραφικό περιβάλλον b. Με διαχείριση των λεκτικών από αρχεία γλώσσας 2. Περιοχές με εξαιρετικά μεγάλη συχνότητα επαναχρησιμότητας περιέχονται σε διαφορετικά αρχεία και γίνονται include. Πχ. Header και footer αρχεία σε ένα template.

6 3. Γενικά, κάθε στοιχείο της HTML5 που φέρει ειδικό χαρακτήρα όπως πχ ένα menu, μία λίστα, ένα quotation, θα πρέπει να συντάσσονται με τον αντίστοιχο ειδικό και ενδεδειγμένο τρόπο όπου είναι δυνατό. Πχ, μενού πλοήγησης, <nav> αντί για <div id= nav > Πχ, περιοχή footer, <footer> αντί για <section class= footer > 4. Όλα τα javascript είναι καλό να τοποθετούνται στο τέλος ακριβώς πρίν κλείσει το body tag, εκτός αν το script που χρησιμοποιούμε ορίζει κάτι διαφορετικό. Πχ, facebook script ορίζει να μπεί javascript στο head tag. 5. Όλα τα css αρχεία είναι καλό να τοποθετούνται στο head και πρίν αυτό κλείσει. Γενικά, είναι καλή πρακτική όλα τα css να συνδιάζονται σε ένα μεγάλο αρχείο, το ίδιο ισχύει και για τη javascript. Αυτή η πρακτική είναι καλό να εφαρμόζεται όταν ένα site βγαίνει στη παραγωγή. 6. Δε φορτώνουμε ποτέ 2 ή παραπάνω εκδόσεις ίδιες ή διαφορετικές από το ίδιο library. Μπορεί να οδηγήσει σε πολύ σοβαρές δυσλειτουργίες. 7. Φορτώνουμε πάντα τη javascript με τρόπο τέτοιο ώστε να εκτελεστεί σωστά. Πχ. Κάνουμε λήψη του jquery_mobile πρίν φορτώσουμε το jquery. Η προτεραιότητα είναι το jquery και συνεπώς θα έχουμε πρόβλημα αν το φορτώσουμε δεύτερο. > TROUBLESHOOTING 1. Τα προβλήματα έχουν σημαντικότητα. a. Κλίμακα σημαντικότητας 1. Ένα/παραπάνω από ένα site δεν λειτουργεί. Εξαιρετικής σημασίας, θα πρέπει να αντιμετοπίζεται άμεσα. 2. Σημαντικό πρόβλημα με αποστολή/λήψη και γενικά mail server. 3. Δεσμευτική καταληκτική ημ/νία για παράδοση έργου. b. Λογική επίλυσης προβλημάτων i. Όταν έρχεται ένα νέο πρόβλημα θα πρέπει να ακολουθούμε τη νοοτροπία και την πεποίθηση ότι μπορούμε να το λύσουμε και ότι δεν έχουμε άλλη πηγή βοήθειας. ii. Θα πρέπει να γίνεται αξιολόγηση του προβλήματος, ώστε να οριστεί ένα χρονικό όριο επίλυσης. iii. Μόλις το χρονικό όριο για την επίλυση ενός προβλήματος έχει ξεπεραστεί, θα πρέπει το πρόβλημα να κοινοποιηθεί σε επιπλέον άτομα της εταιρίας που κατέχουν σχετική γνώση και μπορούν να συνδράμουν προς την επίλυση του.

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