«Πάντα να κλείνεις» Το σκληρό μάντρα των πωλήσεων από Με το ίδιο πνεύμα (αλλά με πολύ λιγότερους όρκους), ένας καλός μηχανικός θα πρέπει να Εδώ είναι γιατί. Γκλεν Ρος Γκλεν Ρος Πάντα αναζωογονητικός Να καθαρίσει ή να μην καθαρίσει Είναι γενικά αποδεκτό ότι ο καθαρός κώδικας είναι ευκολότερος στην κατανόηση, φθηνότερος στη συντήρηση και πολύ πιο επεκτάσιμος. A common objection to refactoring is that there isn’t time to actually do it. Teams see it as a luxury. The relentless drive for new features simply doesn’t allow for refactoring, especially because refactoring changes nothing from an external point of view. That can be a hard sell to your product owner. But clean code makes your life easier. Clean code pays for itself and slows the accumulation of technical debt. So sneak it in. That’s right. I’m suggesting a slight bit of subterfuge. A little misdirection even. Why not clean up a few things in every pull request? Να είστε σε επιφυλακή Ένας καλός μηχανικός έχει ένα όραμα για το πού θα πρέπει να κατευθύνεται η βάση κώδικα. μπορεί να χρειαστεί κάποιο χρονικό διάστημα για να φτάσετε εκεί, αλλά γνωρίζετε τα ακατέργαστα μέρη, το κενό, τον οδικό χάρτη, το τεχνικό χρέος, τις τρύπες ασφαλείας και τα κενά τεκμηρίωσης. As you go about your regular feature development, be on the lookout for refactorings that can advance your larger agenda. Like one of those hyper-observant TV show detectives surveying a crime scene, pay close attention to all the code you stumble across. Όταν παρατηρήσετε μια μυρωδιά κώδικα ή κάτι ελαφρώς μακριά από την τρέχουσα εστίαση σας, οι καμπάνες συναγερμού θα πρέπει να σβήσουν: Πάρτε μερικά λεπτά και να το διορθώσετε τώρα, πριν η έμπνευση εξαφανιστεί. “Don’t let this opportunity pass!” Don’t say it’s not your problem. Don’t pretend you can unsee it. Just roll up your sleeves and get it done. Ένα απλό παράδειγμα Η αναπαραγωγή δεν σημαίνει απαραίτητα την αλλαγή χιλιάδων γραμμών κώδικα. Μπορεί να είναι μόνο ένα μικρό κομμάτι κώδικα εδώ και εκεί. Αυτές οι μικρές μικρο-αναπαραγωγές προστίθενται με την πάροδο του χρόνου. To illustrate micro-refactoring, let’s look at an “extract method” Golang example. Ας υποθέσουμε ότι αντιμετωπίζετε μια λειτουργία που απαιτεί να γνωρίζετε πόσες ημέρες έχουν περάσει από τότε που ένας χρήστης συνδέθηκε τελευταία φορά. func IsDormant(user User, asOf time.Time) bool { days := int(asOf.Sub(user.LastLogin).Hours() / 24) return days >= 8 } Θέλετε να επαναχρησιμοποιήσετε τον τελευταίο υπολογισμό σύνδεσης αντί να τον αντιγράψετε και να τον επικολλήσετε, οπότε παίρνετε την εσωτερική μεταβλητή, , και να το εξαγάγει σε ξεχωριστή μέθοδο, : days DaysSinceLastLogin func IsDormant(user User, asOf time.Time) bool { return DaysSinceLastLogin(user, asOf) >= 8 } func DaysSinceLastLogin(user User, asOf time.Time) int { return int(asOf.Sub(user.LastLogin).Hours() / 24) } Αυτό επιτρέπει να δοκιμαστεί και να επαναχρησιμοποιηθεί η τελευταία λογική σύνδεσης.Αν γράψετε μια δοκιμή μονάδας, θα εντοπίσετε μια περίπτωση άκρης που πρέπει να αντιμετωπιστεί (ενδεχόμενο πανικού εάν ένας χρήστης δεν έχει συνδεθεί ποτέ). Επίσης, διευκολύνει τις μελλοντικές βελτιώσεις. για παράδειγμα, μπορεί να έχει νόημα να κάνετε και methods on the αντί να είναι αυτόνομη. Ομοίως, σκεφτείτε να αντικαταστήσετε την τιμή σκληρού κώδικα Κάτι πιο περιγραφικό, όπως . IsDormant DaysSinceLastLogin User 8 DormantDaysThreshold This is a simple example, just a few lines of code. But that’s the beauty. It shows a small refactoring can add value by revealing a potential bug and pointing towards future improvements. Για να μάθετε περισσότερα σχετικά με την τέχνη της αναπαραγωγής και να δείτε όλους τους μικρούς τρόπους για να βελτιώσετε τον κώδικα σας, ρίξτε μια ματιά σε online πόρους όπως ο κατάλογος αναπαραγωγής από το βιβλίο του Martin Fowler ή το Refactoring Guru. Αναδημοσίευση καταλόγου Επανασχεδιασμός Guru Επανασχηματισμός της σκέψης Έχοντας ένα όραμα για τη βάση κώδικα σας είναι εύκολο. Το να γνωρίζετε πώς να το πάρετε εκεί είναι πιο δύσκολο. Η ανίχνευση ευκαιριών αναπαραγωγής απαιτεί πρακτική. Ένας τρόπος για να ξεκινήσετε είναι να εξετάσετε ποιες κατηγορίες αναπαραγωγής είναι απαραίτητες για να μετατρέψετε τον κώδικα σας. Εδώ είναι μερικά κοινά θέματα αναπαραγωγής για να σκεφτούμε: - Καταρρέει αντίγραφο και επικολλήθηκε λογική σε μια ενιαία λειτουργία. 🧹 Remove Duplication 🧰 — Move common logic out of per-service implementations. Normalize integrations (e.g., all services use the same auth client). Extract Shared Utility or Library 🧱 — Εισάγετε παρατηρήσιμη (ημερολόγηση, ιχνηλασιμότητα, μετρήσεις). Κεντρική επεξεργασία σφαλμάτων ή επαναλήψεις. Add Common Infrastructure ️ Αποσυνδέστε τις διεπαφές έτσι ώστε οι εξαρτήσεις να μπορούν να κοροϊδεύονται ή να κοροϊδεύονται. Make Code More Testable Πλαστά σύνθετα όρια ή ενσωματωμένη λογική.Αναδιοργανώστε τα αρχεία ή τις τάξεις για να ταιριάζουν σε νέες ευθύνες. Prepare for a Feature Change 🏗️ — Break apart a monolith. Introduce event-driven patterns, dependency injection, or async processing. Support a New Architecture 🚦 Διαιρέστε γιγαντιαία αρχεία ή τάξεις σε λογικές, εστιασμένες μονάδες. Reduce Cognitive Load Refactor μη ασφαλή μοτίβα (π.χ., χειροκίνητη σύγκλιση SQL → παραμετροποιημένα ερωτήματα). Improve Security or Compliance — Αντικαταστήστε τους αφελείς αλγόριθμους με βελτιστοποιημένους αλγόριθμους. Improve Performance 👥 - Refactor code που μόνο ο "Pat" καταλαβαίνει σε κάτι που μπορεί να διαβαστεί από την ομάδα. Ease Onboarding or Handoff The 20% Ας εφαρμόσουμε τον κανόνα 80-20 και να ορίσουμε ότι το 20% των αναπαραγωγών πρέπει να γίνει στο up-and-up. Αυτά θα πρέπει να είναι μια ευκολότερη πώληση, ωστόσο, επειδή όταν φτάσετε στο σημείο όπου χρειάζεστε ένα πλήρες, ειλικρινές προς το καλό αναπαραγωγός, σίγουρα θα είναι στην υπηρεσία κάποιου μεγαλύτερου στόχου. Για παράδειγμα, πριν εργαστείτε σε ένα εισιτήριο βελτίωσης της απόδοσης, πρέπει πρώτα να προσθέσετε ιχνηλασιμότητα και μετρήσεις, ώστε να μπορείτε να αναπτύξετε μια πιο λεπτή εικόνα της τρέχουσας απόδοσης και να προσδιορίσετε τα hotspots. Η ανανέωση ξεκινά με τη δοκιμή Είναι πιθανότατα αυτονόητο, αλλά πρέπει να επισημάνω ότι η αναπαραγωγή είναι πολύ πιο εύκολη (και λιγότερο νευρική) εάν η βάση κώδικα σας έχει μια συνοδευτική σειρά δοκιμών που περνούν πριν και μετά την αναπαραγωγή. Εάν το έργο σας δεν έχει ισχυρές δοκιμές, προσθέστε πρώτα μερικές δοκιμές για να ξεκλειδώσετε μελλοντικές αναπαραγωγές. Αρκετοί άλλοι λόγοι Κωδικός Αναθεώρησης Σκέψεις Η συμβουλή μου σε αυτό το άρθρο έρχεται σε αντίθεση με την τυπική κατευθυντήρια γραμμή να μην αναμειγνύεται η εργασία αναδιαμόρφωσης με την κανονική ανάπτυξη χαρακτηριστικών. Η αντίρρηση είναι ότι καθιστά πιο δύσκολο για την ομάδα να κάνει αναθεωρήσεις κώδικα εάν περιλαμβάνονται μη σχετικές αλλαγές. Ένας καλός κανόνας για οποιοδήποτε αίτημα έλξης είναι να περιοριστεί σε 500 γραμμές αλλαγών κώδικα. Ένας δεύτερος κανόνας είναι ότι οι βοηθητικές αλλαγές αναδιαμόρφωσης δεν πρέπει να υπερβαίνουν το 20% του PR. Όταν έχετε αφιερωμένη αναπαραγωγή PRs, κρατήστε το επικεντρωμένο και γύρω από αυτό το μέγεθος. Μερικές φορές μια PR πρέπει να είναι μεγαλύτερη από 500 γραμμές κώδικα, ειδικά όταν εργάζεστε σε ένα repo-wide refactor. Σε αυτές τις περιπτώσεις, συντονιστείτε καλά με τους συναδέλφους σας για να τους προετοιμάσετε για την αλλαγή και να ελαχιστοποιήσετε συγκρούσεις συγχώνευσης. Κάθε δέσμευση μετράει Κάθε φορά που αγγίζετε τη βάση κώδικα, έχετε μια επιλογή: αφήστε το λίγο καλύτερα ή αφήστε το λίγο χειρότερο. Η αναδιαμόρφωση δεν χρειάζεται να είναι ένα μεγάλο γεγονός. Μικρές βελτιώσεις (εξαγωγή μεθόδων, μετονομασία συγκεχυμένων μεταβλητών, διάσπαση μεγάλων μεθόδων κ.λπ.) προστίθενται με την πάροδο του χρόνου. Αν δείτε κάτι, διορθώστε κάτι. Πάντα να επαναπροσδιορίζεσαι!
