Οι πιο περίεργες αρχές προγραμματισμού που δεν έχετε ποτέ ακούσει

Διαφήμιση

Έχουμε ήδη περάσει μέσα από το πιο ουσιαστικές αρχές προγραμματισμού 10 Βασικές Αρχές Προγραμματισμού Κάθε Προγραμματιστής πρέπει να ακολουθήσειΠάντα να γράφετε κώδικα που μπορεί να διατηρηθεί από οποιονδήποτε μπορεί να καταλήξει να εργάζεται στο λογισμικό σας. Για το σκοπό αυτό, εδώ υπάρχουν αρκετές αρχές προγραμματισμού που σας βοηθούν να καθαρίσετε την πράξη σας. Διαβάστε περισσότερα πρέπει να ξέρετε, αλλά υπάρχει μια άλλη κατηγορία αρχών προγραμματισμού που μπορεί να αποδειχθεί ακόμα πιο επωφελής από εκείνα.

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

1. Η Αρχή του Bloat

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

Νόμος του Ζαουβσκι, που ονομάστηκε από τον Jamie Zawinski και αναφέρθηκε στο Η τέχνη του προγραμματισμού UNIX:

"Κάθε πρόγραμμα προσπαθεί να επεκταθεί μέχρι να διαβάσει τα μηνύματα. Τα προγράμματα που δεν μπορούν να επεκταθούν, αντικαθίστανται από αυτά που μπορούν. "

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

Αυτό ισχύει και για την απόδοση του λογισμικού:

"Το λογισμικό επεκτείνεται για να καταναλώσει όλους τους διαθέσιμους πόρους."

Πίσω στη δεκαετία του '90, οι σκληροί δίσκοι και οι CPU και RAM ήταν πολύ πιο περιοριστικοί από ό, τι σήμερα και οι προγραμματιστές εργάστηκαν σκληρά για να ταιριάξουν όσο μπορούσαν εντός των ορίων. Ωστόσο, τώρα που έχουμε μεγαλύτερες μονάδες δίσκου και ταχύτερους CPU και περισσότερη μνήμη RAM, εξακολουθούμε να αγωνιζόμαστε για το σεβασμό των ορίων. Όλα φουσκώνονται με την πάροδο του χρόνου. Είναι δική σας δουλειά να το κρατάτε υπό έλεγχο.

2. Η "χειρότερη είναι η καλύτερη" νοοτροπία

Σχεδόν σαν να ανταποκρινόμαστε στην αρχή του Bloat, έχουμε το Η χειρότερη είναι η καλύτερη νοοτροπία, για πρώτη φορά από τον Richard P. Gabriel σε ένα δοκίμιο που έγραψε για την ποιότητα του λογισμικού:

"Το λογισμικό που είναι περιορισμένο, αλλά απλό στη χρήση, μπορεί να είναι πιο ελκυστικό για τον χρήστη και την αγορά από ό, τι το αντίστροφο."

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

Τι συμβαίνει όταν αγνοείτε αυτό; Καταλήγετε με το Λογισμικό Peter Principle:

"Ένα υπερβολικά σύνθετο έργο τελικά θα γίνει πολύ περίπλοκο για να γίνει κατανοητό ακόμα και από τους δικούς του προγραμματιστές".

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

3. Νόμος του Eagleson

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

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

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

4. Αρχή της ελάχιστης έκπληξης

"Εάν ένα απαραίτητο χαρακτηριστικό έχει έναν παράγοντα μεγάλης έκπληξης, μπορεί να χρειαστεί να επανασχεδιάσετε το χαρακτηριστικό."

Δημοσιεύθηκε για πρώτη φορά στο IBM Systems Journal το 1984, αυτή η αρχή εξακολουθεί να είναι εκπληκτικά σχετική σήμερα - ίσως περισσότερο από ποτέ.

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

5. Νόμος της Κυβερνητικής Εντομολογίας

"Υπάρχει πάντα ένα ακόμα σφάλμα."

Συχνά καλείται Ο νόμος της Κυβερνητικής Εντομολογίας του Lubarsky, δεν είναι σαφές ποιος είναι αυτός ο Lubarsky στην πραγματικότητα. Ωστόσο, η αρχή του χτυπάει αλήθεια για όλους τους προγραμματιστές: δεν έχει σημασία πόσο καθαρά γράφετε τον κώδικα σας, ανεξάρτητα από το πώς Δοκιμάζετε με ακρίβεια τις μονάδες σας, ανεξάρτητα από το πόσο συχνά επαναπροσδιορίζεστε τα μαθήματά σας, θα υπάρχει πάντα ένα άλλο σφάλμα.

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

6. Ο νόμος του Κέρνιγκαν

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

Ο Brian Kernighan, ο ίδιος που συν-συγγραφέας τη γλώσσα προγραμματισμού C Βίβλος Γιατί ο προγραμματισμός C αξίζει ακόμα να μάθειΤο C δεν είναι νεκρή γλώσσα. Στην πραγματικότητα, το περιοδικό IEEE Spectrum το κατέταξε ως την κορυφαία γλώσσα του αριθ. 2 το 2017. Εδώ είναι πέντε λόγοι για τους οποίους. Διαβάστε περισσότερα , είναι διάσημο για αυτόν τον διορατικό νόμο. Το κύριο σημείο είναι αυτό: γράψτε Καλός κωδικός, γράψτε αναγνώσιμος κωδικός, γράψτε απλός κώδικας, οτιδήποτε όσο δεν είναι έξυπνος κώδικας.

Προσπαθώντας να φέρετε τους μυς προγραμματισμού σας με πολυπλοκότητα πύργου ελεφαντόδοντου είναι ακριβώς το αντίθετο από αυτό που σημαίνει γράψτε καθαρό και καλύτερο κώδικα 10 Συμβουλές για το γράψιμο Cleaner & Better CodeΓράφοντας καθαρό κώδικα φαίνεται ευκολότερο από ό, τι στην πραγματικότητα είναι, αλλά τα οφέλη αξίζει τον κόπο. Δείτε πώς μπορείτε να αρχίσετε να γράφετε καθαρότερος κώδικας σήμερα. Διαβάστε περισσότερα . Όσο πιο δύσκολο είναι να καταλάβετε τον κώδικα, τόσο πιο δύσκολο θα είναι να κάνετε εντοπισμό σφαλμάτων όταν σπάσει αναπόφευκτα.

Και ως Robert C. Ο Martin εξηγεί ότι δεν πρόκειται απλά για σφάλμα:

"Πράγματι, ο λόγος του χρόνου που περνάει η ανάγνωση έναντι της γραφής είναι πολύ πάνω από 10 προς 1. Διαβάζουμε συνεχώς τον παλαιό κώδικα ως μέρος της προσπάθειας να γράψουμε νέο κώδικα... [Επομένως], καθιστώντας εύκολη την ανάγνωση, διευκολύνεται η εγγραφή. "

7. Ελαττώματα από καουτσούκ

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

Πρώτα είπα στο Ο πραγματικός προγραμματιστής, λάθος πάπια καουτσούκ είναι όταν εντοπίζετε σφάλμα σε σπασμένο λογισμικό, εξηγώντας τον κώδικα σας σε ένα άψυχο αντικείμενο (π.χ. μια πάπια από καουτσούκ) μία γραμμή τη φορά. Λειτουργεί επειδή η πράξη εξήγησης ενεργοποιεί διαφορετικά μέρη του εγκεφάλου σας και είναι πιο πιθανό να εντοπίσετε ασυνέπειες και να καταλάβετε πού πήγατε στραβά.

Για το λόγο αυτό, μια πάπια από καουτσούκ μπορεί να είναι α εκπληκτικά χαριτωμένο δώρο για προγραμματιστές Τα καλύτερα δώρα για προγραμματιστές Geek: 20 ιδέες για κωδικοποιητές και αγριεήματαΨάχνετε για ένα δώρο για έναν προγραμματιστή; Εδώ είναι τα καλύτερα δώρα geek, που κυμαίνονται από τα μηχανικά πληκτρολόγια μέχρι τα μόνιμα γραφεία και πολλά άλλα. Διαβάστε περισσότερα , αν το αγοράζετε για τον εαυτό σας ή για έναν δικό σας προγραμματιστή φίλο.

8. Ο Ενενήντα Ενενήντα Κανόνας

"Το πρώτο 90 τοις εκατό του κώδικα αντιστοιχεί στο πρώτο 90 τοις εκατό του χρόνου ανάπτυξης. Το υπόλοιπο 10% του κώδικα αντιστοιχεί στο άλλο 90% του χρόνου ανάπτυξης. "

Αυτή η μπερδεμένη μικρή παροιμία του Tom Cargill βρίσκεται στην καρδιά του γιατί ο προγραμματισμός μπορεί να είναι τόσο απογοητευτικός: δεν έχει σημασία πόσο κοντά νομίζετε ότι τελειώνετε, είστε πολύ πιο μακριά από τις καλύτερες εκτιμήσεις σας. Όταν νομίζετε ότι έχετε τελειώσει, είστε μόνο στα μισά του δρόμου.

Συνεχίζει με το νόμο του Hofstadter:

"Πάντα παίρνει περισσότερο από ό, τι περιμένετε, ακόμα και αν λάβετε υπόψη το νόμο του Hofstadter."

9. Νόμος του Πάρκινσον

"Η εργασία διευρύνεται για να γεμίσει ο διαθέσιμος χρόνος για την ολοκλήρωσή της."

Αυτή η μία αρχή, που επινοήθηκε από τον Cyril Northcote Parkinson, είναι μια ευρύτερη αρχή που εφαρμόζεται απολύτως στον προγραμματισμό και πηγαίνει χέρι-χέρι με τον Ενενήντα Ενενήντα Κανόνα παραπάνω: όσο καιρό θα πρέπει να ολοκληρώσετε ένα έργο είναι ακριβώς πόσο καιρό πρόκειται να παίρνω. Στην ανάπτυξη λογισμικού, το "φινίρισμα νωρίς" είναι λίγο πολύ μύθος.

Ο νόμος του Parkinson είναι ο λόγος για τον οποίο οι σωστές προθεσμίες είναι ζωτικής σημασίας εάν θέλετε να ολοκληρώσετε και να στείλετε το λογισμικό σας. Αυτός είναι ο λόγος που οι σύγχρονοι επαγγελματίες προγραμματιστές συχνά συνιστούν ευέλικτες αρχές διαχείρισης έργων Πώς να χρησιμοποιήσετε τις αρχές διαχείρισης του προγράμματος Agile για να οργανώσετε τη ζωή σαςΤο Agile, γνωστό ως μέθοδος διαχείρισης έργου, είναι ένα μεγάλο πλαίσιο για τη διαχείριση της προσωπικής σας ζωής. Θα σας δείξουμε ποιες αρχές μπορείτε να δανειστείτε - δωρεάν download φύλλο εργασίας περιλαμβάνονται! Διαβάστε περισσότερα και εργαλεία διαχείρισης έργων όπως η Asana Trello εναντίον Asana: Το καλύτερο δωρεάν εργαλείο διαχείρισης έργων είναι ...Η επιλογή μεταξύ Trello και Asana είναι δύσκολη. Εδώ συγκρίνουμε τα δωρεάν σχέδια και σας βοηθήσουμε να αποφασίσετε ποιο εργαλείο διαχείρισης έργων είναι το καλύτερο για την ομάδα σας. Διαβάστε περισσότερα .

10. Νόμος του Μπρουκ

"Η προσθήκη ανθρώπινου δυναμικού σε ένα πρόσφατο έργο λογισμικού το καθιστά αργότερα."

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

Στην πραγματικότητα, πιθανότατα θα πάρει μακρύτερα να ολοκληρωσω. Όχι μόνο θα πρέπει να φέρετε τον νέο κωδικοποιητή (ες) σε ταχύτητα, πιθανότατα θα έρθουν σε σύγκρουση με τους υπάρχοντες κωδικοποιητές. Θα χρειαστεί να τεκμηριωθούν περισσότερα πράγματα, θα χρειαστεί περισσότερη γραφειοκρατία για να κρατηθεί ο καθένας στην ίδια σελίδα και περισσότερη τριβή θα βγει από όλη την εμπειρία της κρίσης.

Προχωρώντας ως Προγραμματιστής

Τώρα που γνωρίζετε αυτές τις αρχές, είστε στην πραγματικότητα καλύτερα για την πραγματικό κόσμο του προγραμματισμού, όχι μόνο αυτό που συναντήσατε στο σχολείο, σε ένα web course ή σε ένα bootcamp. Αυτές οι αρχές προέρχονται από χρόνια και χρόνια εμπειρίας και αποτυχίες.

Με αυτή τη νέα σοφία, μπορείτε τώρα να προχωρήσετε σε μια υψηλής σταδιοδρομίας προγραμματισμού 10 Θέσεις Προγραμματισμού Υπολογιστών που είναι στη Ζήτηση Right NowΔεδομένου ότι η προσγείωση μιας εργασίας προγραμματισμού μπορεί να είναι δύσκολη στο σημερινό τοπίο, σκεφτείτε να εστιάσετε σε μία από τις παρακάτω συγκεντρώσεις για να βελτιώσετε τις πιθανότητες επιτυχίας σας. Διαβάστε περισσότερα με πιο ρεαλιστικές προσδοκίες. Γι 'αυτό, μάθετε πώς να μεγιστοποιήστε τις ευκαιρίες σταδιοδρομίας προγραμματισμού Πώς να βελτιώσετε τις προοπτικές καριέρας στον προγραμματισμό σαςΑν ελπίζετε να ξεκινήσετε, να επανεκκινήσετε ή να βελτιώσετε με άλλο τρόπο την καριέρα προγραμματισμού, δεν είναι εύκολο. Αν είστε στο κολέγιο, ο χρόνος είναι τώρα. Εδώ είναι μερικές συμβουλές που μπορεί να σας πάρει μακριά. Διαβάστε περισσότερα . Και αν αποφασίσετε ότι ο προγραμματισμός δεν είναι για σας, μην ανησυχείτε - σκεφτείτε ένα από αυτά μη-κωδικοποίηση τεχνικών εργασιών αντί Κωδικοποίηση δεν είναι για όλους: 9 Τεχνικές θέσεις εργασίας μπορείτε να πάρετε χωρίς αυτόΜην αποθαρρύνεστε εάν θέλετε να είστε μέρος του τομέα τεχνολογίας. Υπάρχουν πολλές θέσεις εργασίας για άτομα χωρίς κωδικοποίηση δεξιοτήτων! Διαβάστε περισσότερα .

Ποιες από αυτές τις αρχές σας δακτυλίουν περισσότερο; Γνωρίζετε τις άλλες περίεργες αρχές προγραμματισμού που χάσαμε; Ενημερώστε μας στα παρακάτω σχόλια!