Χρησιμοποιώντας το SwiftLint και το Danger για τις βέλτιστες πρακτικές Swift

Αυτή η ανάρτηση εμφανίστηκε αρχικά στο Swift Post, διαθέσιμο εδώ.

Το Swift της Apple γίνεται όλο και πιο δημοφιλές μεταξύ της κοινότητας προγραμματιστών. Οι περισσότεροι από εμάς έχουν ήδη αρχίσει να προσαρμόζουν τα έργα μας σε αυτό το λαϊκό. Ενώ υιοθετούμε, ίσως να μην είμαστε τόσο προσεκτικοί όσο θα έπρεπε να είμαστε όσο το Swift είναι μια πολύ ευέλικτη γλώσσα και είναι πραγματικά εύκολο να το κακοποιήσουμε. Ειδικά από μια κουλτούρα του Στόχου-Γ, η εφαρμογή βέλτιστων πρακτικών καθίσταται πραγματικά σημαντική.

Μετά την ανάγνωση Swifty Συμβουλές από Göksel, συνειδητοποίησα ότι μερικές από τις συμβουλές του μπορούν να ελεγχθούν αυτόματα με το SwiftLint. Επίσης, είμαστε τεμπέληδες και έχουμε την τάση να ξεχνάμε να ελέγξουμε τον κώδικα μας πριν συγχωνευθούμε για master. Ακριβώς εδώ, ο Κίνδυνος έρχεται στη σκηνή με γυαλιστερά ρούχα και επισημαίνει ότι κάνουμε κάτι επικίνδυνο.

Ακούγεται ενδιαφέρον ..? Αλλά τι είναι αυτά τα εργαλεία, στην πραγματικότητα;

SwiftLint

Το SwiftLint είναι ένα εργαλείο ανοιχτού κώδικα για την επιβολή του στυλ Swift και των συμβάσεων. Αναπτύσσεται από το Realm. Μπορείτε να ρυθμίσετε τους κανόνες στυλ κωδικοποίησης και να τους πιέσετε κατά τη διάρκεια της ανάπτυξης. Το SwiftLint διαθέτει ένα εργαλείο γραμμής εντολών, το plugin Xcode, το AppCode και την ενσωμάτωση Atom. Έτσι, ταιριάζει πάντα στο αναπτυξιακό σας περιβάλλον. Θα σας δείξει προειδοποιήσεις και / ή σφάλματα αν παραβιάσετε τους κανόνες χαλάρωσης.

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

Ας ρίξουμε μια ματιά στις συμβουλές του Göksel. Λέει, "Ποτέ μην χρησιμοποιείτε σιωπηρά αναδιπλώνονται προαιρετικά". Το SwiftLint παρέχει αυτό από προεπιλογή ακριβώς πώς περιγράφει. Το SwiftLint θα σας προειδοποιήσει όταν αναπτύξετε σιωπηρά ένα προαιρετικό εκτός αν είναι το IBOutlet. Το άλλο είναι "Αποφυγή κακής χρήσης". Το SwiftLint είναι αρκετά έξυπνο για να επισημάνει όταν δεν χρησιμοποιείτε τα δεσμευμένα προαιρετικά σας.

αν αφήσουμε _ = Foo.optionalValue {} // Δακτύλιοι μια προειδοποίηση
σε περίπτωση .some (let _) = self {} // Ενεργοποιεί μια προειδοποίηση
if foo () {let _ = bar ()} // Δεν ενεργοποιεί προειδοποίηση
αν foo () {_ = bar ()} // Δεν ενεργοποιεί προειδοποίηση

Εκτός από την εφαρμογή των βέλτιστων πρακτικών μεμονωμένα, θέλουμε να κάνουμε τον κώδικα βάσης συνεπή. Διευκολύνετε την εφαρμογή των προσαρμοσμένων κανόνων. Ωστόσο, αυτοί οι κανόνες πρέπει να ανταποκρίνονται στις βέλτιστες πρακτικές. Η διαμόρφωση του στίγματος γίνεται από το αρχείο .swiftlint.yml. Αυτό το αρχείο βρίσκεται στην κύρια διαδρομή του έργου. Μπορούμε να ενεργοποιήσουμε, να απενεργοποιήσουμε ή να γράψουμε ειδικούς κανόνες σε αυτό το αρχείο YML. Ας ρίξουμε μια ματιά σε μερικά παραδείγματα.

Πρώτα πράγματα πρώτα, γράφοντας μια μεγάλη λειτουργία είναι γενικά ένα κακό σημάδι. Εάν η λειτουργία σας γίνεται όλο και μεγαλύτερη, αυτό σημαίνει ότι πρέπει να χωρίσετε την ευθύνη. Προσθέστε το ακόλουθο κομμάτι κώδικα στο αρχείο .swiftlint.yml. Αυτό προειδοποιεί τους προγραμματιστές να έχουν λειτουργίες κάτω των 200 γραμμών. Εάν ο προγραμματιστής φτάσει τα 300, το SwiftLint δημιουργεί ένα σφάλμα. Θυμηθείτε, μπορείτε να αγνοήσετε τις προειδοποιήσεις αλλά όχι τα σφάλματα.

function_body_length:
 - 200 # προειδοποίηση
 - 300 # σφάλμα

Σχεδόν κάθε έργο έχει εξαρτήσεις ή κομμάτια κώδικα που δεν είναι δυνατό να αλλάξουν. Αυτά τα τεμάχια κώδικα δεν θα πρέπει να παραμείνουν καθόλου. Για παράδειγμα, εάν ένα έργο χρησιμοποιεί το CocoaPods ως διαχειριστής εξάρτησης, θα έχει φάκελο Pods που θα διατηρεί όλα τα αρχεία εξάρτησης. Πρέπει να αποκλείσουμε αυτό το φάκελο από τη διαδικασία χαλάρωσης. Όπως μπορείτε να δείτε παρακάτω, είναι τόσο εύκολο.

εξαιρούνται:
  - Pods

Οποιεσδήποτε οδηγίες εταιρείας ή προγραμματιστής που εργάζεται στο έργο έχει ένα στυλ κωδικοποίησης. Το SwiftLint βοηθά τους νεοεισερχόμενους να υιοθετήσουν αυτά τα στυλ κατά τη διάρκεια της διαδικασίας επιβίβασης.

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

Προσθέστε αυτό το σχόλιο για να απενεργοποιήσετε τον κανόνα του αρχείου:

// swiftlint: απενεργοποίηση ονόματος_αρχείου

Προσθέστε αυτό το σχόλιο για να απενεργοποιήσετε τον κανόνα στην παρακάτω γραμμή:

// swiftlint: απενεργοποίηση: επόμενο όνομα_αρχείου

Προσθέστε αυτό το σχόλιο για να απενεργοποιήσετε τον κανόνα στην προηγούμενη γραμμή:

// swiftlint: απενεργοποίηση: προηγούμενο όνομα_αρχείου

Μπορείτε να πάρετε τη λίστα με όλους τους κανόνες εκτελώντας την εντολή swiftlint rules στο τερματικό.

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

P .: Μπορείτε να βρείτε το προκαθορισμένο αρχείο .swiftlint.yml εδώ.

Κίνδυνος ️

Κάθε έργο / κομμάτι κώδικα έχει τη δική του συγκεκριμένη ροή. Όταν το έργο μεγαλώνει, η συντήρηση και η προσθήκη νέων χαρακτηριστικών γίνεται πιο δύσκολη. Το επιρρεπή σφάλμα αυξάνεται. Η κατοχύρωση των οδηγιών για την κωδικοποίηση και η εφαρμογή βέλτιστων πρακτικών δεν επαρκούν γενικά. Είμαστε άνθρωποι, κάνουμε λάθη. Ο κίνδυνος μπορεί να εντοπίσει βασικά σφάλματα και ας σκεφτούμε τα δυσκολότερα προβλήματα. Για παράδειγμα, μπορεί να εντοπίσει κοινά τυπογραφικά λάθη ή να δημιουργήσει αλλαγές αρχείων που δεν πρέπει να αλλάξετε μόνοι σας. Μπορεί επίσης να σας αναγκάσει να γράψετε δοκιμές εάν γράψετε περισσότερες από 20 γραμμές κώδικα. Οι κανόνες είναι στα χέρια σου το ίδιο με το SwiftLint.

Ο κίνδυνος είναι ένα διαμάντι Ruby το οποίο τρέχει στο CI κατά τη διάρκεια της διαδικασίας αίτησης έλξης / συγχώνευσης. Αφήνει μηνύματα, σχόλια ή ακόμη και αποτυγχάνει να δημιουργήσει το CI σας όταν παραβιάζονται οι κανόνες σας. Ο κίνδυνος μπορεί να τρέξει σε πολλά εργαλεία CI και μπορεί να συνομιλεί με GitHub, Bitbucket και GitLab.

Ο κίνδυνος μπορεί να αφήσει μηνύματα, προειδοποιήσεις, σφάλματα στο PR / MR. Πηγή: danger.systems

Μπορείτε να ακολουθήσετε τον οδηγό εγκατάστασης εδώ για να εγκαταστήσετε τον Κίνδυνο στη διαδικασία CI σας. Ο κίνδυνος εφαρμόζει τους κανόνες από ένα σενάριο Ruby γραμμένο σε Dangerfile. Ας δούμε τι μπορούμε να κάνουμε εκεί.

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

προειδοποιήστε "Μεγάλο PR, σκεφτείτε να χωρίσετε σε μικρότερα" αν το git.lines_of_code> 600

Τι άλλο? Αν εργάζεστε με τη διαδικασία εξέτασης Test-After, μπορείτε εύκολα να ξεχάσετε να γράψετε δοκιμές. Από την άλλη πλευρά, θα πρέπει να υπάρχει αυτοματοποιημένος τρόπος για τα σχόλια "Ξεχάσατε να προσθέσετε δοκιμές". Γενικά, αν αλλάξετε περισσότερες από 20 γραμμές κώδικα, θα πρέπει να γράψετε δοκιμές. Ο αριθμός των γραμμών εξαρτάται από την απόφασή σας, αλλά έχετε την ιδέα. Ας ρίξουμε μια ματιά πώς μπορούμε να το επιτύχουμε αυτό με το Danger:

Ας δούμε αν υπάρχουν αλλαγές στο φάκελο του έργου
has_app_changes =! git.modified_files.grep (/ ProjectName /).
Στη συνέχεια, θα πρέπει να ελέγξουμε εάν οι δοκιμές ενημερώνονται
has_test_changes =! git.modified_files.grep (/ ProjectNameTests /).
Τέλος, ας τα συνδυάσουμε και να βάλουμε επιπλέον κατάσταση
## για αλλαγμένο αριθμό γραμμών κώδικα
if_app_changes &&! has_test_changes && git.lines_of_code> 20
  fail ("Οι δοκιμές δεν ενημερώθηκαν", κολλώδες: ψευδές)
τέλος

Ο κίνδυνος είναι κατάλληλος για κάθε είδος έργου. Παρέχει ένα ευρύ φάσμα διαμορφώσεων σε πολλές γλώσσες από plugins. Στην υπόθεση Swift, η Ash Furrow ανέπτυξε ένα plugin για το SwiftLint. Χάρη σε αυτό το plugin, μπορούμε να έχουμε προειδοποιήσεις SwiftLint ως σχόλια inline στο αίτημα έλξης. Μπορείτε να δείτε τον οδηγό εγκατάστασης εδώ. Μετά την εγκατάσταση, θα πρέπει να προσθέσετε μία από τις παρακάτω γραμμές στο τέλος του Dangerfile σας.

swiftlint.lint_files
swiftlint.lint_files inline_mode: true

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

Σημείωση: Δεν χρειάζεται να διαμορφώσετε το CI. Είναι δυνατό να εκτελέσετε τον Κίνδυνο στο τοπικό σας μηχάνημα με κίνδυνο τοπικής εντολής.

Χάρη στην απάντηση του Eren, εάν ο τοπικός εντοπισμός κινδύνου δεν τρέχει σε ολόκληρο το τελευταίο ανοιχτό PR, μπορείτε πάντα να χρησιμοποιήσετε την ακόλουθη εντολή:

κίνδυνος pr https: // YOUR_PR_URL --dangerfile = YOUR_DANGERFILE_PATH

P .: Μπορείτε να βρείτε το προκαθορισμένο Dangerfile μου εδώ .

Μπόνους: SwiftLint με γάντζο Git

Εάν εργάζεστε με διαφορετικούς επεξεργαστές κειμένου ή IDE που δεν υποστηρίζει το SwiftLint, μπορείτε να χρησιμοποιήσετε μόνο τα εργαλεία της γραμμής εντολών για να χρωματίσετε τον κώδικα σας. Αυτό είναι ένα επιπλέον βήμα και είναι εύκολο να ξεχάσετε. Καλά, μπορούμε να αυτοματοποιήσουμε αυτό. Το χαρακτηριστικό γάντζου στο Git είναι ένα άλλο μέρος για την αυτοματοποίηση των πραγμάτων. Βασικά, οι γάντζοι Git είναι σενάρια όπου η Git εκτελείται πριν ή μετά από γεγονότα όπως η δέσμευση, η προώθηση και η λήψη. Μπορούμε να τρέξουμε το SwiftLint σε ένα από αυτά τα scripts. Προσωπικά, χρησιμοποιώ το SwiftLint στο άγκιστρο προ-διεκπεραίωσης, ενώ γράφω Swift σε Υψηλό Κείμενο.

P .: Μπορείτε να βρείτε το πλήρες άγκιστρο προ-εμπλοκής εδώ . Εάν θέλετε να χρησιμοποιήσετε το ίδιο, απλά τοποθετήστε το αρχείο πάνω από το φάκελο .git / hooks στο έργο σας. (Θα δείτε τα σενάρια αγκίστρων δείγματος εκεί μέσα. Τοποθετήστε τα μεταξύ τους.) Μπορείτε επίσης να χρησιμοποιήσετε ως διαφορετικό γάντζο. Μπορείτε να ρίξετε μια ματιά στη λίστα των διαθέσιμων αγκίστρων και περισσότερες πληροφορίες εδώ.

Το τέλος

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

Ευχαριστώ για την ανάγνωση! Βοήθεια διάδοση της λέξης .

Έχετε ερωτήσεις, προτάσεις, σχόλια ή ιδέες για τις επερχόμενες αναρτήσεις ιστολογίου; Επικοινωνήστε μαζί μου στο Twitter ή γράψτε ένα σχόλιο! Μπορείτε επίσης να με ακολουθήσετε στο GitHub.

Οι άλλες μου θέσεις:

  • Χρησιμοποιώντας το Firebase Cloud Messaging για απομακρυσμένες ειδοποιήσεις στο iOS
  • Πρώτες εμπειρίες από πλευράς διακομιστή σε μεθόδους Swift - HTTP και λειτουργίες βάσης δεδομένων
  • Δημιουργία δοκιμαστικού API Backup Backend API - Δοκιμές μονάδων στην εφαρμογή Swift Server-Side