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

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


Επισκέπτης

Ερώτηση

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

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

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

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

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

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

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

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

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

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

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

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

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

  • -1
3 ώρες πριν, tsofras είπε

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

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

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

Και ποιος θα τεσταρει το τεστ οτι τεσταρει σωστα το x+y 😃 

Θέλω να πω ότι το τεστ μπορει να εχει παραπλήσια η και μεγαλύτερη δυσκολία με το ιδιο το πρόγραμμα. 

 

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

Και ποιος θα τεσταρει το τεστ οτι τεσταρει σωστα το x+y 😃 

Θέλω να πω ότι το τεστ μπορει να εχει παραπλήσια η και μεγαλύτερη δυσκολία με το ιδιο το πρόγραμμα. 

 

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

Το βράδυ όμως που τρέχεις την σουίτα σου είσαι ήσυχος ότι όλα είναι όπως πρέπει

Έχω πετύχει και προγραμματιστές που βλέπουν τεστ να σκάνε και τα φτιάχνουν απλά για να περάσουν δεν έχει να λέει κάτι αυτό

Η λογική είναι να γράφεις σωστά τεστ για να έχεις το κεφάλι σου ήσυχο

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

Και ποιος θα τεσταρει το τεστ οτι τεσταρει σωστα το x+y 😃 

Θέλω να πω ότι το τεστ μπορει να εχει παραπλήσια η και μεγαλύτερη δυσκολία με το ιδιο το πρόγραμμα. 

 

Γι' αυτό γράφεις πρώτα το test 😛

Ελέγχεις συμπεριφορά, όχι υλοποίηση. Ναι σίγουρα μπορεί να έχεις περίπλοκα use cases και σίγουρα μπορεί να γίνει λάθος, αλλά είναι μια ακόμη δικλείδα ασφαλείας πολύ πιο ισχυρή από το μυαλό του κάθε developer που θα ελέγξει την ορθότητα ενός κομματιού κώδικα με το μυαλό του.

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

Τα unit testing ειναι μια αλλη πονεμενη ιστορια. Προφανως δεν υπαρχει 100% καλυψη, και αμα αυτο προσπαθεις κανεις κατι πολυ λαθως και σπαταλας χρονο και χρημα να το πουμε απλα. Τα unit testings ειναι ενα συμπληρωματικο εργαλειο, και σε καμια περιπτωση δεν πρεπει να θεωρουμε οτι αμα τρεχουν, τοτε ο κωδικας μας ειναι σωστος. Απλα σημαινει οτι τα cases που σκεφτηκαμε δουλευουν, ελα ομως τα cases που μπορουμε να σκεφτουμε ειναι αυτα που αμα το συστημα δουλεψει μια ωρα θα παρουσιαστουν ολα. Τα δυσκολα edge cases, που προκαλουν τον μεγαλητερο πονο ουτε καν συνηθως σου περνανε απο το μυαλο, και προφανως δεν καλυπτωνται απο unit testing. Σωστο και αναλυτικο exception handling ειναι πιο σημαντικο. 

Λίγα integration tests και λιγα unit tests και σωστο exception handling >>>> 100% unit test coverage. 

Bugs πάντα θα υπάρχουνε. Σωστο exception handling θα σε βοηθησει να εντωπισεις ευκολoτερα τα bugs. Ειδικα πλεον στα cloud services, με ολα τα hidden external dependencies. Integrations testing ftw. 

Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
Στις 11/12/2020 στις 9:08 ΠΜ, Papakaliati είπε

Τα unit testing ειναι μια αλλη πονεμενη ιστορια. Προφανως δεν υπαρχει 100% καλυψη, και αμα αυτο προσπαθεις κανεις κατι πολυ λαθως και σπαταλας χρονο και χρημα να το πουμε απλα. Τα unit testings ειναι ενα συμπληρωματικο εργαλειο, και σε καμια περιπτωση δεν πρεπει να θεωρουμε οτι αμα τρεχουν, τοτε ο κωδικας μας ειναι σωστος. Απλα σημαινει οτι τα cases που σκεφτηκαμε δουλευουν, ελα ομως τα cases που μπορουμε να σκεφτουμε ειναι αυτα που αμα το συστημα δουλεψει μια ωρα θα παρουσιαστουν ολα. Τα δυσκολα edge cases, που προκαλουν τον μεγαλητερο πονο ουτε καν συνηθως σου περνανε απο το μυαλο, και προφανως δεν καλυπτωνται απο unit testing. Σωστο και αναλυτικο exception handling ειναι πιο σημαντικο. 

Λίγα integration tests και λιγα unit tests και σωστο exception handling >>>> 100% unit test coverage. 

Bugs πάντα θα υπάρχουνε. Σωστο exception handling θα σε βοηθησει να εντωπισεις ευκολoτερα τα bugs. Ειδικα πλεον στα cloud services, με ολα τα hidden external dependencies. Integrations testing ftw. 

Διαφωνώ. Εάν καθήσεις και καλύψεις κάθε πιθανή περιπτωση του function σου σε test cases τότε οι πιθανότητες να πάει κάτι στραβά σίγουρα λιγοστεύουν. Σαφώς και τέλειο (bugs free) software δεν υπάρχει. Σκοπός όμως είναι να το κάνουμε με όσο δυνατόν λιγότερα bugs γίνεται και το testing (unit tests + integration tests) βοηθάνε φουλ. Αυτό που έχω παρατηρήσει εγώ είναι ότι τις περισσότερες φορές το αίτιο για τα bugs είναι αυτο το ριμάδι το state του application μας το οποίο τις περισσότερες φορές επειρεάζει το output των function μας ή με 2 λόγια, δεν γράφουμε pure functions και χρησιμοποιούμε τόσο πολύ mutable data structures... Ένας λόγος που έχω αγαπήσει το functional programming + clojure είναι ότι προωθούν ακριβώς αυτό το στυλ, immutable data και pure functions! Το οποίο με τη σειρά του πιστεύω σε ωθεί σε ένα καλύτερο product με λιγότερα bugs 

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

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

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

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

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

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

Σύνδεση

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

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

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

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