Απλές πρακτικές για καθαρό και διατηρήσιμο κώδικα
Είναι κοινό μυστικό στον ελληνικό χώρο είναι, ότι είμαστε τσαπατσούληδες μέχρι αηδίας! Οι πελάτες στον χώρο του software, είτε μιλάμε για εμπορικές εφαρμογές γραφείου, είτε για web, μας δυσκολεύουν πολύ περισσότερο από όσο πρέπει και μας βγάζουν από τα νερά μας! Ο βασικός λόγος είναι ότι δεν ξέρουν τι να ζητήσουν και πως! Καθώς επίσης και ότι μερικές φορές όταν μας καλούν να υλοποιήσουμε μία ιδέα τους, δεν ξέρουν κι αυτοί το εύρος της λειτουργικότητας της!
Η γνώμη μου είναι ότι αν δείτε ότι συμβαίνει κάτι τέτοιο, και δεν έχετε κάποιο συμφωνητικό που να σας προστατεύει από τέτοιου είδους μεταχείριση. Αλλά βασίζεστε στην καλή πίστη, που έτσι κι αλλιώς είναι αναγκαίο για την δημιουργία μίας συνεργασίας. Θα πρέπει να πείτε στον πελάτη, εξ αρχής να δοκιμάσουμε την ιδέα της μακέτας! Και δεν εννοώ μακέτα, να ζωγραφίσουμε πως θα είναι η εφαρμογή. Αλλά ένα βήμα παραπάνω… Να χρησιμοποιήσουμε την εφαρμογή με μολύβι και χαρτί! Είναι βασικός παράγοντας στο design, και στην χώρα μας, δεν είναι καθόλου γνωστή!
Έτσι θα μαζέψουμε τα χαρακτηριστικά που ζητάει ο πελάτης, πριν μας ζητήσει τριακόσια revisions!!! Οι διορθώσεις, δεν είναι από μόνες τους κακές, ωστόσο, αν κάποιος ζητήσει ένα χαρακτηριστικό, το οποίο ο παρών κώδικας δεν το υποστηρίζει. Θα αναγκαστούμε να αλλάξουμε ίσως πολύ βασικά πράγματα στον κώδικα, με αποτέλεσμα να θυσιάσουμε κάθε φορά λίγο από τη καλή λειτουργία που είχαμε πετύχει.
Ωστόσο, αυτό δεν το αποφεύγουμε πάντα. Είτε γιατί είναι προσωπικό μας project και γεμίζουμε σημειώσεις το κώδικα, με πράγματα που θα θέλαμε, που πρέπει να βάλουμε κτλ. Είτε ξυπνάμε κάποιο πρωί και λέμε, α για να αλλάξουμε λίγο αυτό το κομμάτι, χωρίς να θυμόμαστε γιατί το κάναμε αυτό εξ αρχής! Όλα αυτά καταλήγουν σε κακό κώδικα. Κώδικα που σπάει εύκολα και φυσικά bugs που θα μας πάρουν πολύ περισσότερο να διορθωθούν από τον ίδιο τον κώδικα, αν δε σταματήσουμε να σκεφτόμαστε με την Ελληνική μας, παραδοσιακή, μπακάλικη λογική!
Πρώτα από όλα ας ξεχάσουμε τα inline σχόλια, εκτός αν είναι πολύ απαραίτητα για κάποιον που θα διαβάσει τον κώδικα μετά. Κρατήστε ξεχωριστό αρχείο με τις σημειώσεις σας.
Οι ονομασίες (functions, μεταβλητές) πρέπει να είναι πάντα περιγραφικές και σύντομες! Χρησιμοποιούμε πάντα μία συγκεκριμένη δομή στην ονομασία. Υπάρχουν πολλές τεχνικές ονομασίας, οι πιο διαδεδομένες είναι το Pascal case (HelloWorld), και το camel case (helloWorld). Στην ουσία όμως, αυτό που μετράει είναι να διατηρείται η ίδια λογική σε όλο το μήκος τους κώδικα.
Κάθε function, θα κάνει μόνο ένα πράγμα, και θα παράγει μόνο ένα αποτέλεσμα! Δεν βοηθάει μόνο στη συστηματοποίηση της λογικής, αλλά και στην αποφυγή bugs και την γρήγορη διόρθωση τους! Στην περίπτωση συνάρτησης void, που δεν επιστρέφει τίποτα, αλλά πχ τυπώνει κάτι στην οθόνη. Προσέχουμε να αφαιρέσουμε πιθανούς υπολογισμούς και να τους βάλουμε σε ξεχωριστές συναρτήσεις. Αυτό βέβαια είναι στην κρίση μας και στο πόσο κολλάει η λογική των υπολογισμών μαζί. Αν διακινδυνεύουμε να γεμίσουμε πολλές μικρές συναρτήσεις, προφανώς δεν βοηθάει ο διαμοιρασμός των λειτουργιών.
Δε μαζεύουμε πολύ κώδικα, σε ένα αρχείο, αν δούμε ότι σπαταλάμε χρόνο στο scroll χωρίζουμε τον κώδικα σε διακριτά κομμάτια και έπειτα σε αρχεία με σύντομη και περιγραφική ονομασία, ώστε να έχουμε πρόσβαση στον κατάλληλο κώδικα μέσα σε δύο scroll max! (Εξαιρούνται περιπτώσεις καθαρής css και html).
Ακολουθούμε πρακτικές
Σταματάμε να δημιουργούμε τη δομή του κώδικα στην πορεία, χρησιμοποιούμε ως εργαλεία τις πρακτικές, τα design patterns. Δεν σκεφτόμαστε πρώτα, πως θα γράψω τον κώδικα, αλλά τι pattern μπορώ να χρησιμοποιήσω!
Δεν σπαταλάμε χρόνο, τον χρησιμοποιούμε σωστά!
Φροντίζουμε να παίρνουμε τον χρόνο που χρειάζόμαστε, ότι κι αν σημαίνει αυτό, γκρίνιες από τους πελάτες κτλ! Αλλά δε γράφουμε κώδικα που ξέρουμε ότι θα χρειαστεί να αλλάξει (τουλάχιστο σύντομα). Ο χρόνος πρέπει να αφιερώνεται σε ποιοτική δουλειά και όχι σε απροσεξίες και σφάλματα οργάνωσης! Οι πελάτες σε όλο τον κόσμο είναι απαιτητικοί, αλλά εμείς είμαστε υποχρεωμένοι να παράγουμε ένα άριστο προϊόν. Είναι πολύ χειρότερο να παραδώσουμε ένα προϊόν γεμάτο bugs, από το να αυξήσουμε τον χρόνο παραγωγής. Κυρίως, αν το συγκεκριμένο δεν στοχεύει σε ένα πελάτη αλλά σε πολλούς και είμαστε δεσμευμένοι να παρέχουμε υποστήριξη. Φανταστείτε, τι θα γίνει αν το εγκαταστήσουν 100 ή 1000 άνθρωποι, και δεν είναι σωστά φτιαγμένο. Την επόμενη μέρα, οι μισοί θα ζητάνε τα λεφτά τους πίσω και θα έχουμε γεμίσει μηνύματα για σφάλματα και bugs!
Τέλος, δε ξεχνάμε το Unit Testing
Αν δε γνωρίζετε τι είναι, ψάξτε το! Σε κάθε γλώσσα υπάρχουν unit testing frameworks, πχ στην php το phpunit, στο javascript το QUnit, στη C το Cute κτλ! Όλα αυτά είναι εφαρμογές/εργαλεία που μπορείτε να χρησιμοποιήσετε ώστε να τεστάρετε την λειτουργία των συναρτήσεων σας. Όπως και να φτιάχνετε γενικό διαγνωστικό κώδικα, βάσει συνθηκών!
Καλό κώδικα, λοιπόν!
Κατηγορίες:
Σχόλια