Προς το περιεχόμενο

Είναι πάντα εύκολο να γράψεις σωστά δομημένο κώδικα;

PC_MAGAS

Από τον PC_MAGAS
στο Προγραμματισμός

 Share

Προτεινόμενες αναρτήσεις

PC_MAGAS Experienced

PC_MAGAS

Δημοσ.
Δημοσ.

Πολλές φορές, σαν developer, επαγγελματικώς βλέπεις κάποια πράγματα που ασπρίζουν τα μαλιά σου και βγάζεις αφρούς από το στόμα πχ. γιατί ρε γαμώτο έβαλε SQL query στον Κώδικα η γιατί είναι ΤΟΣΟ μεγάλη η function και δεν το έσπασε σε μικρότερες.

 

Αλλά είναι οάντα εύκολο να ορίσεις την σωστή δομή του λογισμικού που αναπτύσεις. Πχ να επιλέξεις τα σωστά Desighn Pattern κλπ κλπ; Ακόμη μερικές φορές έχω δει μη σωστά αρχιτεκτονικά δομημένο κώδικα. Αλλά είναι πάντα επιλογή αυτό;

 

Μήπως τελικά είναι καλύτερη επιλογή γράψτο όπως να ναι να βγεί η δουλεία και άμα χαλάσει το ξαναγράφουμε;

GReaperEx Contributor

GReaperEx

Δημοσ.
Δημοσ.

Δεν υπάρχει "σωστή δομή". Το σημαντικό είναι η σύνταξη να είναι καθαρή και συνεχής, δλδ να χρησιμοποιείται καλή στοίχιση και η ίδια από όλους( που δουλεύουν στο ίδιο project ). Δεν είναι πάντα καλό να σπάει μια μεγάλη συνάρτηση σε μικρότερες, όπως και δεν είναι πάντα καλό να χρησιμοποιούνται classes για όλα.

 

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

 

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

  • Like 1
masteripper Crazy Insomniac

masteripper

Δημοσ.
Δημοσ.

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

  • Like 2
NikosKallithea Crazy Insomniac

NikosKallithea

Δημοσ.
Δημοσ.

Πολλές φορές, σαν developer, επαγγελματικώς βλέπεις κάποια πράγματα που ασπρίζουν τα μαλιά σου και βγάζεις αφρούς από το στόμα πχ. γιατί ρε γαμώτο έβαλε SQL query στον Κώδικα η γιατί είναι ΤΟΣΟ μεγάλη η function και δεν το έσπασε σε μικρότερες.

 

Αλλά είναι οάντα εύκολο να ορίσεις την σωστή δομή του λογισμικού που αναπτύσεις. Πχ να επιλέξεις τα σωστά Desighn Pattern κλπ κλπ; Ακόμη μερικές φορές έχω δει μη σωστά αρχιτεκτονικά δομημένο κώδικα. Αλλά είναι πάντα επιλογή αυτό;

 

Μήπως τελικά είναι καλύτερη επιλογή γράψτο όπως να ναι να βγεί η δουλεία και άμα χαλάσει το ξαναγράφουμε;

Οταν ξεκινάς να γράψεις κατι που υπολογίζεις να εχει πχ 1000- 2000 γραμμές και μετα απο επανειλημμένες συσκέψεις και αλλαγές στον προγραμματισμό της εταιρείας αναγκάζεσαι να προσθέτεις και να προσθέτεις γραμμές, τοτε κάποιος άλλος που θα το δει βγάζει το συμπέρασμα που έβγαλες και εσύ

GReaperEx Contributor

GReaperEx

Δημοσ.
Δημοσ.

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

 

Και αυτό γίνεται πιο αυτονόητο αν υπολογίσεις και τις υπερβολικές απαιτήσεις πολλών manager. Όταν ο άλλος θέλει να τελειώσεις κάτι σε 12 ώρες ενώ ξέρεις ότι δε πρόκειται να σου πάρει λιγότερο από τρεις μέρες... αλλάζουν οι προτεραιότητες σου.

masteripper Crazy Insomniac

masteripper

Δημοσ.
Δημοσ.

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

Σε project το οποίο έχει deadline ακόμα και χαλαρό όπως και να το κάνεις όπως και αν δεν σου αρέσει στο τέλος την ματσακονια θα την κάνεις τουλάχιστον "λίγο"

Predatorkill Grand Master

Predatorkill

Δημοσ.
Δημοσ.

Περαν του κωδικα βαζω σχολια οπου μπορω, αμα δε βαλω ξεχναω γρηγορα. Συνηθης τακτικη επισης οταν γραφω κατι βρωμικα βαζω // todo και επιστρεφω αργοτερα και κανω refactor.

  • Like 1
masteripper Crazy Insomniac

masteripper

Δημοσ.
Δημοσ.

Περαν του κωδικα βαζω σχολια οπου μπορω, αμα δε βαλω ξεχναω γρηγορα. Συνηθης τακτικη επισης οταν γραφω κατι βρωμικα βαζω // todo και επιστρεφω αργοτερα και κανω refactor.

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

  • Like 2
Predatorkill Grand Master

Predatorkill

Δημοσ.
Δημοσ.

Θορυβος ως προς την αναγνωση ή ως προς το τελικο προϊον; Στο τελικο προϊον αφαιρουνται αυτοματως με εργαλεια ως γνωστον. Ως προς την αναγνωση σε οτι framework εχω δουλεψει υπαρχουν παντου comments στον πηγαιο κωδικα και σχεδον ολες τις φορες υπαρχουν σχολια πολλων γραμμων πληρως επεξηγηματικα.

  • Like 1
Επισκέπτης

Επισκέπτης

Δημοσ.
Δημοσ.

Προσωπικά δεν με ενδιαφέρει ο σωστός ή ο λάθος τρόπος. Με ενδιαφέρει να είναι γρήγορο το πρόγραμμα.

defacer Grand Master

defacer

Δημοσ.
Δημοσ.

Πολλές φορές, σαν developer, επαγγελματικώς βλέπεις κάποια πράγματα που ασπρίζουν τα μαλιά σου και βγάζεις αφρούς από το στόμα πχ. γιατί ρε γαμώτο έβαλε SQL query στον Κώδικα η γιατί είναι ΤΟΣΟ μεγάλη η function και δεν το έσπασε σε μικρότερες.

Αν ασπρίζουν τα μαλλιά σου με αυτά, άλλαξε καριέρα όσο ακόμα έχεις μαλλιά...   :-D  :-D 

 

Αλλά είναι οάντα εύκολο να ορίσεις την σωστή δομή του λογισμικού που αναπτύσεις. Πχ να επιλέξεις τα σωστά Desighn Pattern κλπ κλπ; Ακόμη μερικές φορές έχω δει μη σωστά αρχιτεκτονικά δομημένο κώδικα. Αλλά είναι πάντα επιλογή αυτό;

 

Μήπως τελικά είναι καλύτερη επιλογή γράψτο όπως να ναι να βγεί η δουλεία και άμα χαλάσει το ξαναγράφουμε;

Ποτέ δεν είναι εύκολο, αν ήταν θα το έκαναν όλοι. Δεν είναι καν εύκολο να συμφωνήσουμε τι σημαίνει ακριβώς "σωστή" δομή.

 

Δεν είμαι σίγουρος πώς εννοείς το "γράψτο όπως να'ναι". Μπορεί να πάει από "χωρίς features και φρου φρου, ίσα ίσα να γίνεται η δουλειά μας", που είναι γενικά πάρα πολύ καλή προσέγγιση μέχρι "copy paste bubblesort από stack overflow" που είναι για κρέμασμα.

Και αυτό γίνεται πιο αυτονόητο αν υπολογίσεις και τις υπερβολικές απαιτήσεις πολλών manager. Όταν ο άλλος θέλει να τελειώσεις κάτι σε 12 ώρες ενώ ξέρεις ότι δε πρόκειται να σου πάρει λιγότερο από τρεις μέρες... αλλάζουν οι προτεραιότητες σου.

 

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

  • Like 1
Tsalikis177 Rising Star

Tsalikis177

Δημοσ.
Δημοσ.

Πολλές φορές, σαν developer, επαγγελματικώς βλέπεις κάποια πράγματα που ασπρίζουν τα μαλιά σου και βγάζεις αφρούς από το στόμα πχ. γιατί ρε γαμώτο έβαλε SQL query στον Κώδικα η γιατί είναι ΤΟΣΟ μεγάλη η function και δεν το έσπασε σε μικρότερες.

 

Αλλά είναι οάντα εύκολο να ορίσεις την σωστή δομή του λογισμικού που αναπτύσεις. Πχ να επιλέξεις τα σωστά Desighn Pattern κλπ κλπ; Ακόμη μερικές φορές έχω δει μη σωστά αρχιτεκτονικά δομημένο κώδικα. Αλλά είναι πάντα επιλογή αυτό;

 

Μήπως τελικά είναι καλύτερη επιλογή γράψτο όπως να ναι να βγεί η δουλεία και άμα χαλάσει το ξαναγράφουμε;

 

Σκέφτηκες ότι πολύ απλά στα @ του και ήθελε απλά να πάρει τον μισθό; άσε που οι εταιρείες σου εμπνέουν αυτό το πνεύμα. Δηλαδή "ξεπέτα το και άσε τα optimizations". 

 

Όπως έχω πει. δεν είμαστε στην εποχή που είχαμε 512-1γβ ραμ. Σήμερα έχουμε μπόλικη ραμ, γρήγορη ραμ και γρήγορους επεξεργαστές. τα περισσότερα προγράμματα τρέχουν σφαίρα όσο κακογραμμένα να είναι. Δεν κάνει διαφορά στο μάτι.

 

Και ξες... εγώ σαν πελάτης στα @ μου το πίσω. Την δουλειά μου την κάνει το app?

 

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

Alithinos Experienced

Alithinos

Δημοσ.
Δημοσ.

Περαν του κωδικα βαζω σχολια οπου μπορω, αμα δε βαλω ξεχναω γρηγορα. Συνηθης τακτικη επισης οταν γραφω κατι βρωμικα βαζω // todo και επιστρεφω αργοτερα και κανω refactor.

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

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

 

1. Ονόμασε τις συναρτήσεις σου με ρήματα, πχ GetNumber. Οι συναρτήσεις συνήθως κάνουν κάτι, και άρα ένα ρήμα είναι ο καταλληλότερος τρόπος ονομασίας τους.

2. Διατήρησε μια συνέχεια (consistency) στο τρόπο που δίνεις ονόματα. Πχ Αν έχεις πολλές συναρτήσεις οι οποίες 'παίρνουν κάτι διάλεξε είτε να έχουν μέσα το Get, ή το Retrieve, ή το Acquire... Αλλά μην έχεις άλλες έτσι και άλλες αλλιώς.

3. Ονόμασε τις κλάσεις σου και άλλα αντικείμενα, με αντικείμενα. Πχ "Client" ή "Server".

4. Φρόντισε το όνομα του κάθε τι να εξηγεί το τι είναι το κάθε τι.

 

 

 

Θορυβος ως προς την αναγνωση ή ως προς το τελικο προϊον; Στο τελικο προϊον αφαιρουνται αυτοματως με εργαλεια ως γνωστον. Ως προς την αναγνωση σε οτι framework εχω δουλεψει υπαρχουν παντου comments στον πηγαιο κωδικα και σχεδον ολες τις φορες υπαρχουν σχολια πολλων γραμμων πληρως επεξηγηματικα.

 

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

 

 

 

 

@PC_MAGAS & @Predatorkill: Αν έχεις χρόνο και όρεξη, ρίξε ένα διάβασμα στο Clean Code. Έμαθα για αυτό και άρχισα να το διαβάζω λόγο υπερβολικού Code Smell που είχε κάτι το οποίο έφτιαχνα. Το βιβλίο με έκανε να σταματήσω το project που ασχολιόμουν, και να επιστρέψω σε παλαιότερα projects που θεωρούσα completed για να εφαρμόσω τα όσα έμαθα και σε αυτά, γιατί ένιωσα πως ήταν θέμα τιμής να τα καθαρίσω. Διδάσκει επί της ουσίας της αρχές του S.O.L.I.D. 

 

Έκανα λοιπόν ένα γενναίο refactor εφαρμόζοντας τις αρχές που έμαθα απ' το βιβλίο, και πλέον το project είναι πολύ πιο ευανάγνωστο και εύκολο στη συντήρηση.

 

Ενδεικτικά θα σου παρουσιάσω τα code metrics όπως τα μετρά το Visual Studio σε ένα project πριν και μετά το refactor που έκανα:

 

Πριν:

 

Maintain:               61                                               
Cyclomatic:        640                                               
Depth:                    7                                                
Coupling:              90                                                
Lines:                3383
 
Μετά:     
                                          
Maintain:               67                                          +6
Cyclomatic:        483                                        -157
Depth:                     7                                          +0
Coupling:             102                                       +12*
Lines:                 2323                                    -1060

 

 

 

 

* Γενικά το περισσότερο coupling είναι κακό, αλλά έχε υπ' όψιν πως το VS μετρά ως coupling ακόμα και αν μια συνάρτηση καλεί μια άλλη συνάρτηση η οποία βρίσκεται εντός της ίδιας κλάσης. Και στη στη συγκεκριμένη περίπτωση, το +12 coupling είναι πάει χαλάλι αφού μπόρεσα και μείωσα τις γραμμές κώδικα κατά 1060 σειρές.

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

  • Like 2
defacer Grand Master

defacer

Δημοσ.
Δημοσ.

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

 

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

 

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

// WORST
function isValidDate(day, month, year) {
    leap = (year % 4 == 0) && ((year % 100 != 0) || year % 400 == 0);
    switch (month) {
        case 1:
        case 3:
        case 5:
            max = 31;
        // κλπ κλπ
    }

    return day >= 1 && day <= max;
}

Είναι λίγο μπερδεψιάρικο, ας το βελτιώσουμε με σχόλια:

// STILL BAD!
function isValidDate(day, month, year) {
    // Determine if it's a leap year: a year is leap if and only if it can be divided by 4,
    // but not if it can be divided by 100, unless it can also be divided by 400.
    leap = (year % 4 == 0) && ((year % 100 != 0) || year % 400 == 0);

    // Determine how many days in that particular month
    switch (month) {
        case 1:
        case 3:
        case 5:
            max = 31;
        // κλπ κλπ
    }

    return day >= 1 && day <= max;
}
Make no mistake, αυτός ο κώδικας είναι πολύ καλύτερος από τον αρχικό! Έχει όμως κι αυτός το πρόβλημά του: χρησιμοποιούμε human-readable comments αντί να κωδικοποιήσουμε αυτό που κάνουμε στο machine-readable επίπεδο:
 
// GOOD
function isValidDate(day, month, year) {
    daysInMonth = countDaysInMonth(month, year);
    return day >= 1 && day <= daysInMonth;
}

function countDaysInMonth(month, year) {
    isLeap = isLeapYear(year);
    switch (month) { ... }
}

function isLeapYear(year) {
    return (year % 4 == 0) && ((year % 100 != 0) || year % 400 == 0);
}

Εδώ λοιπόν δε χρειάζομαι σχόλια στον κώδικα γιατί:

  • Έχω αντικαταστήσει περιεχόμενα σχολίων με ονοματισμένα function calls: δε χρειάζεται να κάνω πρόλογο για το τι συμβαίνει εκεί που γράφει countDaysInMonth(...). Σημαντικό: αυτό για να γίνει πρέπει να είναι πραγματικά πολύ απλοποιημένες οι συναρτήσεις (SRP). Το να πάρεις ένα μάτσο spaghetti code και να τον κρύψεις πίσω από ένα function call είναι μεν καλύτερο από πριν, αλλά όχι βέλτιστο εφόσον η function αυτή κάνει αρκετά πράγματα για να χρειάζεται προετοιμαστικά σχόλια στο call site "κάτσε να σου πω τι πάω να κάνω τώρα".
  • Έχω σπάσει -- και το τονίζω αυτό γιατί είναι επίσης σούπερ κλασικό tip -- τις functions έτσι ώστε να φαίνεται πολύ ευκολότερα τι, και κυρίως γιατί, κάνει η κάθε μία. Ο αναγνώστης της isValidDate θα δει δύο τέλεια κατανοητές γραμμές κώδικα και τίποτα παραπάνω. Αν αυτό που τον ενδιαφέρει είναι να μάθει τι κάνει η isValidDate δε χρειάζεται να διαβάσει παραπάνω, σε αντίθεση με την αρχική εκδοχή.

 

ΟΚ, εντάξει το textbook example. Αυτό δε σημαίνει ότι "τα σχόλια είναι άσχημα". Ορίστε ένα κομμάτι από δικό μου production κώδικα:

public function materialize()
{
    $output = Json::encode($this->data);
    $userAgent = Application::resolve()->request->getUserAgentAndVersion();
    $isInternetExplorer = $userAgent && reset($userAgent) === HttpRequest::UA_INTERNET_EXPLORER;
    if ($isInternetExplorer && $this->httpCode >= 400 && strlen($output) < 513) {
        $output .= str_repeat(' ', 513 - strlen($output));
    }


    echo $output;
}

Τι σκατά γίνεται εδώ;;;;; ΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑΑ!!!!11

 

Ορίστε πάλι το ίδιο αλλά μαζί με τα comments αυτή τη φορά:

public function materialize()
{
    $output = Json::encode($this->data);

    // INTERNET EXPLORER HORROR STORY #2436236
    // Server returns a 4xx or 5xx error code? Don't worry, IE comes to the rescue! If you return such a code IE
    // will helpfully REPLACE YOUR CONTENT with a friendly error message, which is bad enough by itself. If you are
    // in the pleasant position of doing this in a <iframe> and then try to access the content from the original
    // page this means that scripting errors will occur as a result of the same-origin policy and it all goes
    // downhill from there.
    //
    // Solution: make sure that you always return content larger than 512 bytes in order to turn off this "feature".
    // Documented at http://support.microsoft.com/kb/294807/en-us
    $userAgent = Application::resolve()->request->getUserAgentAndVersion();
    $isInternetExplorer = $userAgent && reset($userAgent) === HttpRequest::UA_INTERNET_EXPLORER;
    if ($isInternetExplorer && $this->httpCode >= 400 && strlen($output) < 513) {
        $output .= str_repeat(' ', 513 - strlen($output));
    }

    echo $output;
}

Νομίζω είναι προφανές πού θέλω να καταλήξω.

  • Like 4

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα
 Share
Προς την λίστα θεμάτων
  • Δημιουργία νέου...