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

Χαλαρώστε - το έχουμε αυτό! Σε αυτό το άρθρο, θα εξετάσουμε τα πιο συνηθισμένα συστήματα τόσο για μικρά όσο και για μεγάλα έργα, με μερικές εύκολες πρακτικές που ακολουθούνται εύκολα.

Γιατί να ασχοληθούμε;

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

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

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

Κάνοντας την αίσθηση των πραγμάτων

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

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

Το υποχρεωτικό σετ

Αυτή είναι μια λίστα με τα αρχεία που θα πρέπει να έχουν σχεδόν κάθε έργο λογισμικού:

• README: αυτό είναι που σας δίνει το GitHub ακριβώς κάτω από το sourcetree και μπορεί να πάει μακρύ δρόμο να εξηγήσει τι είναι το έργο, πώς οργανώνονται τα αρχεία και πού να βρείτε περισσότερες πληροφορίες.
• CHANGELOG: για να αναφέρετε τι νέο υπάρχει, τροποποιείται ή διακόπτεται σε κάθε έκδοση ή αναθεώρηση - συνήθως με αντίστροφη χρονολογική σειρά για ευκολία (πρώτα οι τελευταίες αλλαγές).
• ΑΔΕΙΑ ΑΝΤΙΓΡΑΦΗΣ: ένα αρχείο που περιέχει το πλήρες κείμενο της άδειας που καλύπτει το λογισμικό, συμπεριλαμβανομένων ορισμένων επιπλέον πληροφοριών πνευματικών δικαιωμάτων, εάν είναι απαραίτητο (όπως άδειες τρίτων).
• .gitignore: υποθέτοντας ότι χρησιμοποιείτε Git (πιθανότατα το κάνετε), αυτό θα είναι επίσης απαραίτητο για να πείτε ποια αρχεία δεν συγχρονίζονται με το αποθετήριο. (Βλέπω Μετάβαση Έναρξη Git's primer στο .gitignore και την τεκμηρίωση για περισσότερες πληροφορίες και ρίξτε μια ματιά μια συλλογή χρήσιμων προτύπων .gitignore για μερικές ιδέες.)

Υποστηρικτικοί ηθοποιοί

Ορισμένα επιπλέον αρχεία που μπορείτε επίσης να εξετάσετε, ανάλογα με το έργο:

• AUTHORS: πιστώσεις σε όσους συμμετέχουν στη σύνταξη του κώδικα.
• BUGS: γνωστά ζητήματα και οδηγίες σχετικά με την αναφορά σφαλμάτων που βρέθηκαν πρόσφατα.
• CONTRIBUTING/HACKING: οδηγός για μελλοντικούς συνεισφέροντες, ιδιαίτερα χρήσιμος για έργα ανοιχτού κώδικα.
• FAQ: γνωρίζετε ήδη τι είναι. 😉
• INSTALL: οδηγίες για το πώς να μεταγλωττίσετε ή να εγκαταστήσετε το λογισμικό σε διαφορετικά συστήματα.
• NEWS: παρόμοιο με το CHANGELOG αρχείο, αλλά προορίζεται για τελικούς χρήστες, όχι για προγραμματιστές.
• THANKS: ευχαριστίες.
• TODO/ROADMAP: μια λίστα για προγραμματισμένες επερχόμενες λειτουργίες.
• VERSION/RELEASE: ένα μόνο σκάφος που περιγράφει τον τρέχοντα αριθμό έκδοσης ή το όνομα κυκλοφορίας.

Φάκελοι για στοιχεία ή υποσυστήματα

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

Μερικά παραδείγματα θα μπορούσαν να είναι:

• διεθνοποίηση (i18n) και εντοπισμός (l18n)
• ενότητες ελέγχου ταυτότητας
• πρόσθετα τρίτων
• εργαλεία γενικής χρήσης και εργασίες cron
• διεπαφή χρήστη (UI) και γραφική διεπαφή χρήστη (GUI)

Όλα αυτά μπορούν να οργανωθούν σε έναν μόνο κατάλογο "συστατικών" ή "υποσυστήματος" - αλλά μην τρελαίνετε!

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

Αστο Έξω του Sourcetree, παρακαλώ

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

ημερομηνία. Μπορεί να μπείτε στον πειρασμό να έχετε data/ κατάλογο στο sourcetree σας για αρχεία CSV και παρόμοια, ειδικά αν καταλαμβάνουν μόνο μερικά kilobyte. Τι γίνεται όμως αν παίρνουν megabyte ή ακόμα και gigabyte (που δεν είναι ασυνήθιστο αυτές τις μέρες); Θέλετε πραγματικά να δεσμευτείτε ότι στη βάση κωδικών σας σαν να ήταν κωδικός; Οχι.

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

ρυθμίσεις. Αυτό είναι ένα άλλο μεγάλο ΟΧΙ. Δεν πρέπει να βάλετε διαπιστευτήρια, κωδικούς πρόσβασης ή ακόμη και διακριτικά ασφαλείας στη βάση κώδικα. Δεν μπορούμε να καλύψουμε τους τρόπους γύρω από αυτό εδώ, αλλά αν είστε προγραμματιστής της Python, εξετάστε το ενδεχόμενο να το χρησιμοποιήσετε Python Decouple.

Περίπτωση 1: Εφαρμογή ιστού

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

Δομή αρχείου

├── .elasticbeanstalk
├── .env
├── billing
├── changelog.txt
├── locale
│ ├── en
│ └── zh_Hans
├── members
├── readme.txt
├── static
│ ├── fonts
│ ├── images
│ ├── javascript
│ └── styles
├── templates
│ ├── admin
│ └── frontend
├── todo.txt
└── tools

Ανάλυση

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

Αν είσαι πολύ λίγο εξοικειωμένοι με την ανάπτυξη ιστοσελίδων, το περιεχόμενο του static και templates ο φάκελος μπορεί να σας γνωρίζει. Ίσως τα μόνα ασυνήθιστα στοιχεία να είναι .elasticbeanstalk, το οποίο αποθηκεύει αρχεία ανάπτυξης για το Amazon Web Services (AWS) και .env, το οποίο μόνο τοπικά αποθηκεύει ρυθμίσεις για το έργο, όπως διαπιστευτήρια βάσης δεδομένων. Τα υπόλοιπα, όπως README και TODO, έχουμε ήδη συζητήσει.

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

Όσον αφορά την ονομασία, δεν κάνει μεγάλη διαφορά αν ονομάσουμε τον κατάλογο εικόνων images/ or img/, ή τον κατάλογο στυλ styles/ or css/, Ή η javascript/ κατάλογο js/. Το κύριο πράγμα είναι ότι η δομή είναι λογική, και ακολουθούμε πάντα κάτι από μια σύμβαση, είτε μακρά περιγραφικά ονόματα, είτε σύντομα.

Περίπτωση 2: Εφαρμογή για υπολογιστές

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

Σε αυτά τα παραδείγματα, θα αφήσουμε το sourcetree να μεγαλώσει λίγο μεγαλύτερο.

Δομή αρχείου

├── .gitignore
├── data
├── doc
├── legacy
│ ├── dashboard
│ ├── img
│ └── system
├── LICENSE
├── README
├── tests
├── thirdparty
├── tools
│ ├── data_integration
│ └── data_scraping
├── ui
│ ├── charts
│ ├── css
│ ├── csv
│ ├── dashboard
│ ├── img
│ │ └── icons
│ ├── js
│ ├── reports
│ └── summaries
├── VERSION
└── wiki

Ανάλυση

Η ui/ Ο φάκελος είναι ουσιαστικά ο πυρήνας της εφαρμογής. Το όνομα των υποφακέλων είναι σχεδόν αυτονόητο (μια άλλη καλή πρακτική). Και σε αντίθεση με το παράδειγμα της εφαρμογής ιστού, εδώ επιλέξαμε συντομευμένα ονόματα (όπως js αντί του javascript). Για άλλη μια φορά, αυτό που έχει σημασία είναι ότι είμαστε συνεπείς στο έργο.

Νωρίτερα, πρότεινα να αφήσετε αρχεία δεδομένων από το sourcetree, και ωστόσο υπάρχει data/ φάκελο εκεί. Πώς κι έτσι? Σκεφτείτε αυτό το δέντρο ως πλαίσιο προγραμματιστή που χρειάζεται δεδομένα για να δοκιμάσει σωστά την εφαρμογή. Αλλά αυτά τα δεδομένα εξακολουθούν να είναι εκτός συγχρονισμού του αποθετηρίου, σύμφωνα με τους κανόνες που ορίζονται στο .gitignore αρχείο.

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

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

Παρατηρήστε ότι υπάρχουν doc/ και wiki/ φακέλους, οι οποίοι θα μπορούσαν να μοιάζουν με επανάληψη. Ωστόσο, είναι επίσης απολύτως δυνατό - και ακόμη και λογικό - να υπάρχει ένας φάκελος τεκμηρίωσης που προορίζεται για τον τελικό χρήστη και ένα wiki για την ομάδα ανάπτυξης.

Τύλιξε

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

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

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

Περισσότερες Πληροφορίες

Πηγή: https://www.sitepoint.com/organize-project-files/?utm_source=rss