Ως Ανώτερος Μηχανικός Λογισμικού, αναζητώ πάντα ευκαιρίες για να βελτιώσω τις δεξιότητές μου για προγραμματιστές και να παραμένω ενημερωμένος σε έναν συνεχώς μεταβαλλόμενο κλάδο. Πρόσφατα διάβασα το The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition» των David Thomas και Andrew Hunt και ενθουσιάστηκα από τον πλούτο της πολύτιμης γνώσης και των συμβουλών που περιείχε. Κράτησα πολλές σημειώσεις και ήθελα να μοιραστώ μερικά από τα βασικά σημεία που μου ξεχώρισαν περισσότερο. Σε αυτό το άρθρο, μοιράζομαι 101 από τις βασικές γνώσεις μου από κάθε κεφάλαιο/θέμα στο πλαίσιο του "The Pragmatic Programmer". Είτε είστε έμπειρος προγραμματιστής είτε αρχάριος, ελπίζω να βρείτε μερικά πετράδια σε αυτήν τη σύνοψη. Ας αρχίσουμε!

Κεφάλαιο 1: Μια πραγματιστική φιλοσοφία

Θέμα 1: Είναι η ζωή σου

  • 1: Είναι σημαντικό να οικειοποιηθείτε τη ζωή και την καριέρα σας ως προγραμματιστής λογισμικού. Έχετε την υπηρεσία να κάνετε αλλαγές και αποφάσεις που θα ωφελήσουν εσάς και την επαγγελματική σας εξέλιξη.
  • 2: Μην είσαι παθητικός στην καριέρα σου. Πάρτε την πρωτοβουλία να μάθετε νέες δεξιότητες, να δοκιμάσετε νέα πράγματα και να κάνετε αλλαγές εάν το τρέχον εργασιακό περιβάλλον ή η εργασία σας δεν ανταποκρίνεται στις ανάγκες σας. Μην περιμένετε από κάποιον άλλο να σας προσφέρει ευκαιρίες, αναζητήστε τις μόνοι σας.

Θέμα 2: Η γάτα έφαγε τον πηγαίο κώδικα μου

  • 3: Οι πραγματιστές προγραμματιστές αναλαμβάνουν την ευθύνη για τη σταδιοδρομία, τη μάθηση και τη δουλειά τους.
  • 4: Η εμπιστοσύνη είναι σημαντική για την επιτυχία μιας ομάδας και είναι σημαντικό να είσαι ειλικρινής και να παραδέχεσαι τα λάθη ή τις ελλείψεις.
  • 5: Όταν αποδέχεστε την ευθύνη για ένα αποτέλεσμα, θα πρέπει να περιμένετε να λογοδοτήσετε για αυτό. Παραδεχτείτε τα λάθη και προσφέρετε επιλογές αντί να δικαιολογείτε.
  • 6: Είναι σημαντικό να είστε προορατικοί στον εντοπισμό και την αντιμετώπιση προβλημάτων και κινδύνων και να επικοινωνείτε έγκαιρα πιθανά ζητήματα σε άλλους.

Θέμα 3: Εντροπία λογισμικού

  • 7: Η ψυχολογία ή η κουλτούρα ενός έργου μπορεί να συμβάλει σε μεγάλο βαθμό στη σήψη λογισμικού. Μια αίσθηση απελπισίας ή εγκατάλειψης μπορεί να εξαπλωθεί μεταξύ των μελών της ομάδας, οδηγώντας σε μια καθοδική σπείρα.
  • 8: Για να αποφευχθεί η σήψη του λογισμικού, είναι σημαντικό να διορθώσετε «σπασμένα παράθυρα» ή μικρά ζητήματα, μόλις ανακαλυφθούν. Η παραμέληση αυτών των θεμάτων μπορεί να οδηγήσει σε σοβαρές δομικές βλάβες και σε αίσθηση εγκατάλειψης.

Θέμα 4: Πέτρινη σούπα και βρασμένοι βάτραχοι

  • 9: Χρησιμοποιήστε μικρές, σταδιακές αλλαγές για να επιτύχετε έναν μεγαλύτερο στόχο, δείχνοντας τα πιθανά οφέλη και επιτρέποντας σε άλλους να συμμετάσχουν στην επιτυχία.
  • 10: Έχετε επίγνωση των σταδιακών αλλαγών και των πιθανών συνεπειών τους και εργαστείτε ενεργά για να αποτρέψετε την εμφάνιση αρνητικών αλλαγών.

Θέμα 5: Αρκετά καλό λογισμικό

  • 11: Το αρκετά καλό λογισμικό είναι λογισμικό που ανταποκρίνεται στις ανάγκες του χρήστη, μπορεί να συντηρηθεί και πληροί βασικά πρότυπα απόδοσης, απορρήτου και ασφάλειας, αλλά μπορεί να μην είναι απαραίτητα τέλειο.
  • 12: Είναι σημαντικό να γνωρίζετε πότε πρέπει να σταματήσετε να εργάζεστε σε ένα πρόγραμμα και να το αφήνετε να παραμείνει μόνο του, αντί να συνεχίσετε να προσθέτετε επίπεδα και λεπτομέρειες που μπορεί τελικά να βλάψουν τη συνολική ποιότητα του λογισμικού.
  • 13: Η συντήρηση του λογισμικού και η επιδιόρθωση ελαττωμάτων θα πρέπει να είναι μια συνεχής διαδικασία και όχι μια εφάπαξ προσπάθεια στο τέλος ενός έργου.
  • 14: Είναι σημαντικό να ιεραρχούνται και να διορθώνονται τα ελαττώματα με βάση τον πιθανό αντίκτυπό τους και τη δυσκολία επίλυσής τους.

Θέμα 6: Το χαρτοφυλάκιο γνώσεων σας

  • 15: Η αξία της γνώσης και της εμπειρίας ενός προγραμματιστή μειώνεται με την πάροδο του χρόνου, επομένως είναι σημαντικό να επενδύει συνεχώς και να ενημερώνει το χαρτοφυλάκιο γνώσεών του για να παραμένει ενημερωμένο και πολύτιμο για την εταιρεία ή τους πελάτες του.
  • 16: Για να διαχειρίζονται αποτελεσματικά το χαρτοφυλάκιο γνώσεων τους, οι προγραμματιστές πρέπει να επενδύουν τακτικά, να διαφοροποιούν τις γνώσεις τους, να εξισορροπούν τη μάθησή τους μεταξύ τομέων υψηλού και χαμηλού κινδύνου, να αναζητούν νέες τεχνολογίες προτού γίνουν δημοφιλείς και να επανεξετάζουν και να εξισορροπούν τακτικά το χαρτοφυλάκιό τους.
  • 17: Ο καθορισμός συγκεκριμένων, μετρήσιμων, επιτεύξιμων, σχετικών και χρονικά δεσμευμένων στόχων (στόχοι SMART) μπορεί να βοηθήσει τους προγραμματιστές να επενδύσουν αποτελεσματικά στο χαρτοφυλάκιο γνώσεων τους.
  • 18: Η οικοδόμηση ενός δικτύου ενημερωμένων και έμπειρων ατόμων, όπως η συμμετοχή σε συνέδρια του κλάδου, η συμμετοχή σε επαγγελματικούς οργανισμούς ή η συμμετοχή σε διαδικτυακές κοινότητες, μπορεί επίσης να βοηθήσει τους προγραμματιστές να παραμείνουν ενημερωμένοι και να επεκτείνουν τις γνώσεις τους.
  • 19: Η συνεχής αναζήτηση νέων ευκαιριών μάθησης, όπως μέσω αυτοδιδασκαλίας, διαδικτυακών μαθημάτων ή απόκτησης πρόσθετων πιστοποιήσεων, μπορεί επίσης να βοηθήσει τους προγραμματιστές να παραμείνουν ανταγωνιστικοί και πολύτιμοι στον τομέα τους.

Θέμα 7: Επικοινωνήστε!

  • 20: Η αποτελεσματική επικοινωνία είναι απαραίτητη για έναν προγραμματιστή για να μεταφέρει ιδέες και να συνεργάζεται αποτελεσματικά με άλλους.
  • 21: Γνωρίστε το κοινό σας και τι θέλετε να πείτε πριν επικοινωνήσετε. Σκεφτείτε να χρησιμοποιήσετε οπτικά βοηθήματα.
  • 22: Συγκεντρώστε σχόλια και βελτιώστε συνεχώς τις επικοινωνιακές σας δεξιότητες.

Κεφάλαιο 2: Μια πραγματιστική προσέγγιση

Θέμα 8: Η ουσία του καλού σχεδιασμού

  • 23: Το καλό σχέδιο αλλάζει ευκολότερα από το κακό σχέδιο.
  • 24: Ακολουθήστε την αρχή ETC: Ευκολότερη αλλαγή. Για να διευκολύνετε την αλλαγή του κώδικα, είναι σημαντικό να τον διατηρήσετε αποσυνδεδεμένο και συνεκτικό και να τον αντικαταστήσετε αν είναι δυνατόν.

Θέμα 9: DRY — The Evils of Duplication

  • 25: Η αρχή DRY (Don’t Repeat Yourself) δηλώνει ότι κάθε κομμάτι γνώσης πρέπει να έχει μια ενιαία, σαφή, έγκυρη αναπαράσταση σε ένα σύστημα.
  • 26: Το DRY ισχύει για κάτι περισσότερο από τον απλό κώδικα, αναφέρεται επίσης στην επικάλυψη γνώσης ή πρόθεσης που εκφράζεται σε διαφορετικά μέρη ή μορφές.
  • 27: Η αντιγραφή κώδικα μπορεί να οδηγήσει σε εφιάλτες συντήρησης και μειωμένη αξιοπιστία στο λογισμικό. Για να το αποφύγετε, προσπαθήστε να εντοπίσετε κοινά μοτίβα και να τα αφαιρέσετε σε επαναχρησιμοποιήσιμα στοιχεία. Χρησιμοποιήστε τεχνικές όπως η κληρονομικότητα, η σύνθεση και η ανάθεση για να εξαλείψετε την επικάλυψη.
  • 28: Χρησιμοποιήστε βιβλιοθήκες, πλαίσια και εργαλεία για να αποφύγετε την επανεφεύρεση του τροχού και την επανάληψη της εργασίας.

Θέμα 10: Ορθογωνικότητα

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

Θέμα 11: Αναστρεψιμότητα

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

Θέμα 12: Σφαίρες ιχνηθέτη

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

Θέμα 13: Πρωτότυπα και Post-it Notes

  • 35: Η δημιουργία πρωτοτύπων είναι ένας τρόπος για να δοκιμάσετε ιδέες και να μειώσετε τον κίνδυνο στην ανάπτυξη λογισμικού.
  • 36: Τα πρωτότυπα μπορεί να βασίζονται σε κώδικα ή χωρίς κώδικα, όπως η χρήση σημειώσεων ή σχεδίων Post-it. Τα πράγματα που πρέπει να δημιουργηθούν περιλαμβάνουν αρχιτεκτονική, νέες λειτουργίες, δομές δεδομένων, εργαλεία τρίτων, ζητήματα απόδοσης και σχεδιασμό διεπαφής χρήστη.
  • 37: Όταν συλλέγετε σχόλια για ένα πρωτότυπο, εστιάστε στις πτυχές που δοκιμάζονται και αποφύγετε να κολλήσετε σε λεπτομέρειες.

Θέμα 14: Γλώσσες Τομέα

  • 38: Η χρήση μιας γλώσσας προγραμματισμού που αντικατοπτρίζει το λεξιλόγιο και τη σύνταξη του τομέα του προβλήματος μπορεί να διευκολύνει την κατανόηση και την επίλυση του προβλήματος. Παραδείγματα γλωσσών τομέα περιλαμβάνουν τις RSpec, Cucumber, Phoenix Routes και Ansible.

Θέμα 15: Εκτίμηση

  • 39: Η εκτίμηση είναι μια δεξιότητα που μπορεί να σας βοηθήσει να κατανοήσετε τη σκοπιμότητα εργασιών και έργων και να προβλέψετε τα αποτελέσματα.
  • 40: Η ακρίβεια μιας εκτίμησης εξαρτάται από το πλαίσιο στο οποίο χρησιμοποιείται. Χρησιμοποιήστε μονάδες που αντικατοπτρίζουν την επιδιωκόμενη ακρίβεια της εκτίμησης. Επίσης, οι πιο ακριβείς εκτιμήσεις προέρχονται από άτομα που έχουν εκτελέσει παρόμοιες εργασίες στο παρελθόν.
  • 41: Χρησιμοποιήστε μια προσέγγιση από πάνω προς τα κάτω για την εκτίμηση μεγάλων εργασιών, χωρίζοντάς τες σε μικρότερα μέρη και προσθέτοντας εκτιμήσεις για κάθε μέρος. Χρησιμοποιήστε μια προσέγγιση από κάτω προς τα πάνω για την εκτίμηση μικρών εργασιών προσθέτοντας εκτιμήσεις για κάθε μεμονωμένη εργασία.
  • 42: Να παρέχετε πάντα ένα εύρος εκτιμήσεων και να εξηγείτε τυχόν υποθέσεις που γίνονται.

Κεφάλαιο 3: Τα βασικά εργαλεία

Θέμα 16: Η δύναμη του απλού κειμένου

  • 43: Το απλό κείμενο είναι ένας απλός και αποτελεσματικός τρόπος αποθήκευσης γνώσης που μπορεί να χειριστεί και να διαβαστεί από ανθρώπους και υπολογιστές.
  • 44: Σχεδόν κάθε εργαλείο στο σύμπαν των υπολογιστών μπορεί να λειτουργήσει σε απλό κείμενο, καθιστώντας το μια ισχυρή και ευέλικτη μορφή.

Θέμα 17: Παιχνίδια Shell

  • 45: Το κέλυφος εντολών είναι ένα ισχυρό εργαλείο για τον χειρισμό κειμένου και την αυτοματοποίηση εργασιών. Η προσαρμογή του κελύφους εντολών μπορεί να βελτιώσει την παραγωγικότητα και να το κάνει πιο εύκολο στη χρήση.
  • 46: Οι διεπαφές GUI έχουν περιορισμούς και δεν μπορούν πάντα να εκτελούν εργασίες εκτός του προβλεπόμενου πεδίου εφαρμογής τους.
  • 47: Είναι σημαντικό να μάθετε τις βασικές δεξιότητες του κελύφους και να εξοικειωθείτε με τα εργαλεία που είναι διαθέσιμα στο κέλυφος.

Θέμα 18: Power Editing

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

Θέμα 19: Έλεγχος έκδοσης

  • 49: Να χρησιμοποιείτε πάντα τον έλεγχο έκδοσης, ακόμη και για μικρά έργα ή αρχεία που δεν είναι πηγαίου κώδικα, όπως η τεκμηρίωση.

Θέμα 20: Εντοπισμός σφαλμάτων

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

Θέμα 21: Χειρισμός κειμένου

  • 53: Οι γλώσσες χειρισμού κειμένου είναι ισχυρά εργαλεία για γρήγορη εκτέλεση μετασχηματισμών σε κείμενο, δημιουργία πρωτοτύπων ιδεών και αυτοματοποίηση εργασιών.

Θέμα 22: Μηχανικά Ημερήσια Βιβλία

  • 54: Ένα ημερολόγιο μηχανικής είναι ένα περιοδικό στο οποίο ένας μηχανικός καταγράφει την εργασία, τις ιδέες, τις αναγνώσεις του και άλλες σχετικές πληροφορίες. Η διατήρηση ενός βιβλίου ημέρας είναι πιο αξιόπιστη από το να βασίζεσαι στη μνήμη και μπορεί να προσφέρει ένα μέρος για αποθήκευση ιδεών και προβληματισμό για εργασίες. Σκεφτείτε να χρησιμοποιήσετε χαρτί για ένα ημερήσιο ημερήσιο μηχανικό αντί για ένα ψηφιακό αρχείο ή ένα wiki.

Κεφάλαιο 4: Πραγματική παράνοια

Θέμα 23: Σχεδιασμός με σύμβαση

  • 55: Design by Contract (DBC) είναι μια τεχνική για τη διασφάλιση της ορθότητας του προγράμματος τεκμηριώνοντας τα δικαιώματα και τις ευθύνες των ενοτήτων λογισμικού. Αποτελείται από προϋποθέσεις (απαιτήσεις που πρέπει να πληρούνται για να κληθεί η συνάρτηση ή η μέθοδος), μετασυνθήκες (εγγυημένη έξοδος της συνάρτησης) και αμετάβλητες κλάσης (συνθήκες που πρέπει πάντα να ισχύουν από την οπτική γωνία ενός καλούντος). Η τήρηση του DBC μπορεί να βοηθήσει τους προγραμματιστές να διασφαλίσουν την ορθότητα του προγράμματος, να κάνει τον κώδικα πιο ευανάγνωστο και κατανοητό και να επιτρέψει την καλύτερη συνεργασία μεταξύ των προγραμματιστών.

Θέμα 24: Τα νεκρά προγράμματα δεν λένε ψέματα

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

Θέμα 25: Διεκδικητικός Προγραμματισμός

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

Θέμα 26: Πώς να εξισορροπήσετε τους πόρους

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

Θέμα 27: Μην ξεπερνάτε τους προβολείς σας

  • 60: Κάντε μικρά, συνειδητά βήματα στην αναπτυξιακή σας εργασία και λάβετε συνεχή ανατροφοδότηση για να προσαρμόσετε την προσέγγισή σας. Πριν ξεκινήσετε την κωδικοποίηση, βεβαιωθείτε ότι έχετε πλήρη κατανόηση του προβλήματος που προσπαθείτε να λύσετε.
  • 61: Αποφύγετε εργασίες που απαιτούν «μάντι» ή πρόβλεψη μελλοντικών γεγονότων ή αναγκών, καθώς ενέχουν υψηλό κίνδυνο να είναι λανθασμένες. Σχεδιάστε τον κώδικά σας ώστε να είναι αντικαταστάσιμος αντί να προσπαθείτε να προβλέψετε και να σχεδιάσετε για ένα αβέβαιο μέλλον.

Κεφάλαιο 5: Λυγίστε ή σπάστε

Θέμα 28: Αποσύνδεση

  • 62: Η σύζευξη είναι ο εχθρός της αλλαγής. Γιατί ενώνει πράγματα που χρειάζονται αλλαγή παράλληλα, κάνοντας την αλλαγή πιο δύσκολη. Τα συμπτώματα σύζευξης περιλαμβάνουν μη φυσιολογικές εξαρτήσεις μεταξύ άσχετων λειτουργικών μονάδων, «απλές» αλλαγές που επηρεάζουν άσχετα μέρη του συστήματος και οι προγραμματιστές φοβούνται τις αλλαγές κώδικα.
  • 63: Οι τρόποι αποσύνδεσης κώδικα περιλαμβάνουν τη χρήση μικρότερων μεθόδων, τη χρήση διεπαφών και αφηρημένων κλάσεων, τη χρήση ένεσης εξάρτησης και τη χρήση μηνυμάτων και αρχιτεκτονικών που βασίζονται σε συμβάντα

Θέμα 29: Ζογκλέρ στον πραγματικό κόσμο

  • 64: Προκειμένου να γίνουν οι εφαρμογές πιο διαδραστικές και αποτελεσματικές, θα πρέπει να σχεδιαστούν έτσι ώστε να ανταποκρίνονται σε γεγονότα και να προσαρμόζουν ανάλογα τη συμπεριφορά τους. Υπάρχουν 4 στρατηγικές για τη σύνταξη αποκριτικών εφαρμογών: Μηχανές πεπερασμένης κατάστασης, μοτίβο παρατηρητή, δημοσίευση/εγγραφή και αντιδραστικός προγραμματισμός και ροές.
  • 65: Οι μηχανές πεπερασμένης κατάστασης (FSM) είναι ένας τρόπος καθορισμού του τρόπου χειρισμού συμβάντων ορίζοντας ένα σύνολο καταστάσεων και τα γεγονότα που είναι σημαντικά για κάθε κατάσταση, καθώς και τη νέα κατάσταση που προκύπτει για κάθε συμβάν. Τα FSM μπορούν να αναπαρασταθούν ως δεδομένα σε έναν πίνακα και να υλοποιηθούν με απλό κώδικα.
  • 66: Το μοτίβο παρατηρητή περιλαμβάνει αντικείμενα που εγγράφονται σε συμβάντα και ειδοποιούνται όταν συμβαίνουν.
  • 67: Στο Publish/Subscribe Pattern, τα αντικείμενα δημοσιεύουν συμβάντα και άλλα αντικείμενα εγγράφονται σε αυτά.
  • 68: Ο αντιδραστικός προγραμματισμός και οι ροές περιλαμβάνουν τη δημιουργία και τον χειρισμό ροών γεγονότων και την αντίδραση σε αυτά καθώς συμβαίνουν.

Θέμα 30: Μετασχηματισμός Προγραμματισμού

  • 69: Είναι σημαντικό να εστιάσουμε στον μετασχηματισμό των δεδομένων στον προγραμματισμό, παρά στον ίδιο τον κώδικα. Υπάρχουν 2 προσεγγίσεις για την εύρεση των απαραίτητων μετασχηματισμών σε ένα πρόγραμμα. Η πρώτη προσέγγιση ξεκινά με την απαίτηση και τον προσδιορισμό των εισροών και εκροών. Η δεύτερη προσέγγιση είναι η έναρξη με τα δεδομένα και ο καθορισμός των απαραίτητων μετασχηματισμών για την επίτευξη του επιθυμητού αποτελέσματος.

Θέμα 31: Φόρος Κληρονομιάς

  • 70: Αντί να χρησιμοποιείτε κληρονομικότητα, είναι συχνά καλύτερο να χρησιμοποιείτε σύνθεση και «πληκτρολόγηση πάπιας» για να επιτύχετε τους ίδιους στόχους. Το "Duck typing" αναφέρεται σε ένα στυλ ελέγχου τύπου στο οποίο οι μέθοδοι και οι ιδιότητες ενός αντικειμένου καθορίζουν τον τύπο του, αντί για την κληρονομιά του από μια συγκεκριμένη κλάση ή υλοποίηση μιας συγκεκριμένης διεπαφής. Αυτό σημαίνει ότι εάν ένα αντικείμενο έχει τις μεθόδους και τις ιδιότητες που απαιτούνται για μια συγκεκριμένη εργασία, μπορεί να χρησιμοποιηθεί σε αυτήν την εργασία ανεξάρτητα από τον πραγματικό τύπο του.

Θέμα 32: Διαμόρφωση

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

Κεφάλαιο 6: Συγχρονισμός

Θέμα 33: Σπάσιμο της χρονικής σύζευξης

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

Θέμα 34: Η κοινή κατάσταση είναι εσφαλμένη κατάσταση

  • 74: Είναι γενικά καλύτερο να αποφεύγετε την κοινή κατάσταση όποτε είναι δυνατόν. Μπορεί να οδηγήσει σε εσφαλμένα ή ασυνεπή αποτελέσματα.

Θέμα 35: Παράγοντες και Διεργασίες

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

Θέμα 36: Μαυροπίνακες

  • 76: Οι μαυροπίνακες είναι μια μορφή συγχρονισμού όπου ανεξάρτητες διεργασίες ή πράκτορες συνεισφέρουν και ανακτούν πληροφορίες από μια κοινή δομή δεδομένων (ο μαυροπίνακας). Οι μαυροπίνακες μπορούν να χρησιμοποιηθούν σε καταστάσεις όπου τα δεδομένα μπορούν να φτάσουν με οποιαδήποτε σειρά και όπου η συλλογή δεδομένων μπορεί να γίνει από διαφορετικά συστήματα. Οι μαυροπίνακες μπορούν να χρησιμοποιηθούν για τον συντονισμό και τη διαχείριση πολύπλοκων διαδικασιών όπου υπάρχουν εξαρτήσεις και περιορισμοί δεδομένων.

Κεφάλαιο 7: Ενώ Κωδικοποιείτε

Θέμα 37: Listen to Your Lizard Brain

  • 77: Είναι σύνηθες οι άνθρωποι να αισθάνονται δισταγμό ή δυσφορία όταν ξεκινούν ένα νέο έργο ή εργασία. Αυτός ο δισταγμός μπορεί να είναι μια ενστικτώδης απάντηση που βασίζεται σε προηγούμενη εμπειρία ή αμφιβολίες για τις ικανότητές του. Είναι σημαντικό να ακούτε και να αναγνωρίζετε αυτά τα συναισθήματα προκειμένου να εντοπίσετε και να αντιμετωπίσετε τυχόν πιθανά προβλήματα.
  • 78: Η κωδικοποίηση μπορεί επίσης να είναι δύσκολη και απογοητευτική μερικές φορές, και αυτό μπορεί να είναι σημάδι ότι υπάρχει κάτι λάθος με τη δομή ή την προσέγγιση που ακολουθείται. Είναι σημαντικό να ακούτε και να εμπιστεύεστε αυτά τα ένστικτα για να εντοπίσετε και να διορθώσετε προβλήματα.
  • 79: Για να ακούτε και να εμπιστεύεστε τα ένστικτα κάποιου, είναι σημαντικό να αφήσετε χρόνο και χώρο για να βγουν στην επιφάνεια και να αναγνωριστούν, να δώσετε προσοχή στις σωματικές αισθήσεις και συναισθήματα και να εξασκήσετε την επίγνωση και την αυτογνωσία.

Θέμα 38: Προγραμματισμός κατά σύμπτωση

  • 80: «Προγραμματισμός κατά σύμπτωση» αναφέρεται στη βάση της τύχης και των τυχαίων επιτυχιών αντί του προγραμματισμού εσκεμμένα. Αποφύγετε το κατανοώντας τον λόγο για τον οποίο λειτουργεί ο κώδικας και όχι απλώς βασιζόμενοι στο γεγονός ότι φαίνεται να λειτουργεί. Οι καλές δοκιμές και η τεκμηρίωση θα βοηθήσουν επίσης να διορθωθεί αυτό.

Θέμα 39: Ταχύτητα αλγόριθμου

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

Θέμα 40: Refactoring

  • 82: Το Refactoring θα πρέπει να είναι μια καθημερινή δραστηριότητα, κάνοντας μικρά βήματα χαμηλού κινδύνου, αντί για μια ειδική, υψηλής τελετής, δραστηριότητα μια φορά τη φορά. Μερικοί λόγοι για αναμόρφωση περιλαμβάνουν: διπλασιασμό, μη ορθογώνιο σχεδιασμό, ξεπερασμένες γνώσεις, αλλαγές χρήσης ή βελτίωση της εσωτερικής ποιότητας.
  • 83: Το Test-Driven Development (TDD) μπορεί να χρησιμοποιηθεί για την ασφαλή αναπαράσταση κώδικα. Απαιτούνται καλές αυτοματοποιημένες δοκιμές μονάδας για να διασφαλιστεί ότι η εξωτερική συμπεριφορά δεν έχει αλλάξει κατά την ανακατασκευή.

Θέμα 41: Test to Code

  • 84: Τα κύρια οφέλη της δοκιμής προκύπτουν κατά τη διάρκεια της διαδικασίας σκέψης και γραφής, και όχι μόνο κατά την εκτέλεση των δοκιμών. Η δοκιμή παρέχει πολύτιμη ανατροφοδότηση που μπορεί να καθοδηγήσει την κωδικοποίηση και η σκέψη σχετικά με τις δοκιμές μπορεί να βοηθήσει στην αποσαφήνιση της κατανόησης του κώδικα και στην απλοποίηση της λογικής του.
  • 85: Το TDD είναι ως επί το πλείστον ωφέλιμο, αλλά μπορεί επίσης να οδηγήσει σε υπερβολική εστίαση στην κάλυψη των δοκιμών και σε περιττές δοκιμές. Όταν χρησιμοποιείτε το TDD, είναι σημαντικό να θυμάστε ότι ο στόχος είναι η παραγωγή κώδικα εργασίας, όχι απλώς η επιτυχία δοκιμών.

Θέμα 42: Έλεγχος βάσει ιδιοτήτων

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

Θέμα 43: Μείνετε ασφαλείς εκεί έξω

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

Θέμα 44: Ονομασία πραγμάτων

  • 88: Η ονομασία των πραγμάτων σε κώδικα είναι σημαντική καθώς αποκαλύπτει την πρόθεση και την πεποίθηση του προγραμματιστή. Χρησιμοποιήστε περιγραφικά ονόματα που αποδίδουν ξεκάθαρα το σκοπό του πράγματος.

Κεφάλαιο 8: Πριν από το Έργο

Θέμα 45: The Requirements Pit

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

Θέμα 46: Επίλυση αδύνατων γρίφων

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

Θέμα 47: Δουλεύοντας Μαζί

  • 94: Οι συνεργατικές προσεγγίσεις όπως ο προγραμματισμός σε ζευγάρια και όχλος μπορούν να βοηθήσουν στη βελτίωση της επικοινωνίας μέσα σε μια ομάδα και να οδηγήσουν σε πιο συνεκτικά και καλά σχεδιασμένα συστήματα. Για παράδειγμα, ο προγραμματισμός ζευγών, όπου ένα άτομο κωδικοποιεί ενώ ένα άλλο σχολιάζει και βοηθά στην επίλυση προβλημάτων, μπορεί να είναι ένας ισχυρός τρόπος συνεργασίας και παραγωγής λογισμικού υψηλότερης ποιότητας. Ο προγραμματισμός Mob, όπου ολόκληρη η ομάδα εργάζεται μαζί για το ίδιο πρόβλημα την ίδια στιγμή, μπορεί επίσης να είναι μια αποτελεσματική προσέγγιση.

Θέμα 48: Η ουσία της ευκινησίας

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

Κεφάλαιο 9: Πραγματικά έργα

Θέμα 49: Πραγματικές Ομάδες

  • 96: Η ρεαλιστική ομάδα στο σύνολό της θα πρέπει να δώσει προτεραιότητα στη διατήρηση της υψηλής ποιότητας και να παρακολουθεί ενεργά για αλλαγές στο περιβάλλον του έργου. Η αποτελεσματική επικοινωνία εντός της ομάδας και με τους ενδιαφερόμενους είναι ζωτικής σημασίας για την επιτυχία. Οι ομάδες θα πρέπει να επιδιώκουν τη διαφάνεια και τη συνεργασία και να επιτρέπουν την ευελιξία και την προσαρμοστικότητα.
  • 97: Η επένδυση στη γνώση και τις δεξιότητες της ομάδας μέσω προγραμματισμένου χρόνου μάθησης και ανάπτυξης είναι σημαντική για τη βελτίωση και την καινοτομία.

Θέμα 50: Οι καρύδες δεν το κόβουν

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

Θέμα 51: Pragmatic Starter Kit

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

Θέμα 52: Απολαύστε τους χρήστες σας

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

Θέμα 53: Υπερηφάνεια και Προκατάληψη

  • 101: Να είστε υπερήφανοι για τη δουλειά σας και να είστε υπεύθυνοι για το σχέδιο και τον κώδικα που παράγετε. Προσπαθήστε να αναγνωριστείτε ως επαγγελματίας και υψηλής ποιότητας προγραμματιστής.

συμπέρασμα

Ελπίζω να βρήκατε αυτές τις 101 προτάσεις χρήσιμες και εμπνευσμένες. Προσπάθησα να συλλάβω την ουσία των βασικών γνώσεων και συστάσεων του βιβλίου, αλλά τίποτα δεν είναι καλύτερο να διαβάσετε ολόκληρο το βιβλίο μόνοι σας. Υπάρχουν πολλά παραδείγματα κώδικα που δεν συμπεριέλαβα σε αυτό το άρθρο. Εάν σκέφτεστε σοβαρά να βελτιώσετε τις προγραμματιστικές σας δεξιότητες και να μεγιστοποιήσετε την αποτελεσματικότητά σας ως προγραμματιστής, σας συνιστώ να πάρετε ένα αντίγραφο του The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition» και να το μελετήσετε προσεκτικά. Εάν έχετε διαβάσει το βιβλίο και έχετε οποιεσδήποτε σκέψεις ή προτάσεις δικές σας, αφήστε ένα σχόλιο παρακάτω για να το μοιραστείτε με άλλους!

Δημοσιεύτηκε αρχικά στη διεύθυνση https://www.miketsamis.com στις 8 Ιανουαρίου 2023.