Προσωπικά ασχολούμαι με τον προγραμματισμό σχεδόν 10 χρόνια (με το web πολύ λιγότερα). Μέσα σε τόσα χρόνια τριβής με αυτόν, έχω καταλήξει σε κάποιους εμπειρικούς «κανόνες», που θεωρώ ότι οδηγούν σε ευκολότερη εκμάθηση μιας γλώσσας και ποιοτικότερο αποτέλεσμα, οπότε αποφάσισα να τους μοιραστώ μαζί σας, μήπως βοηθήσουν τους πιο άπειρους της παρέας.
Προς τους πιο έμπειρους της παρέας: Εσείς που ήδη τα ξέρετε αυτά, μπορείτε να προτείνετε δικές σας συμβουλές και να τις προσθέσω στο άρθρο (και –γιατί όχι;- να μάθω κι εγώ, όλοι μαθητές είμαστε όταν πρόκειται για κάτι τόσο ρευστό) ή αν διαφωνείτε με κάποια να γράψετε γιατί. Και μην απογοητεύεστε που δεν απευθύνεται σε εσάς το άρθρο, ετοιμάζω σύντομα post με κάτι javascript-related που ελπίζω ότι θα το βρείτε πολύ πιο ενδιαφέρον.
Οι περισσότερες από τις παρακάτω συμβουλές δεν περιορίζονται αποκλειστικά στο web development, αλλά θα μπορούσαν πιστεύω να φανούν χρήσιμες σε οποιαδήποτε γλώσσα προγραμματισμού.
Αξιοποιείτε τη νέα γνώση, έστω και μόνο στο μυαλό σας
Καθώς διαβάζετε κάτι, να προσπαθείτε πάντα να φανταστείτε κάποια εφαρμογή στην οποία θα μπορούσε να αποβεί χρήσιμο. Με αυτό τον τρόπο το θυμάστε πιο εύκολα, συγκεντρώνεστε περισσότερο και εκτιμάτε καλύτερα τη γνώση που σας προσφέρεται.
Μην “καίτε τις πηγές σας”
Αν έχετε κάποιους γνωστούς με μεγαλύτερη εμπειρία στη γλώσσα προγραμματισμού που μαθαίνετε, μην τρέχετε να τους ρωτάτε με την πρώτη δυσκολία που θα συναντήσετε. Έτσι “καίτε τις πηγές σας” όπως συνηθίζω να λέω, δηλαδή θα τους κουράσετε και όταν θα έχετε κάποια πραγματικά σοβαρή απορία, δεν θα είναι εκεί για να σας βοηθήσουν. Επιπλέον, πολύ περισσότερα κερδίζετε από τις δυσκολίες που συναντάτε, παρά από τις περιπτώσεις που αυτά που γράφετε δουλεύουν ρολόι, όσο κι αν δεν το συνειδητοποιείτε τώρα.
Μην βιάζεστε και μην βαριέστε
Μην βάζετε τόσο σύντομα ονόματα μεταβλητών που δεν είναι κατανοητό το τι κάνουν. Πολλές φορές ένας καλογραμμένος κώδικας, με ονόματα μεταβλητών και συναρτήσεων που “φωνάζουν” τι κάνουν, χρειάζεται λίγα ή και καθόλου σχόλια, ενώ ένας κώδικας γραμμένος βιαστικά, με ονόματα μεταβλητών το πολύ 5 γραμμάτων δεν βγάζει εύκολα νόημα όσα σχόλια και να του βάλετε. Εδώ προσωπικά μου χρησιμεύει ιδιαίτερα το copy-paste: Αντί να βάζω μικρά και ακαταλαβίστικα ονόματα μεταβλητών για να εξοικονομώ χρόνο, βάζω μεγάλα και κατανοητά (βέβαια όλα έχουν ένα όριο, το να γράφετε ολόκληρη πρόταση ως όνομα μεταβλητής ΔΕΝ είναι καλή πρακτική) και όταν χρειαστεί να τα ξαναχρησιμοποιήσω, τα κάνω copy-paste. Έτσι γλιτώνω και τυχόν σφάλματα από typos.
Η προτροπή του υπότιτλου έχει και μια ακόμα έκφανση: Μην αφήνετε στην άκρη τον κώδικα μόλις απλά δουλέψει. Ο προγραμματισμός είναι τέχνη, και στην τέχνη, υπάρχουν πολλοί διαφορετικοί τρόποι για την επίλυση του ίδιου προβλήματος. Να στοχεύετε προς τον πιο καλογραμμένο και αποδοτικό κώδικα, όχι απλά αυτόν που δουλεύει (εκτός προφανώς αν το deadline σας πιέζει πολύ, αλλά συνήθως όταν μαθαίνετε προγραμματισμό δεν έχετε συγκεκριμένο deadline!).
Η αντιγραφή ολόκληρων τμημάτων κώδικα είναι κακό σημάδι
Αν παρατηρήσετε ότι χρειάζεται να αντιγράψετε τμήμα κώδικα που έχετε ήδη γράψει και να του αλλάξετε απλώς κάποια πράγματα, τότε ίσως πρέπει να αναλογιστείτε μήπως θα ήταν καλύτερο να τον μεταφέρετε σε κάποια επιμέρους διαδικασία/συνάρτηση και να καλείτε αυτή ή να βρείτε έναν άλλο τρόπο ώστε ο κώδικας που είναι κοινός να γράφεται μόνο μία φορά (παραδείγματος χάριν, αν διαφοροποιείται η συμπεριφορά του κώδικα σε μια γραμμή αναλόγως την τιμή κάποιας μεταβλητής, τότε κάντε τον έλεγχο μόνο σε αυτή τη γραμμή, όχι πιο έξω). Αν αυτό συμβαίνει πολλές φορές, με σχετιζόμενα μεταξύ τους κομμάτια κώδικα, ίσως θα έπρεπε να δημιουργήσετε και χωριστή κλάση (αν γράφετε αντικειμενοστρεφώς). Όσο μεγαλύτερο το κομμάτι κώδικα, και όσο μικρότερες οι αλλαγές που απαιτούνται κάθε φορά, τόσο πιθανότερο είναι να χρειάζεται κάτι τέτοιο.
Μην βάζετε άσκοπα σχόλια
Τώρα που είστε αρχάριοι, όλοι θα σας τονίζουν την αξία των σχολίων, οπότε δεν θα το κάνω κι εγώ. Εγώ εδώ θα εξετάσω μια άλλη πτυχή του θέματος: Τα υπερβολικά πολλά σχόλια είναι εξίσου άχρηστα με την απουσία σχολίων. Δεν χρειάζεται να σχολιάζετε το προφανές, και εσείς χάνετε χρόνο, και αυτός που θα διαβάσει τον κώδικα σας στο μέλλον. Προσέξτε μόνο μια λεπτή διαφορά: Αυτό που θεωρείτε προφανές τώρα, μπορεί στο μέλλον να μην σας φαίνεται καθόλου προφανές. Πρέπει να μάθετε να ξεχωρίζετε το πραγματικά προφανές, από αυτό που φαίνεται προφανές λόγω τριβής με τον συγκεκριμένο κώδικα (μια διάκριση που κι εγώ πολλές φορές δυσκολεύομαι να κάνω).
Τα σχόλια είναι χρήσιμα κυρίως στις παρακάτω περιπτώσεις:
- Δυσνόητα κομμάτια κώδικα, συνήθως επειδή χρησιμοποιήσατε κάποιο «τρικ» αντί να πάτε με την πεπατημένη (η πεπατημένη συνήθως είναι και self-explanatory). Ειδικά όταν χρησιμοποιείτε πολλά regular expressions, επιβάλλεται να γράφετε και σχόλια.
- Δηλώσεις συναρτήσεων και κλάσεων. Ακόμα κι αν είναι προφανές από το όνομα αυτό που κάνει μια συνάρτηση/κλάση, είναι εξίσου προφανές και το πώς χρησιμοποιείται;
- Στο τέλος μεγάλων μπλοκ κώδικα. Παραδείγματος χάριν, αν έχετε μια συνάρτηση με μέσα διάφορα μεγάλα εμφωλευμένα loops και ifs είναι πιθανό (ειδικά αν η γλώσσα στην οποία γράφετε χρησιμοποιεί το ίδιο σύμβολο για να κλείνει όλα τα μπλοκ, συνήθως το ‘}’ ) να μην ξέρετε που τελειώνει τι, ακόμα κι αν έχετε βάλει σωστές εσοχές. Σε αυτές τις περιπτώσεις είναι χρήσιμο ένα σχόλιο δίπλα στο κάθε closing brace που να αναφέρει ΤΙ είναι αυτό που τελειώνει εκεί.
- Σε περιπτώσεις που ξέρετε ότι ο κώδικας σας θα αναγνωστεί από άτομα με μηδαμινή ή πολύ μικρή εμπειρία, καλό θα ήταν να βάλετε αρκετά περισσότερα σχόλια από όσα χρειάζονται. Θα γλιτώσετε πολλές κουραστικές ερωτήσεις.
Μην ξεχνάτε να αφαιρείτε τις debugging ενέργειες σας
Σε κάθε γλώσσα προγραμματισμού χρησιμοποιούμε τις συναρτήσεις εμφάνισης κειμένου για debugging. Στη javascript τα alerts, στην PHP την echo, στη Java τη System.out.println() και ούτω καθεξής. Πολλές φορές τα αφήνουμε εκεί ακόμα και αφότου βρούμε το πρόβλημα, μιας και δεν μας ενοχλεί να βλέπουμε για παράδειγμα και ένα alert μερικές φορές καθώς αναπτύσσουμε την εφαρμογή και αναβάλλουμε την αφαίρεση του για αργότερα που θα τελειώσει το πρόγραμμα/script. Ωστόσο, συνήθως χρειάζεται να κάνετε debugging πάνω από μία φορά, και στο τέλος δεν θα ξέρετε ποιο alert εμφανίζει τι και θα καταλήξετε να ψάχνετε τον κώδικα για να βγάλετε άκρη (και να αφαιρέσετε τότε τα debugging κομμάτια που είχαν ξεμείνει). Δεν είναι καλύτερο να τα αφαιρείτε αμέσως μετά;
————————————————-
Κάτι άσχετο: Έχω δει ότι εδώ και πολύ καιρό με έχει προσκαλέσει ο lexx στο “My Desktop right now” game. Ο λόγος που δεν έχω απαντήσει, είναι ότι το desktop μου είναι αρκετά default, μιας και το χρησιμοποιώ ελάχιστα (ο,τι χρειάζομαι είναι συντόμευση στο Quick Launch ή στο Start Menu). Ακόμα και το wallpaper είναι το default των Vista, μιας και αφενός μεν το βλέπω σπάνια, αφετέρου το θεωρώ πολύ αξιόλογο.
Πολύ ωραίες συμβουλές και για νέους στο χώρο αλλά και για πιο experienced.
το να Μην “καίτε τις πηγές σας” είναι πιστεύω μια από τις ποιο σοφές συμβουλές η καλύτερα μια από τις ποιο σοφές αρχές.
Μία ακόμα συμβουλή είναι πως όταν προσπαθείς να μάθεις κάτι νέο να ανατρέχεις σε κομμάτια ανοιχτού κώδικα .
Πάντα βοηθάει να δεις τι έκανε κάποιος άλλος πριν από εσένα. Δυστυχώς δύσκολα υπάρχει παρθενογένεση σήμερα.
Ευχαριστώ για τα σχόλια σας lexx και Παρασκευά!
@Παρασκευάς: Συμφωνώ μαζί σου, αλλά πιστεύω ότι αυτή η συμβουλή εμπίπτει σε λίγο πιο έμπειρους. Αν ένας που τώρα μαθαίνει μια γλώσσα ανατρέξει σε κομμάτια κώδικα πολύ έμπειρων προγραμματιστών, είναι πιθανό να απογοητευτεί, να μπερδευτεί και να μην καταλάβει και τίποτα.
Καλύτερα να διαβάσει πρώτα ένα βιβλίο ώστε να μπει σωστά και ομαλά “στο κλίμα”, να γράψει και λίγο κώδικα μόνος του, και μετά. Το παραπάνω φυσικά αποτελεί καθαρά προσωπική άποψη, έχω διαπιστώσει ότι υπάρχουν εξίσου αξιόλογοι developers που είναι κατά των βιβλίων και θεωρούν ότι πρέπει να μάθεις από παραδείγματα άλλων εξ’αρχής. Φαντάζομαι ότι έχει να κάνει με το πώς έμαθε ο καθένας.
“Μην καίτε τις πηγές σας”. Πράγματι, είναι σοφό. Εγώ, μόλις 13 ετών θέλω να μάθω προγραμματισμό(λίγο δύσκολο το βλέπω) και έχω “κάψει” ήδη μια πηγή ρωτώντας συνεχώς “βλακείες”. Αν το διάβαζα πιο νωρίς…