Πρόλογος του μεταφραστή: Αφού διαβάσετε αυτό το άρθρο, μπορεί να εκπλαγείτε ή ακόμα και να θυμώσετε. Ναι, και εμείς εκπλαγήκαμε: ο συγγραφέας υποτίθεται ότι δεν είχε ακούσει ποτέ για την ιεραρχία στην ομάδα, για τον καθορισμό εργασιών με την κατάσταση "κάντε το γρήγορα και χωρίς αιτιολογία". Ναι, έτσι είναι, αυτό είναι λίγο περίεργο κείμενο. Πράγματι, ο συγγραφέας προτείνει στον προγραμματιστή να αναλάβει το ρόλο ενός αρχιτέκτονα συστήματος - γιατί τότε χρειάζεστε έναν αρχιτέκτονα; Αλλά όλες αυτές οι αντιρρήσεις δεν πρέπει να σας τυφλώνουν στο κύριο πράγμα - γιατί παρόλα αυτά πήραμε και μεταφράσαμε αυτό το κείμενο. Δεν μιλάει για ρόλους. Αυτό το κείμενο αφορά μια επαγγελματική προσέγγιση και ευαισθητοποίηση. Η αλήθεια είναι ότι όσο «κάνεις αυτό που σου λένε» χωρίς να σκέφτεσαι το νόημα των πράξεών σου, δεν θα γίνεις ποτέ σπουδαίος προγραμματιστής.
Πείτε όχι σε περιττό κώδικα. Το μόνο που έχετε να κάνετε είναι να ενώσετε τρία γράμματα και να πείτε τη λέξη. Ας προσπαθήσουμε να το κάνουμε αυτό μαζί: "Όχι!"
Αλλά περίμενε. Γιατί το κάνουμε αυτό; Εξάλλου, το κύριο καθήκον ενός προγραμματιστή είναι να γράφει κώδικα. Χρειάζεται όμως να γράψετε κάποιον κωδικό που σας ζητείται; Οχι! "Η κατανόηση του πότε δεν πρέπει να γράφετε κώδικα είναι ίσως η πιο σημαντική ικανότητα για έναν προγραμματιστή." .
Υπενθύμιση: για όλους τους αναγνώστες του "Habr" - έκπτωση 10 ρούβλια κατά την εγγραφή σε οποιοδήποτε μάθημα Skillbox χρησιμοποιώντας τον κωδικό προσφοράς "Habr".
Το Skillbox προτείνει: Πρακτικό μάθημα .
Ο προγραμματισμός είναι η τέχνη της επίλυσης προβλημάτων. Και είστε κύριοι αυτής της τέχνης.
Μερικές φορές, σε μια προσπάθεια να ξεκινήσουμε τη δουλειά όσο το δυνατόν γρηγορότερα, δεν σκεφτόμαστε τίποτα άλλο από το να ολοκληρώσουμε την εργασία που έχουμε. Και αυτό μπορεί να προκαλέσει ακόμη πιο σοβαρά προβλήματα.
Σε τι κάνουν τα στραβά μάτια οι προγραμματιστές;
Όλος ο κώδικας που γράφετε πρέπει να είναι κατανοητός από άλλους προγραμματιστές και πρέπει να ελεγχθεί και να διορθωθεί.
Αλλά υπάρχει ένα πρόβλημα: ό,τι και να γράψετε, θα περιπλέξει το λογισμικό σας και πιθανότατα θα παρουσιάσει σφάλματα στο μέλλον.
Σύμφωνα με τον Rich Skrent, . Να τι γράφει:
«Ο κώδικας είναι κακός γιατί αρχίζει να σαπίζει και απαιτεί συνεχή συντήρηση. Η προσθήκη νέων χαρακτηριστικών απαιτεί συχνά την τροποποίηση του παλιού κώδικα. Όσο μεγαλύτερο είναι, τόσο μεγαλύτερη είναι η πιθανότητα εμφάνισης σφάλματος και τόσο περισσότερος χρόνος χρειάζεται για τη μεταγλώττιση. Χρειάζεται περισσότερος χρόνος από έναν άλλο προγραμματιστή για να το καταλάβει. Και αν χρειαστεί ανακατασκευή, τότε σίγουρα θα υπάρχουν θραύσματα που αξίζει να αλλάξουν. Ο μεγάλος κώδικας συχνά σημαίνει μειωμένη ευελιξία και λειτουργικότητα του έργου. Μια απλή και κομψή λύση είναι πιο γρήγορη από τον πολύπλοκο κώδικα.»
Πώς ξέρετε πότε δεν πρέπει να γράφετε κώδικα;
Το πρόβλημα είναι ότι οι προγραμματιστές συχνά υπερβάλλουν τον αριθμό των δυνατοτήτων που χρειάζονται οι εφαρμογές τους. Ως αποτέλεσμα, πολλά τμήματα κώδικα παραμένουν ημιτελή ή κανείς δεν τα χρησιμοποιεί, αλλά περιπλέκουν την εφαρμογή.
Πρέπει να κατανοήσετε ξεκάθαρα τι χρειάζεται το έργο σας και τι όχι.
Ένα παράδειγμα είναι μια εφαρμογή που επιλύει μόνο μία εργασία - τη διαχείριση email. Για το σκοπό αυτό, έχουν εισαχθεί δύο λειτουργίες - αποστολή και λήψη επιστολών. Δεν πρέπει να περιμένετε από τον διαχειριστή αλληλογραφίας να γίνει ταυτόχρονα διαχειριστής εργασιών.
Πρέπει να πείτε σταθερά «όχι» σε προτάσεις για να προσθέσετε λειτουργίες που δεν σχετίζονται με την κύρια εργασία της εφαρμογής. Αυτή είναι ακριβώς η στιγμή που γίνεται σαφές ότι δεν χρειάζεται πρόσθετος κωδικός.
Μην χάνετε ποτέ την εστίαση της εφαρμογής σας.
Πάντα να ρωτάτε τον εαυτό σας:
— Ποια λειτουργία πρέπει να εφαρμοστεί τώρα;
— Τι κωδικό να γράψω;
Αμφισβητήστε τις ιδέες που σας έρχονται στο μυαλό και αξιολογήστε τις προτάσεις που προέρχονται από το εξωτερικό. Διαφορετικά, ο επιπλέον κώδικας μπορεί απλά να σκοτώσει το έργο.
Γνωρίζοντας πότε δεν πρέπει να προσθέτετε περιττά πράγματα θα σας βοηθήσει να διατηρήσετε τη βάση του κώδικα υπό σταθερό έλεγχο.
Στην αρχή της διαδρομής, ο προγραμματιστής έχει μόνο δύο ή τρία αρχεία πηγής. Είναι απλό. Η μεταγλώττιση και η εκκίνηση της εφαρμογής απαιτεί ελάχιστο χρόνο. Είναι πάντα σαφές πού και τι να αναζητήσετε.
Καθώς η εφαρμογή επεκτείνεται, εμφανίζονται όλο και περισσότερα αρχεία κώδικα. Γεμίζουν τον κατάλογο, το καθένα με εκατοντάδες γραμμές. Για να τα οργανώσετε σωστά όλα αυτά, θα πρέπει να δημιουργήσετε επιπλέον καταλόγους. Ταυτόχρονα, το να θυμόμαστε ποιες λειτουργίες είναι υπεύθυνες για το τι και ποιες ενέργειες τις προκαλούν γίνεται όλο και πιο δύσκολο. Η σύλληψη σφαλμάτων απαιτεί επίσης περισσότερο χρόνο. Η διαχείριση έργου γίνεται επίσης πιο περίπλοκη· δεν απαιτείται ένας, αλλά πολλοί προγραμματιστές να παρακολουθούν τα πάντα. Αντίστοιχα, τα κόστη, τόσο χρηματικά όσο και χρονικά, αυξάνονται και η διαδικασία ανάπτυξης επιβραδύνεται.
Το έργο τελικά γίνεται τεράστιο και η προσθήκη κάθε νέας δυνατότητας απαιτεί όλο και περισσότερη προσπάθεια. Ακόμα και για κάτι πολύ ασήμαντο πρέπει να αφιερώσεις αρκετές ώρες. Η διόρθωση υπαρχόντων σφαλμάτων οδηγεί στην εμφάνιση νέων και χάνονται οι προθεσμίες έκδοσης εφαρμογών.
Τώρα πρέπει να παλέψουμε για τη ζωή του έργου. Γιατί;
Το γεγονός είναι ότι απλά δεν καταλάβατε πότε δεν πρέπει να προσθέσετε επιπλέον κώδικα και απαντήσατε «ναι» σε κάθε πρόταση και ιδέα. Ήσουν τυφλός, η επιθυμία να δημιουργήσεις νέα πράγματα σε έκανε να αγνοήσεις σημαντικά γεγονότα.
Ακούγεται σαν σενάριο ταινίας τρόμου, σωστά;
Αυτό ακριβώς θα συμβεί αν συνεχίσετε να λέτε ναι. Προσπαθήστε να καταλάβετε πότε δεν πρέπει να προστεθεί κώδικας. Αφαιρέστε τα περιττά πράγματα από το έργο - αυτό θα κάνει τη ζωή σας πολύ πιο εύκολη και θα παρατείνει τη διάρκεια ζωής της εφαρμογής.
«Μία από τις πιο παραγωγικές μέρες μου ήταν όταν διέγραψα 1000 γραμμές κώδικα».
— Κεν Τόμσον.
Είναι δύσκολο να μάθετε πότε να μην γράφετε κώδικα. Είναι όμως απαραίτητο.
Ναι, ξέρω ότι μόλις ξεκινήσατε την πορεία ενός προγραμματιστή και θέλετε να γράψετε κώδικα. Είναι καλό, μην χάνετε αυτή την πρώτη εντύπωση, αλλά μην χάνετε από τα μάτια σας σημαντικούς παράγοντες λόγω ενθουσιασμού. Καταλάβαμε τα πάντα μέσω δοκιμής και λάθους. Θα κάνετε επίσης λάθη και θα μάθετε από αυτά. Αλλά αν μπορείτε να μάθετε από τα παραπάνω, η δουλειά σας θα γίνει πιο συνειδητή.
Συνεχίστε να δημιουργείτε, αλλά να ξέρετε πότε να πείτε όχι.
Το Skillbox προτείνει:
- Εφαρμοσμένο διαδικτυακό μάθημα .
- Διαδικτυακό μάθημα .
- Πρακτικό μάθημα έτους .
Πηγή: www.habr.com