TheCodestReview #5 - δύο φορές την εβδομάδα χυμός μηχανικής λογισμικού

Στο τελευταίο επεισόδιο είχα πειράξει να σχολιάσω το άρθρο που καλύπτει τη σημασία του χιούμορ στον εργασιακό χώρο, αλλά εν τω μεταξύ κατάλαβα ότι αξίζει πολύ μεγαλύτερη αναγνώριση, οπότε θα γράψω σύντομα ένα ολόκληρο blog post γι' αυτό.    

Πράγματα που με απασχόλησαν τις τελευταίες δύο εβδομάδες: 

α) Πριν από τα Χριστούγεννα ξεκίνησα με το επεισόδιο της πρεμιέρας του Σειρά διαδικτυακών σεμιναρίων "Bulletproof CTO" (μείνετε συντονισμένοι για το 2ο επεισόδιο τον Φεβρουάριο με το SaaS CTOs, λεπτομέρειες σύντομα στο LinkedIn μου).

β) Ρύθμιση του σχεδίου ανάπτυξής μας για το 2021 με στόχο να ξεπεράσουμε τον πυρήνα των Ruby και JS και να αναπτύξουμε ένα Magento και Προϊόν Σχεδιαστική επάρκεια εσωτερικό.

Αρκετά με την αυτοπροβολή, επιτρέψτε μου να σας προσκαλέσω στο 5ο επεισόδιο της σειράς #TheCodestReview. 

Θέματα μου ομάδα έχει προετοιμαστεί για αυτή τη στιγμή: 

1. Κλιμακούμενη και συντηρήσιμη αρχιτεκτονική front-end.
2. Συμβατικές δεσμεύσεις.
3. Αναβαθμίσεις της έκδοσης Ruby 3.0.0.

Τα σχόλια σχετικά με την εφαρμογή frontend και τις συμβατικές δεσμεύσεις παραδίδονται αυτή την εβδομάδα από τους μηχανικούς μας React, ενώ η Ruby 3.0.0 από την ομάδα μας Ruby dream team.

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

Υπάρχουν δύο καλά πρότυπα από την ανάπτυξη back-end - Domain Driven Development (DDD) και Separation of Concerns (SoC). Μπορούμε επίσης να τα χρησιμοποιήσουμε στην αρχιτεκτονική front-end.

Στο DDD προσπαθούμε να ομαδοποιήσουμε παρόμοια χαρακτηριστικά και να τα αποσυνδέσουμε όσο το δυνατόν περισσότερο από άλλες ομάδες (ενότητες).

Ενώ με το SoC, για παράδειγμα, διαχωρίζουμε τη λογική, τις προβολές και τα μοντέλα δεδομένων (π.χ. χρησιμοποιώντας το πρότυπο σχεδίασης MVC ή MVVM).

Υπάρχουν πολλές καλές πρακτικές και μοτίβα για χρήση, αλλά αυτός ο τρόπος προτιμάται για μένα.

Όταν χρησιμοποιούμε αυτό το μοτίβο θα έχουμε αυτή την εικόνα:

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

Και έχουμε αυτή τη δομή:

φάκελος app - επίπεδο εφαρμογής

assets - φάκελος για εικόνες, γραμματοσειρές, εικονίδια κ.λπ.

συστατικά - εδώ θα πρέπει να υπάρχουν συστατικά για επαναχρησιμοποίηση που δεν έχουν περίπλοκη λογική

config - εδώ θα αποθηκεύσουμε την παγκόσμια κατάσταση

lib - φάκελος για πολύπλοκες συναρτήσεις και λογικούς υπολογισμούς

ενότητες - εδώ είναι οι ενότητές μας

pubsub - χώρος αποθήκευσης σχημάτων για την περιγραφή της δομής δεδομένων.

styles - για τον κώδικα css/scss μας

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

Αν κοιτάξουμε βαθύτερα στην αρχιτεκτονική των ενοτήτων και τις συνδέσεις τους με το API - θα έχουμε κάτι τέτοιο:

Αν ο φάκελος 'app' θα δημιουργήσουμε έναν άλλο φάκελο 'api' με τον κώδικα για τις κλήσεις API και τα δεδομένα που θα αποθηκεύσουμε στο 'config/store'. Εδώ κρατάμε στατικά και αμετάβλητα δεδομένα τα οποία χρησιμοποιούμε σε ολόκληρη την εφαρμογή.

Επίσης στο φάκελο 'pubsub/schema' θα περιγράψουμε συγκεκριμένους τύπους δεδομένων για JavaScript αντικείμενα.

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

Το front-end είναι το πρώτο σημείο εισόδου για τους χρήστες μας. Καθώς τα front-end έργα μας αυξάνονται σε χαρακτηριστικά, θα εισάγουμε και περισσότερα σφάλματα. Αλλά οι χρήστες μας περιμένουν να μην υπάρχουν σφάλματα, και νέα χαρακτηριστικά γρήγορα. Αυτό είναι αδύνατο. Ωστόσο, με τη χρήση μιας καλής αρχιτεκτονικής μπορούμε μόνο να προσπαθήσουμε να το πετύχουμε αυτό όσο το δυνατόν περισσότερο.

Συμβατικές δεσμεύσεις από τον Sathyabodh Mudhol στο DZone

Ο λόγος πίσω από την ανάγκη δέσμευσης της εργασίας με καλύτερο τρόπο

Φανταστείτε ότι βρίσκεστε σε ένα σημείο εκκίνησης σε μια εταιρεία στην οποία μόλις προσληφθήκατε. Όλοι οι άνθρωποι είναι καλοί μαζί σας και όλα φαίνονται μια χαρά μέχρι το σημείο που σας παρουσιάζουν μια βάση κώδικα από την εποχή που το JavaScript ήταν γλώσσα και το Netscape φόρτωνε μια σελίδα για κάτι που θα σας φαινόταν σαν μια αιωνιότητα.

Η κληρονομικότητα του κώδικα φαίνεται να είναι ένα τεράστιο ζήτημα κατά την εισαγωγή νέων προγραμματιστών σε ένα έργο. Η ανάγνωση του κώδικα είναι ένα πράγμα, αλλά η κατανόηση του τρόπου με τον οποίο αναπτύχθηκε η εφαρμογή δεν είναι ακριβώς το ίδιο. Συχνά οι commits αποδεικνύονται χρήσιμες και δίνουν το πλαίσιο για το γιατί αυτά τα console.logs δεν πιάστηκαν από τον linter ή γιατί αυτό το δυσάρεστο // TODO υπάρχει για τα παιδιά του προγραμματιστή που έκανε αρχικά τον σχολιασμό.

Ας ξεκινήσουμε με το γιατί οι συμβατικές δεσμεύσεις είναι καλύτερες από τους μη τυποποιημένους κανόνες δεσμεύσεων.

Αν προσλάβουμε νέους προγραμματιστές σε ένα έργο στο οποίο οι περισσότερες μεταβιβάσεις αποτελούνται από μηνύματα της μορφής ότι πρέπει να δουλέψει ή Sleepy fix for footer ASAP τι σας έρχεται στο μυαλό;

Θα έλεγα ότι οι κόκκινες σημαίες επειδή:

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

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

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

Εργαλεία

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

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

Όταν ασχολείστε με τις ρυθμίσεις και τις εξαπλώνετε σε όλη την ομάδα σας, μπορείτε απλά να δημιουργήσετε ένα πακέτο npm και απλά να το mpn i -D σε κάθε έργο. Αυτό σίγουρα θα βοηθήσει όλους στο έργο να είναι στην ίδια σελίδα ανά πάσα στιγμή και αν χρειαστεί να περπατάτε από έργο σε έργο καταλαβαίνοντας τι αφορούσαν οι τελευταίες αλλαγές (και γιατί έγιναν).

Φίλοι με πολλαπλά οφέλη

Έτσι τώρα, αφού τα έχετε στήσει όλα και έχετε καταλάβει γιατί θα ήταν καλή ιδέα να αρχίσετε να χρησιμοποιείτε το CC, το καλύτερο μέρος θα είναι ο προγραμματισμός γύρω από τους κανόνες που μόλις εφαρμόσατε! Χρησιμοποιούμε έναν τυποποιημένο τρόπο για το πώς κάνουμε commit, δίνουμε μεγαλύτερη προσοχή στο τι πραγματικά αφορούσε το commit, οπότε γιατί να μην δημιουργήσετε άγκιστρα που σας επιτρέπουν γρήγορο έλεγχο στο staging όταν υπάρχει μια σημαία; Δεν θέλουμε να επιβαρύνουμε υπερβολικά τις υπηρεσίες και να μειώσουμε το κόστος όταν χρειάζεται και υπάρχουν κάποιοι λόγοι για να κάνουμε δοκιμές σε διακομιστή που μοιάζει με παραγωγή αντί για localhost.

Ας υποθέσουμε ότι εργάζεστε σε PWA και ότι το SSL είναι απαραίτητο για να δοκιμάσετε τις πλήρεις δυνατότητες και ότι έχετε ένα SSL στην πλατφόρμα δοκιμών σας. Το μόνο που χρειάζεστε τώρα είναι μια καλή δέσμευση. Κάτι σαν feat(PWA): manifest icons workbox setup upload θα ενεργοποιούσε όλο το μηχανισμό των δοκιμών και της μετακίνησης των γραναζιών. Δεν το χρειαζόμαστε αυτό όταν απλά ανεβάζουμε κάποια στατικά δεδομένα όπως το manifest.json, οπότε προσθέτουμε μια σημαία [TEST_SKIP] ως postfix στο commit μας. Αυτό επιτρέπει στο CI μας να ανεβάζει απλώς νέα στοιχεία στο περιβάλλον δοκιμών και να παραλείπει τις δοκιμές. Μπορείτε να διαβάσετε περισσότερα σχετικά με αυτό εδώ

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

Ευτυχισμένη συμβατική δέσμευση!

Ruby 3.0.0 ενημερώσεις απελευθέρωσης από την Κοινότητα Ruby

Η πολυαναμενόμενη από την κοινότητα έκδοση Ruby 3.0.0 είδε το φως της ημέρας τα Χριστούγεννα, ώστε όλοι οι προγραμματιστές Ruby εκεί έξω να τη βρουν κάτω από το χριστουγεννιάτικο δέντρο μόλις ξυπνήσουν το πρωί. Στο The Codest καλλιεργούμε την κουλτούρα της ανταλλαγής γνώσεων με τη διοργάνωση εβδομαδιαίων συναντήσεων ανάπτυξης όπου οι μηχανικοί μας συζητούν τις τεχνολογικές τάσεις και τις νέες ανακαλύψεις τους που αξίζουν την προσοχή. Παρακάτω μπορείτε να βρείτε έναν σύνδεσμο για τις διαφάνειες από την ημέρα επίδειξης όπου ο ανώτερος μηχανικός μας της Ruby συζήτησε μερικές σημαντικές αλλαγές στη Ruby 3.0.0 από την υποκειμενική του άποψη:

https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing

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

https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods

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

Επιστρέφουμε σε σας με το επόμενο επεισόδιο στα τέλη Φεβρουαρίου με την ανασκόπηση ενός podcast με συνέντευξη από τον CTO του Shopify, τον άνθρωπο πίσω από μια ομάδα μηχανικών που εργάζεται στην υπέροχη εφαρμογή Ruby monolith!

Τα λέμε.

Διαβάστε περισσότερα:

TheCodestReview #4 - εβδομαδιαίος χυμός μηχανικής λογισμικού

TheCodestReview #3 - εβδομαδιαίος χυμός μηχανικής λογισμικού

TheCodestReview #2 - εβδομαδιαίος χυμός μηχανικής λογισμικού