Εργασία ως προγραμματιστής υπό δύσκολες συνθήκες

[great]

Τα σχόλια δεν ειναι τίποτα μεσα στον κώδικα.

Μπερδευετε τα σχολια με το documentation που πρεπει να ακολουθει κάθε εφαρμογή.

Εκει αναλύεις technical, οχι για τον manager για τον επομενο developer, συνάδελφο στο τμήμα κτλ. Δεν εχει νοημα να το καταλαβει η μαιμου ο manager δεν ειναι αυτος ο σκοπός.

[Kercyn]

7 λεπτά πριν, asxs είπε

Είμαι υπέρ και προσπαθώ πάντα να γράφω clean (self-documented) κώδικα αλλά δυστυχώς δεν έχω ούτε την τεράστια εμπειρία αλλά ούτε γνωρίζω όλα τα best practices ώστε να συνδέω λογικές. Διαβάζοντας λοιπόν τις απαντήσεις περί κατηγορηματικής μη χρήσης σχολίων μου γεννήθηκαν οι εξής απορίες:

Γράφετε πάντα μόνοι σας; Σας ενδιαφέρει αν ο κώδικας σας μπορεί να συντηρηθεί από κάποιον άλλο π.χ. νέο στην εταιρεία που προσπαθεί να μπει στην ομάδα; Ο Product Owner / Project Manager / Team Leader σας είναι χαρούμενος όταν του παραδίδετε κομμάτια κώδικα χωρίς καθόλου σχόλια λέγοντας του απλά ότι θα βγάλει άκρη διαβάζοντας τα ονόματα των μεταβλητών / μεθόδων; Δεν έχει τύχει ποτέ να αναλάβετε κάτι από κάποιον άλλον και να μην βγάζετε άκρη με τις δίχως σχόλια "καλλιγραφίες" του.

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

[ghostaki]

2 ώρες πριν, asxs είπε

Είμαι υπέρ και προσπαθώ πάντα να γράφω clean (self-documented) κώδικα αλλά δυστυχώς δεν έχω ούτε την τεράστια εμπειρία αλλά ούτε γνωρίζω όλα τα best practices ώστε να συνδέω λογικές. Διαβάζοντας λοιπόν τις απαντήσεις περί κατηγορηματικής μη χρήσης σχολίων μου γεννήθηκαν οι εξής απορίες:

Γράφετε πάντα μόνοι σας; Σας ενδιαφέρει αν ο κώδικας σας μπορεί να συντηρηθεί από κάποιον άλλο π.χ. νέο στην εταιρεία που προσπαθεί να μπει στην ομάδα; Ο Product Owner / Project Manager / Team Leader σας είναι χαρούμενος όταν του παραδίδετε κομμάτια κώδικα χωρίς καθόλου σχόλια λέγοντας του απλά ότι θα βγάλει άκρη διαβάζοντας τα ονόματα των μεταβλητών / μεθόδων; Δεν έχει τύχει ποτέ να αναλάβετε κάτι από κάποιον άλλον και να μην βγάζετε άκρη με τις δίχως σχόλια "καλλιγραφίες" του.

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

Προφανώς και κάποιες φορές θα μας ξεφύγουν πράγματα και ο κώδικας δε θα είναι όπως θα τον θέλαμε. Άνθρωποι είμαστε, λάθη γίνονται, κάποιες φορές δεν υπάρχει χρόνος και απλά θες να φτιάξεις κάτι επειγόντως (αλλά τότε καλό είναι να συνοδεύεται κι από ένα tech debt ticket με σχόλιο για link στο Jira πχ.), και 1002 άλλοι λόγοι.

Επεξ/σία 9 Δεκεμβρίου 2020 από ghostaki

[MitsarasAth]

Στην ελλαδα στις περισσοτερες δουλειες επικρατει αυτος ο πανικος-χαος ακομα και σε μεγαλα ονοματα για τον απλο λογο οτι ο dev δεν εχει ιδαιτερη συμμετοχη  στην ληψη αποφασεων και στην οργανωση δυστηχως.

Αυτο το κάνουν συνηθως μανατζαραιοι με ενα καρο πιστοποιησεις και buzzwords(και συνηθως non technical) ,η φιλος του διευθυντη και διοικουν μια εταιρεια πληροφορικης ακριβως το ιδιο με ενα εργοστασιο(τρεις εργατες φτιαχνουν γρηγοροτερα εναν τοιχο απο εναν αρα ετσι θα λειτουργει καισ το software ), και αντι για εργατες ειναι οι ντεβς που γραφουν κωδικα με τον κιλο, γρηγορα κτλ κτλ που αυτο οδηγει σε ελλειψη documentation , σχεδιασμος στο ποδι η ανυπαρκτος, legacy με το που βγηκε στην παραγωγη 😛 και αλλα τετοια ωραια.
 

Επεξ/σία 9 Δεκεμβρίου 2020 από MitsarasAth

[Predatorkill]

Ωραια θα ηταν παντως να υπηρχε ενα standard στα γνωστα τουλαχιστο IDE οπου με καποιο “inner link” να μπορεις να βαζεις comments στο link και απλα να βαζεις το link για comment. (Δεν αναφερομαι σε http links πχ προς jira, να μην «φευγεις» δλδ απο το IDE)

Ισως και να υπαρχει, δε το χω ψαξει.

Επεξ/σία 9 Δεκεμβρίου 2020 από Predatorkill

[valkon]

6 ώρες πριν, valkon είπε

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

 

[AgiosEfraim]

Δεν ξερω ακριβως πως είναι τα πράγματα στον προγραμματισμό αλλα στο IT γενικότερα οταν αλλάζεις δουλειά και δεν πας σε μια εταιρία που μολις ανοιξε, ενω εσυ νομίζεις οτι φεύγεις απο το μπουρδελο και πας στον παράδεισο αυτο που πραγματικα συμβαίνει ειναι οτι εσυ πας καπου ωπου 60% του χρόνου σου ειναι να φτιαξεις τα σκατα των προηγούμενων, κανεις ομως δεν θελει να πειραξει σκατα παρελθόντος, στο υπόλοιπο 30% του χρόνου σου δημιουργείς δικα σου προβλήματα που θα τα βρει ο επόμενος και ενα 10% του χρόνου σου συζητας ποσο καλα θα τα εφτιαχνες εσυ, αν... αν... αν... ! 

Καποια στιγμή σου κάθεται η καλη (για αυτο πρέπει να αλλάζουμε δουλειές) ή εισαι τοσο κακος που σε κανουν μανατζερ. 

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

 

 

Επεξ/σία 9 Δεκεμβρίου 2020 από AgiosEfraim

[masteripper]

8 ώρες πριν, smoipa είπε

Μια γνώμη και από εμένα. Σιχαίνομαι να βλέπω τον κώδικα μου να ξεπερνάει τις 40 - 50 γραμμές σε μία function, 9 στις 10 περιπτώσεις σημαίνει ότι κάπου το έχασα σχεδιαστικά. Προσπαθώ συνήθως να υπάρχει μια function που θα είναι ο σκελετός και το μόνο που θα κάνει είναι να καλεί άλλες και να μην κάνει κανέναν υπολογισμό η ίδια. Με αυτόν το τρόπο αν τα ονόματα που δίνεις στις επιμέρους function είναι self explanatory δεν νομίζω να έχεις κανένα θέμα, ή να χρειαστείς σχόλια. Από εκεί και πέρα όταν αλλάζεις κώδικα που ήδη υπάρχει για λόγους ιστορικότητας καλό είναι να μαρκάρεις τις αλλαγές που έκανες με το task και να γράφεις ένα μικρό documentation γιατί το έκανες. Για ενδεχόμενα roll back και τέτοια. Νομίζω είναι πολύ κουραστικός ένας κώδικας γεμάτος comment  και στο debug και στο development. Όσο αυξάνεται ένα object άρα και τα σχόλια από ένα σημείο και μετά δεν μπορείς ούτε να κάνεις scroll καλά καλά εκεί μέσα.
Όσον αφορά την αρχική ερώτηση του θέματος. Αν δεν υπάρχει κάποιος από τους από πάνω που να είναι διατεθειμένος να ασχοληθεί δεν μπορείς να κάνεις και πολλά, γιατί κανείς δεν σε λάβει στα υπόψιν του. Από εκεί και πέρα μπορείς είτε να κάνεις υπομονή, είτε να δεις αν στην εταιρεία σου μπορείς να πας σε κάποια άλλη ομάδα που να είναι καλύτερα ή ακόμα καλύτερα μόνος σου. Αλλιώς νομίζω είναι μονόδρομος η αλλαγή, αν όχι τώρα στα κοντά, τότε αργότερα.
Και έχεις δίκιο δεν μπορείς να δουλέψεις αποδοτικά για κανένα λόγο έτσι. Αλλά δυστυχώς δεν είναι στο χέρι σου.

Βασική αρχή όταν γράφω μέθοδο...όσο πιο μικρό είναι το function σε μέγεθος τόσο καλύτερο είναι ....και ξεκινάμε απο πιθανά bugs μέχρι την απόδοση...

Όσον αφορά τα σχόλια...εκεί υπάρχει 1 θέμα...και εγώ υπέρ των σχολίων στην πυρά αλλά υπάρχουν περιπτώσεις που χάνεις την μπάλλα όταν επισκέπτεσαι κώδικα μετά απο μήνες - χρόνια....και όλα τα ωραία περί source control πάνε ψιλοπερίπατο....

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

[GReaperEx]

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

http://wiki.c2.com/?LongFunctions

[albNik]

Μια που πιασατε τα σχολια πρεπει να πουμε πως κατι χειρότερο ειναι τα unit tests. Πας σε ενα ξένο κωδικα να προσθεσεις ενα feature, χαιρεσαι που το καταφερες πριν πεσουν τα μαλλιά και μετα αρχιζουν να κλοτσανε τα τεστ. Αναγκαζεσαι να τα πειραξεις ωστε να πρασινισουν αλλα μερικές φορες ειναι τοσο αθλια που απλα τα κανεις Assert(true) ή comment out.

 

Επεξ/σία 10 Δεκεμβρίου 2020 από albNik

[great]

8 ώρες πριν, masteripper είπε

αλλά υπάρχουν περιπτώσεις που χάνεις την μπάλλα όταν επισκέπτεσαι κώδικα μετά απο μήνες - χρόνια.

εαν μιλάμε για δικο μου κώδικα που εχω κανει για πρωσοπικι χρήση πάντως εχω δεκαετίας προγράμματα σε VB6 που τα ανοιγω τωρα και θυμαμαι ακριβως τι κανει αυτο και γιατι το ειχα κανει. Βεβαια το κουσούρι μου με τα variables να τα λεω κατι:

paizei
gami***e
arxi
telos
denmporeithapaiksei

το έχω στα δικά μου πάντα

[kaliakman]

10 ώρες πριν, albNik είπε

Μια που πιασατε τα σχολια πρεπει να πουμε πως κατι χειρότερο ειναι τα unit tests. Πας σε ενα ξένο κωδικα να προσθεσεις ενα feature, χαιρεσαι που το καταφερες πριν πεσουν τα μαλλιά και μετα αρχιζουν να κλοτσανε τα τεστ. Αναγκαζεσαι να τα πειραξεις ωστε να πρασινισουν αλλα μερικές φορες ειναι τοσο αθλια που απλα τα κανεις Assert(true) ή comment out.

 

Αν σπας τα tests με το καινούριο feature σου κάτι έχεις κάνει λάθος. Τα tests είναι εκεί ακριβώς ώστε να ξέρεις ότι αυτό που άλλαξες δεν τα σπάει. 

 

-------------------

Να πω και εγώ την γνώμη μου(κυρίως για library components αλλά και γενικότερα) : 

Σε κάθε αρχείο με λειτουργία υπάρχει top level documentation που εξηγεί τι κάνει γενικότερα η λειτουργία καθώς και examples για την χρήση. 

 

Σε κάθε συνάρτηση/ μέθοδο / whatever πάλι documentation τι παίρνει τι γυρνάει και τι κάνει. 

Το documentation παραγεται με εργαλεία που κάνουν parse αυτά τα σχόλια. 

Όταν κανείς import / include / whatever κοιτάς το κώδικα και το εκεί documentation και όχι εξωτερικά. 

Αν αλλάξεις κάτι και δεν αλλάξεις το documentation δεν περνάει το code review οπότε το να φτάσεις σε κακό state είναι αδύνατο. 

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

[MitsarasAth]

μιας υπαρχει το debate πλεον για τα comments στον κωδικα ας ποσταρω αυτο 😛

https://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered

[albNik]

5 ώρες πριν, kaliakman είπε

Αν σπας τα tests με το καινούριο feature σου κάτι έχεις κάνει λάθος. Τα tests είναι εκεί ακριβώς ώστε να ξέρεις ότι αυτό που άλλαξες δεν τα σπάει. 

Στην πραξη ειναι πιο περίπλοκο. Το feature λεει οτι τωρα οταν καλεις το a θα εκτελεις τα x'y'z' αντι για xy που ηταν πριν. Στα τεστ δεν ειναι τοσο ευκολη η αντικαταστάση xy-->x'y'z'. Όσο περισσότερα τεστ τόσο πιο δυσκολα

[Predatorkill]

5 ώρες πριν, MitsarasAth είπε

μιας υπαρχει το debate πλεον για τα comments στον κωδικα ας ποσταρω αυτο 😛

https://stackoverflow.com/questions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered

Εχω βαλει σχολιο σε ενα endpoint που ειχε να κανει με eshop product variants το κινητο μου και «οποιος δε καταλαβαινει Χριστο να με παρει τηλεφωνο». Ακομα να με παρει καποιος