Προς το περιεχόμενο
  • Εγγραφή
  • 0

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


Επισκέπτης

Ερώτηση

Ανοίγω το συγκεκριμένο νήμα γιατί θα ήθελα να θίξω το θέμα του τίτλου.

Επειδή δεν μου αρέσει να μακρυγορώ, με λίγα λόγια θα προσπαθήσω να περιγράψω τη δική μου εμπειρία.

Εργάζομαι σ'ένα ολιγομελή τμήμα ανάπτυξης κώδικα και συντήρησης μιας εταιρείας σε συναφή κλάδο με την Πληροφορική. Η δουλειά σχετικά "βγαίνει" αλλά λόγω παραγόντων όπως έλλειψη οργάνωσης, λίγα χέρια, μη ορθολογική ανάπτυξη, ανύπαρκτο security, καθόλου documentation/σχόλια... δεν μπορώ να πω ότι είμαι ικανοποιημένος. Δεδομένου ότι κάτι αντίστοιχο συνέβαινε και στην προηγούμενη εταιρεία που ήμουν, αρχίζω να αναρωτιέμαι πως είναι εφικτό να δουλέψει ένας προγραμματιστής αποδοτικά και τυπικά υπό αυτές τις συνθήκες.

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

Πως αντιμετωπίζεται μια τέτοια κατάσταση;  Θα με ενδιέφερε να ακούσω τις δικές σας επαγγελματικές εμπειρίες αλλά και απόψεις επί του θέματος.

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • Απαντήσεις 50
  • Δημιουργία
  • Τελευταία απάντηση

Συχνή συμμετοχή στην ερώτηση

Συχνή συμμετοχή στην ερώτηση

Δημοφιλή Μηνύματα

Το ότι ο σωστός κώδικας είναι περιγραφικός από μόνος του και δεν χρειάζεται σχόλια, και ότι τα σχολια είναι code smell, ειναι απο τις μεγαλυτερες μπαρουφες ever, που καποιος εγραψε και απο τοτε εχει γ

Τα σχόλια θα μπουν στο task description. Το task θα έχει συγκεκριμένα specs, ώστε να ξέρει ο καθένας το πρέπει να παραδώσει. Είμαστε στο 2020 και υπάρχουν συγκεκριμένα process και εργαλεια για project

Καλά πως. Σχόλια δεν γράφεις (μόνο) για να εξηγείς πως κανεις κάτι, αλλά και γιατί. Πχ έχεις διαλέξει ένα magic number σε configuration: γράψε γιατί. Σε ένα απι για παράδειγμα μπορεί να παίρνεις σαν α

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

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

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

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

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

  • Like 1
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
Δημοσ. (επεξεργασμένο)
2 ώρες πριν, asxs είπε

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

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

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

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

Επεξ/σία από ghostaki
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
Δημοσ. (επεξεργασμένο)

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


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

Επεξ/σία από MitsarasAth
  • Like 1
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
Δημοσ. (επεξεργασμένο)

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

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

Επεξ/σία από Predatorkill
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • -1
Δημοσ. (επεξεργασμένο)

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

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

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

 

 

Επεξ/σία από AgiosEfraim
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
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...να μπορείς να γράφεις αυτό που πρέπει αλλά να μην σε εμποδίζει στην ανάγνωση του κώδικα.

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0

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

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

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
Δημοσ. (επεξεργασμένο)

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

 

Επεξ/σία από albNik
  • Haha 1
  • Confused 1
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
8 ώρες πριν, masteripper είπε

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

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

paizei
gami***e
arxi
telos
denmporeithapaiksei

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

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
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. 

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0

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

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

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • -1
5 ώρες πριν, kaliakman είπε

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

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

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
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 το κινητο μου και «οποιος δε καταλαβαινει Χριστο να με παρει τηλεφωνο». Ακομα να με παρει καποιος

  • Haha 1
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
25 λεπτά πριν, albNik είπε

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

To test υπάρχει γιατί αν η μέθοδος που είχες έκανε x + y τότε τεσταρει ότι δουλεύει το x + y  . Αν έβαλες στην μέθοδο να κάνει και + z , τότε καλά κάνει το τεστ και σκάει και πρέπει να το φτιάξεις και αυτό.

Και είσαι τυχερός αν βρίσκεται σε codebase που έχει χιλιάδες tests γιατί όταν αλλάζεις κάτι γνωρίζεις ότι κάτι έσπασες

Απλά όσο καλογραμμένος είναι ο κώδικας σου άλλο τόσο καλογραμμένα είναι τα τεστ , και αρκετές φορές στην προσπάθεια να γράψεις καλά unit tests φτιάχνεις και καλύτερο κώδικα

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

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

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

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

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

Εγγραφείτε για έναν νέο λογαριασμό

Σύνδεση

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

Συνδεθείτε τώρα

  • Δημιουργία νέου...

Με την περιήγησή σας στο insomnia.gr, αποδέχεστε τη χρήση cookies που ενισχύουν σημαντικά την εμπειρία χρήσης.