Οι καλοί προγραμματιστές είναι πάντα αναπαραγωγικοί

«Πάντα να κλείνεις»

Το σκληρό μάντρα των πωλήσεων απόΓκλεν Ρος Γκλεν ΡοςΜε το ίδιο πνεύμα (αλλά με πολύ λιγότερους όρκους), ένας καλός μηχανικός θα πρέπει ναΠάντα αναζωογονητικόςΕδώ είναι γιατί.

Να καθαρίσει ή να μην καθαρίσει

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

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)
}

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

Επίσης, διευκολύνει τις μελλοντικές βελτιώσεις. για παράδειγμα, μπορεί να έχει νόημα να κάνετεIsDormantκαιDaysSinceLastLogin methods on the 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.

Επανασχηματισμός της σκέψης

Έχοντας ένα όραμα για τη βάση κώδικα σας είναι εύκολο. Το να γνωρίζετε πώς να το πάρετε εκεί είναι πιο δύσκολο. Η ανίχνευση ευκαιριών αναπαραγωγής απαιτεί πρακτική. Ένας τρόπος για να ξεκινήσετε είναι να εξετάσετε ποιες κατηγορίες αναπαραγωγής είναι απαραίτητες για να μετατρέψετε τον κώδικα σας.

Εδώ είναι μερικά κοινά θέματα αναπαραγωγής για να σκεφτούμε:

🧹 Remove Duplication- Καταρρέει αντίγραφο και επικολλήθηκε λογική σε μια ενιαία λειτουργία.

🧰 Extract Shared Utility or Library — Move common logic out of per-service implementations. Normalize integrations (e.g., all services use the same auth client).

🧱 Add Common Infrastructure— Εισάγετε παρατηρήσιμη (ημερολόγηση, ιχνηλασιμότητα, μετρήσεις). Κεντρική επεξεργασία σφαλμάτων ή επαναλήψεις.

️Make Code More TestableΑποσυνδέστε τις διεπαφές έτσι ώστε οι εξαρτήσεις να μπορούν να κοροϊδεύονται ή να κοροϊδεύονται.

Prepare for a Feature ChangeΠλαστά σύνθετα όρια ή ενσωματωμένη λογική.Αναδιοργανώστε τα αρχεία ή τις τάξεις για να ταιριάζουν σε νέες ευθύνες.

🏗️ Support a New Architecture — Break apart a monolith. Introduce event-driven patterns, dependency injection, or async processing.

🚦 Reduce Cognitive LoadΔιαιρέστε γιγαντιαία αρχεία ή τάξεις σε λογικές, εστιασμένες μονάδες.

Improve Security or ComplianceRefactor μη ασφαλή μοτίβα (π.χ., χειροκίνητη σύγκλιση SQL → παραμετροποιημένα ερωτήματα).

Improve Performance— Αντικαταστήστε τους αφελείς αλγόριθμους με βελτιστοποιημένους αλγόριθμους.

👥 Ease Onboarding or Handoff- Refactor code που μόνο ο "Pat" καταλαβαίνει σε κάτι που μπορεί να διαβαστεί από την ομάδα.

The 20%

Ας εφαρμόσουμε τον κανόνα 80-20 και να ορίσουμε ότι το 20% των αναπαραγωγών πρέπει να γίνει στο up-and-up.

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

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

Η ανανέωση ξεκινά με τη δοκιμή

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

Κωδικός Αναθεώρησης Σκέψεις

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

Ένας καλός κανόνας για οποιοδήποτε αίτημα έλξης είναι να περιοριστεί σε 500 γραμμές αλλαγών κώδικα. Ένας δεύτερος κανόνας είναι ότι οι βοηθητικές αλλαγές αναδιαμόρφωσης δεν πρέπει να υπερβαίνουν το 20% του PR.

Όταν έχετε αφιερωμένη αναπαραγωγή PRs, κρατήστε το επικεντρωμένο και γύρω από αυτό το μέγεθος. Μερικές φορές μια PR πρέπει να είναι μεγαλύτερη από 500 γραμμές κώδικα, ειδικά όταν εργάζεστε σε ένα repo-wide refactor. Σε αυτές τις περιπτώσεις, συντονιστείτε καλά με τους συναδέλφους σας για να τους προετοιμάσετε για την αλλαγή και να ελαχιστοποιήσετε συγκρούσεις συγχώνευσης.

Κάθε δέσμευση μετράει

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

Αν δείτε κάτι, διορθώστε κάτι.

Πάντα να επαναπροσδιορίζεσαι!