Η ανάπτυξη λογισμικού Agile δεν αφορά μόνο τις ευέλικτες αρχές και πρακτικές. Για να είναι επιτυχής στην έκδοση λογισμικού που επηρεάζει θετικά τους τελικούς χρήστες, αντιμετωπίζει το τεχνικό χρέος και αξιοποιεί με αξιοπιστία, η ομάδα ανάπτυξης πρέπει επίσης να εξετάσει τις πρακτικές κωδικοποίησης και τα πρότυπα αρχιτεκτονικής που οδηγούν στην ευελιξία.
Ένα ακόμη πιο σημαντικό ζήτημα διακυβεύεται για τεχνολογικούς οργανισμούς. Όσο σκληρό και αν είναι η ανάπτυξη λογισμικού, είναι ακόμη πιο δύσκολο να αναπτύξετε τακτικά βελτιώσεις και αναβαθμίσεις για μεγάλο χρονικό διάστημα. Οι πρακτικές των υπολογιστών CI / CD και IAC (υποδομή ως κώδικας) αντιμετωπίζουν εν μέρει έναν κρίσιμο παράγοντα καθώς ο αυτοματισμός επιτρέπει αξιόπιστους και επαναλαμβανόμενους τρόπους ανάπτυξης εφαρμογών. Προσθέστε σε συνεχείς δοκιμές και οι ομάδες ανάπτυξης έχουν έναν τρόπο να επιβεβαιώσουν ότι οι αλλαγές κώδικα δεν επηρεάζουν την υπάρχουσα λειτουργικότητα.
Ωστόσο, καθώς οι εφαρμογές γερνούν, οι αρχικοί προγραμματιστές μεταβαίνουν σε άλλα έργα και μερικές φορές σε άλλες εταιρείες. Όταν οι νέοι προγραμματιστές συμμετέχουν στην ομάδα, πρέπει να μάθουν την αρχιτεκτονική του λογισμικού και να κατανοήσουν τον κώδικα πριν μπορέσουν να τον αλλάξουν αξιόπιστα και αποτελεσματικά.
Επιπλέον, οι προγραμματιστές που δημιουργούν εφαρμογές συχνά θέλουν να αναπτύξουν νέες. Μπορεί να αισθάνεστε άνετα και ασφαλή να παραμείνετε συνδεδεμένοι με τις εφαρμογές που αναπτύσσετε, αλλά η πρόσδεσή σας στον κωδικό σας δεν είναι υγιής για την καριέρα ή τον οργανισμό σας.
Ο καλύτερος τρόπος για να προχωρήσετε σε νέες και συναρπαστικές πρωτοβουλίες ανάπτυξης λογισμικού είναι να κάνετε την αρχιτεκτονική, την εφαρμογή και τον κώδικα σας εύκολα υποστηριζόμενη από άλλους προγραμματιστές. Οι ευέλικτες ομάδες και προγραμματιστές πρέπει να δημιουργήσουν και να εφαρμόσουν πρακτικές κωδικοποίησης που υποστηρίζουν τη συνεχή ανάπτυξη λογισμικού.
1. Μην ανακαλύψετε ξανά τον τροχό
Ο πρώτος κανόνας κωδικοποίησης: Μην κωδικοποιείτε κάτι που δεν χρειάζεται να κωδικοποιηθεί! Πως?
- Εξετάστε το ενδεχόμενο να κάνετε ερωτήσεις σχετικά με τις απαιτήσεις. Γιατί είναι σημαντικό ένα χαρακτηριστικό; Ποιος επωφελείται; Πιο συγκεκριμένα, εξερευνήστε επιλογές μη κωδικοποίησης για να λύσετε το πρόβλημα. Μερικές φορές η καλύτερη λύση δεν είναι καθόλου λύση.
- Έχει ήδη κωδικοποιήσει κάποιος στον οργανισμό σας μια παρόμοια λύση; Ίσως υπάρχει μια μικροϋπηρεσία που χρειάζεται απλώς μια βελτίωση ή μια βιβλιοθήκη λογισμικού που χρειάζεται μια μικρή αναβάθμιση; Φροντίστε να ελέγξετε τη βάση κώδικα του οργανισμού σας προτού κωδικοποιήσετε κάτι νέο.
- Υπάρχουν λύσεις τρίτων, συμπεριλαμβανομένων προσιτών εργαλείων SaaS ή επιλογών ανοιχτού κώδικα, που πληρούν ελάχιστες απαιτήσεις;
- Έχετε εξετάσει ανοιχτά αποθετήρια κωδικοποίησης όπως το GitHub για παραδείγματα κώδικα και αποσπάσματα που πληρούν τις απαιτήσεις συμμόρφωσης του οργανισμού σας;
2. Εξετάστε τις επιλογές ανάπτυξης χαμηλού κώδικα
Εάν πρέπει να κωδικοποιήσετε μια λύση, τότε ίσως εναλλακτικές πλατφόρμες χαμηλού κώδικα μπορούν να επιτρέψουν την αποτελεσματικότερη ανάπτυξη των δυνατοτήτων σε σύγκριση με την κωδικοποίηση σε γλώσσες ανάπτυξης όπως Java, .Net, PHP και JavaScript.
Οι πλατφόρμες χαμηλού κώδικα όπως το Caspio, το Quick Base, το Appian, το OutSystems και το Vantiq παρέχουν όλα εργαλεία για την ανάπτυξη εφαρμογών με λίγο κώδικα και μερικές φορές ακόμη και χωρίς κωδικοποίηση. Κάθε πλατφόρμα ειδικεύεται σε διαφορετικές δυνατότητες και επομένως είναι κατάλληλη για μια συγκεκριμένη κατηγορία εφαρμογών. Το Caspio, για παράδειγμα, διευκολύνει την ενσωμάτωση φορμών και ροών εργασίας σε ιστότοπους. Η Γρήγορη βάση έχει ισχυρές δυνατότητες ροής εργασίας και αυτοματισμού και η αρχιτεκτονική της Vantiq είναι κατάλληλη για IoT και άλλες εφαρμογές δεδομένων σε πραγματικό χρόνο.
Υπάρχουν φορές που απαιτείται κωδικοποίηση, αλλά οι προγραμματιστές πρέπει επίσης να είναι ικανοί σε μία ή περισσότερες επιλογές ανάπτυξης χαμηλού κώδικα και να τις εξετάζουν για κατάλληλες περιπτώσεις χρήσης.
3. Αυτοματοποιήστε τις δοκιμές
Πέρα από τη σύνταξη κώδικα που πληροί τις απαιτήσεις, ένα από τα πιο σημαντικά πράγματα που πρέπει να κάνουν οι προγραμματιστές είναι να το δοκιμάσουν. Οι δοκιμαστικές πρακτικές ανάπτυξης και τα αυτοματοποιημένα εργαλεία δοκιμών έχουν ωριμάσει και οι ομάδες ανάπτυξης θα πρέπει να περιλαμβάνουν δοκιμές μονάδας, παλινδρόμησης, απόδοσης και ασφάλειας ως μέρος των ευέλικτων εκτιμήσεών τους.
Εκτός από τη διεξαγωγή δοκιμών για την επικύρωση εκδόσεων και εκδόσεων, αυτές οι δοκιμές συμβάλλουν επίσης στην ενίσχυση του κώδικα. Οι δοκιμές είναι τεκμηρίωση και συνάπτουν συμβόλαιο για το πώς υποτίθεται ότι συμπεριφέρεται ο κώδικας. Όταν οι νέοι προγραμματιστές συμμετέχουν σε ομάδες και εφαρμόζουν κατά λάθος μια κακή αλλαγή, οι συνεχείς δοκιμές σταματούν την κατασκευή και παρέχουν ουσιαστικά σχόλια στον προγραμματιστή, προκειμένου να αντιμετωπιστεί γρήγορα το ζήτημα.
4. Εξωτερικοποιήστε όλες τις παραμέτρους διαμόρφωσης
Δεν πρέπει να υπάρχει δικαιολογία για τους προγραμματιστές να έχουν ποτέ ρυθμίσεις σε επίπεδο συστήματος, κωδικούς χρήστη και κωδικούς πρόσβασης ή άλλες πληροφορίες διαμόρφωσης στον κώδικα. Έχω δει τους προγραμματιστές να χρησιμοποιούν συντομεύσεις ενώ αναπτύσσουν πρωτότυπα που βρίσκουν τον δρόμο τους σε περιβάλλοντα παραγωγής. Στις σημερινές αρχιτεκτονικές αυτό δεν πρέπει ποτέ να γίνει. Η σκληρή κωδικοποίηση δεν είναι τεχνικό χρέος, αλλά μια τεμπέλης, ανεύθυνη πρακτική κωδικοποίησης που μπορεί να έχει σημαντικές συνέπειες. Εάν ο κωδικός γίνει κατά λάθος προσβάσιμος, δημιουργεί ένα θέμα ευπάθειας ασφαλείας εάν εκτίθενται τελικά σημεία ή διαπιστευτήρια πρόσβασης.
Προχωρώντας ένα βήμα παραπέρα, κατά την επεξεργασία κώδικα παλαιού τύπου, η αντιμετώπιση οποιωνδήποτε σκληρών κωδικοποιήσεων και παραμέτρων θα πρέπει να αποτελεί μη διαπραγματεύσιμη τεχνική προτεραιότητα χρέους.
5. Ακολουθήστε τις συμβάσεις ονομασίας και συμπεριλάβετε σχόλια για να κάνετε τον κώδικα αναγνώσιμο
Δούλευα κάποτε με έναν εξαιρετικά ταλαντούχο προγραμματιστή που δεν γνώριζε καλά τα Αγγλικά και δεν ήμουν ο καλύτερος δακτυλογράφος. Θα δημιουργούσε αντικείμενα με ονόματα όπως ένα, σι, και ντο και στη συνέχεια δημιουργήστε τοπικές μεταβλητές με το όνομα ζζ, εε, xx. Θα δεσμευόταν να το καθαρίσει πριν από την κυκλοφορία, αλλά σπάνια ακολουθούσε.
Δεν πρέπει να έχετε καθιερώσει προγραμματισμό ζευγαριού ή όχλου για να αναγνωρίσετε ότι αυτή είναι μια φοβερή πρακτική.
Οι ομάδες θα πρέπει να υιοθετήσουν συμβάσεις ονομασίας, όπως τον Οδηγό στυλ JavaScript της Google και τον Οδηγό στυλ Java και να δεσμευτούν να σχολιάσουν κώδικα τουλάχιστον σε επίπεδο αρθρωτού και ιδανικά σε επίπεδο τάξης. Επιπλέον, οι οργανισμοί πρέπει να εξετάσουν το ενδεχόμενο χρήσης εργαλείων ανάλυσης στατικού κώδικα που παρέχουν ανατροφοδότηση στους προγραμματιστές όταν ο κώδικας χρειάζεται αναδιαμόρφωση για παράγοντες δομής και αναγνωσιμότητας.
6. Ελέγχετε συχνά τον κώδικα στον έλεγχο έκδοσης
Εάν δεν ελέγχετε τον κώδικα στο στοιχείο ελέγχου έκδοσης σε καθημερινή ή συχνότερη βάση, μπορεί να δημιουργήσει διενέξεις και άλλα μπλοκ που επηρεάζουν την ομάδα. Ένα μικρό λάθος μπορεί να αναγκάσει τις ευέλικτες ομάδες να χάσουν τις δεσμεύσεις τους για σπριντ ή να δημιουργήσουν επιπλέον προσπάθειες για την επίλυση των εξαρτήσεων.
Οι ομάδες πρέπει να συμφωνήσουν σε συμβάσεις για τον έλεγχο σε κώδικα που δεν είναι έτοιμος για παραγωγή. Οι συμβατικές προσεγγίσεις περιλαμβάνουν σημαίες χαρακτηριστικών και διακλάδωση Git.
7. Αποφύγετε την κωδικοποίηση ηρωικών και περιπλοκών
Οι περισσότεροι προγραμματιστές που γνωρίζω έγιναν επαγγελματίες μηχανικοί λογισμικού επειδή τους αρέσει να επιλύουν προκλήσεις κωδικοποίησης. Η κωδικοποίηση είναι μια τέχνη, επιστήμη και βιοτεχνία, και οι καλύτεροι προγραμματιστές αναζητούν αναθεωρητικές εργασίες κωδικοποίησης και κομψές εφαρμογές.
Εκτός από το ότι υπάρχει μια γκρίζα γραμμή μεταξύ της επίλυσης απαιτητικών επιχειρηματικών και τεχνικών εργασιών έναντι της κωδικοποίησης ηρωικών που αφήνουν στους επόμενους προγραμματιστές κώδικα που είναι δύσκολο να κατανοηθεί και περίπλοκο να διατηρηθεί.
Για όσους από εμάς έχουν κωδικοποιήσει κάποια στιγμή, θυμόμαστε την ευκολία του Perl one-liners ή τη χρήση ένθετων προτύπων στο C ++. Μερικές φορές υπάρχουν καλοί λόγοι για να χρησιμοποιήσετε αυτές τις προσεγγίσεις, αλλά εάν μια νέα ομάδα προγραμματιστών δεν καταλαβαίνει αυτές τις τεχνικές, είναι πιο δύσκολο να αλλάξετε τον κώδικα. Μερικές φορές είναι απλές αλλά λιγότερο κομψές πρακτικές κωδικοποίησης.
Οδήγηση ευελιξίας στην ευέλικτη ανάπτυξη λογισμικού
Τα τελετουργικά που είναι ενσωματωμένα στο scrum και στην ευέλικτη ανάπτυξη, συμπεριλαμβανομένων δεσμεύσεων, standups, sprint reviews και retrospectives είναι πλέον αποδεδειγμένες πρακτικές που επιτρέπουν την ομαδική συνεργασία και την επιτυχή εφαρμογή. Αλλά για να δείξουν ευελιξία για μεγάλο χρονικό διάστημα, οι προγραμματιστές πρέπει να αναλάβουν ευθύνες και πρακτικές κωδικοποίησης που επιτρέπουν μακροπρόθεσμη υποστήριξη και επεκτασιμότητα του κώδικα που αναπτύσσουν.
Οι ομάδες ανάπτυξης πρέπει να έχουν μια κριτική άποψη για τις πρακτικές κωδικοποίησης. Δεν είναι μόνο αρκετά καλό για επίδειξη και κυκλοφορία σήμερα. Είναι επίσης σημαντικό να επιτρέψετε σε άλλους να διατηρούν εύκολα την εφαρμογή και τον κώδικα.
