Legacy app thread

[PC_MAGAS]

Εκεί που εργάζετε ασχολείστε με παλιό κώδικα και frameworks αν ναι πόσο;
Αν ναι πόσο καθαρός ο κώδικας είναι, παρόλο που είναι legacy η εφαρμογή;

 

Τέλος έχετε αρκετό stuff ώστε να συντειρείτε τόσον παλιόν κώδικα;

[thanasis00]

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

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

Το πρώτο πιο δύσκολο είναι οι out of date βιβλιοθήκες, όπου αν κάπως σπάσει κάτι και χρειαστεί κάποια βιβλιοθήκη upgrade, γίνεται λίγο χάος η κατάσταση, μέχρι να γίνει migrate το codebase στη νεότερη έκδοση της βιβλιοθήκης, και να υποστηριχτεί η υποδομή για την αλλαγή.

Το δεύτερο είναι το maintenance των μηχανημάτων δοκιμαστικού και παραγωγικού περιβάλλοντος, καθώς αν κάποια dependencies αλλάξουν, είναι μια διαδικασία για να καταφέρει να γίνει migrate το state της υποδομής (debian packaging ftw).

Και το τρίτο πιο δύσκολο είναι το dev environment σε παλιά projects, καθώς υπάρχουν και έργα προ 10ετίας, που είναι σχεδόν αδύνατον να στήσεις ένα dev environment στο pc σου, οπότε πρέπει να παίξουν αλχημείες με docker για να τρέξεις τέτοια legacy projects, διαδικασία που παίρνει χαλαρά μία βδομάδα, αν το project απαιτεί και διασυνδέσεις με άλλα εργαλεία...

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

Και τέλος υπάρχουν και projects που το codebase είναι σταθερό εδώ και χρόνια, αλλά για να είσαι up to date με security updates στο production, έχει αρκετό κόπο στο upgrade των βιβλιοθηκών για να τρέχει latest secure software... 

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

[ALLisCHAOS]

Στην παλιά μου δουλειά το Core product της εταιρείας ήταν ο ορισμός της λεγκασίλας (και εξακολουθεί να είναι).
Φτιαγμένο απο το 1995 με Java Swing και ένα custom ORM.
Ακόμη και το UI του εξακολουθεί να είναι το ίδιο με τότε (βέβαια εδώ παίζει ρόλο και η δύναμη της συνήθειας των πελατών που δεν θέλουν κάτι καινούργιο μην χρειαστεί και ξανά κάνουν training το προσωπικό). Μιλάμε για ένα τεράστιο project με undocumented κώδικα στα περισσότερα σημεία και με την υπέροχη God class (Order) η οποία τελευταία φορά που την είχα κοιτάξει ήταν στις 15000 γράμμες. Το πιο τρομακτικό ήταν όταν σου ζητούσανε να βάλεις ένα καινούργιο feature ή να κάνεις μικρά fixes, ποτέ δεν ήσουν σίγουρος τι μπορεί να χάλασε αυτή η μικρή αλλαγή ή αυτός ο νέος κώδικας που χρησιμοποιεί τα ήδη υπάρχον. Βασικά τώρα που το ξανασκέφτομαι υπήρχε και πιο τρομακτικό, να μην σου δουλεύει κάτι στο επίπεδο του ORM, όπου η μόνη σου λύση ήταν ή να ρωτήσεις τον CTO (ο δημιουργός ο οποίος θα σου απαντούσε όποτε θυμόταν) ή να ξεκινήσεις να σκάβεις μόνος σου στο implementation του για να δεις που τελικά είναι το πρόβλημα... Unit/integration tests εννοείται ούτε για δείγμα, ευτυχώς υπήρχε code review και QA department για testing αλλά γενικά δεν περνούσες πολύ ωραία (εγώ τουλάχιστον).
Το καλό ήταν ότι η Java που χρησιμοποιούσαν ήταν η 8 και ότι στο Web ordering κομμάτι τα πράγματα ήταν πιο εξελιγμένα με Spring και Angular 2.
Στην εν λόγο εταιρεία συνάντησα και για πρώτη φορά αυτά τα Component base frameworks (πχ Wicket, Vaadin)  που ήταν της μόδα κάπου στο 2008-2010? Ξέρετε εκείνα που σου επέτραν να έχεις με ένα κοινό stack (Java) και back-end και front-end. Υπήρχε η κλάση Textbox πχ την οποία οποτε την χρησιμοποιούσες μπορούσες να δώσεις στον client ένα textbox html element με όλα τα events κλπ. Ήταν πραγματικά ότι πιο διεστραμένο έχει σκεφτεί ο ανθρώπινος νους και ότι πιο 'σαπιο' έχω δουλέψει ποτέ. Ίσως για πολύ base πραγματα να ήταν καλό αλλά πραγματικά όταν ζητούσαν διάφορα πράγματα (ειδικά για το front-end κομμάτι) απλά προσπαθούσες να χακάρεις το σύμπαν και να το κάνεις να παίξει. Ας μην μιλήσω για υποστήριξει στο stack-overflow και γενικά online... Ευτυχώς μετά απο κάποιο καιρό είδαν οτι δεν προχωράει έτσι το πράγμα και το σουτάραμε και το ξανά γράψαμε σε REST APIs και SPA. 

Γενικά στις περισσότερες μεγάλες εταιρείες δυστυχώς το legacy δεν θα το γλιτώσεις. Θυμάμαι να κάνω συνέντευξη με μια μεγάλη εταιρεία του χώρου η οποία παίρνει εργα με δημόσιους φορείς σε όλη την ΕΕ και να μου λένε οτι υπάρχουν project (καινούργια) στα οποία θα χρησιμοποιήσεις πιο latest τεχνολογίες και υπάρχουν και άλλα στα οποία είμαστε με Java 5 ή με αυτά τα Components base frameworks (wicket). Όσα λεφτά και να μου έδιναν ο μόνος λόγος που θα γυρνούσα σε κάτι τέτοιο ήταν αν δεν έβρισκα αλλού δουλειά και δεν είχα να φάω. Δεν μπορώ να καταλάβω κάποιον που να ευχαριστιέται μια μέρα σε τέτοια δουλειά. Εκτός και αν θέλει να μαζέυει ιστορίες και να τις λεει όταν βγαίνουν έξω με συναδέλφους για το τι έπρεπε να κάνει για να δουλέψει το Χ. Αλλά περί ορέξεως...
 

[Predatorkill]

@thanasis00

Γιατι ολα τα παλια projects δεν ξαναγραφονται απο την αρχη και σπαταλιεται τοσος χρονος στο maintain/νεα features?

Δε λεω ολοι να στραφουν εκει, γιατι δεν προσλαμβανουν ομως κοσμο μονο για αυτο; 
 

οτι κρατικο site υπαρχει ειναι ολα με εξωτερικους συνεργατες ή εχει το κρατος δικο του δυναμικο;

[thanasis00]

27 λεπτά πριν, Predatorkill είπε

Γιατι ολα τα παλια projects δεν ξαναγραφονται απο την αρχη και σπαταλιεται τοσος χρονος στο maintain/νεα features?

Δε λεω ολοι να στραφουν εκει, γιατι δεν προσλαμβανουν ομως κοσμο μονο για αυτο; 

Γενικά στο δημόσιο, ο κύκλος ανάπτυξης ενός λογισμικού περιλαμβάνει διάφορα στάδια, όπως ο επιχειρησιακός σχεδιασμός, ο τεχνικός σχεδιασμός, η εύρεση ομάδας ανάπτυξης και ομάδας παρακολούθησης, ο καθορισμός των παραδοτέων ανά περίοδο ανάπτυξης κλπ, έτσι ώστε το τελικό αποτέλεσμα να είναι τουλάχιστον ισάξιο, αν όχι ανώτερο του υπάρχοντος λογισμικού. Οπότε όταν μιλάμε για επανασχεδιασμό/επανανάπτυξη μια ήδη υπάρχουσας υπηρεσίας, περιλαμβάνει αρκετό κόσμο που πρέπει να διαθέσει αρκετές εργατοώρες για τα προπαρασκευαστικά στάδια, πριν καν φτάσουμε στο κομμάτι της ανάπτυξης. Δεδομένων των συνθηκών από covid και μετά, η ψηφιακή διακυβέρνηση έχει πάρει τεράστιες διαστάσεις σχεδόν σε όλους τους δημόσιους φορείς, οπότε το μεγαλύτερο ποσοστό των εργατοωρών προορίζεται στην ανάπτυξη νέων υπηρεσιών που περιλαμβάνονται στη τεράστια ομπρέλα gov.gr. 

Συνεπώς, αυτή τη δεδομένη χρονική περίοδο, είναι πολύ πιο εύκολο να δώσεις σε 1 ή 2 άτομα να κάνουν υποστήριξη σε μια legacy εφαρμογή, με σκοπό να μπορείς να χρησιμοποιήσεις το μεγαλύτερο μέρος των συνεργατών στα πιο επίκαιρα έργα. Δυστυχώς το φαίνομενο "πετάω έξτρα 10 ανθρώπους σε ένα πρόβλημα για να λυθεί", ναι μεν ακούγεται εφικτό, αλλά αν μιλάμε για ανθρώπους που πχ δεν έχουν ιδέα για το υπάρχον πληροφοριακό σύστημα που πρέπει να εξυγχρονιστεί, ή δεν έχουν ιδέα για τον επιχειρησιακό σκοπό και το παραδοτέο της υπηρεσίας που πρέπει να αναβαθμιστεί, αυτομάτως βλέπουμε ότι θα πρέπει να υπάρξει ένα graceful period αρκετών εργατοωρών για να μπορέσει να ξεκινήσει ένας παραγωγικός κύκλος ανάπτυξης στο συγκεκριμένο κομμάτι. Επίσης, κάποιες φορές το να ζητήσεις έξτρα κόσμο για αναβάθμιση παλιών υπηρεσιών που έχουν μικρό αριθμό επισκεψιμότητας, δεν είναι και η καλύτερη επιλογή. Συνεπώς καταλήγω στο ότι τη δεδομένη χρονική στιγμή δε χρειάζεται άμεσα η επανυλοποίηση κάποιων legacy υπηρεσιών, αλλά όταν βρεθεί χρόνος και το κατάλληλο capacity είναι πάντα σε συζήτηση το τι μπορεί να ξαναγραφτεί.

27 λεπτά πριν, Predatorkill είπε

κρατικο site υπαρχει ειναι ολα με εξωτερικους συνεργατες ή εχει το κρατος δικο του δυναμικο;

Γενικά το κράτος δουλεύει πολύ με δημόσιους φορείς, που είναι πρακτικά ιδιωτικές εταιρείες δημοσίου δικαίου. Δηλαδή πραγματικά δεν έχουν δικά τους έργα, αλλά παίρνουν κονδύλια από το κράτος για την υλοποίηση έργων. Υπάρχει όμως εργατικό δυναμικό στον τομέα της πληροφορικής που είναι δημόσιοι υπάλληλοι, και είναι και σε διάφορες ειδικότητες, από προγραμματιστές μέχρι system administrators. Κυρίως ανήκουν σε μεγάλα υπουργεία (πχ Οικονομικών ή Ηλ. Διακυβέρνησης) που υποστηρίζουν κάποιες in house υπηρεσίες, ή υπηρεσίες που αναπτύχθηκαν εσωτερικά για λογαριασμό του κράτους. Όμως η πλειοψηφία των έργων πηγαίνει στους αρμόδιους δημόσιους φορείς, που έχουν την ιδιαιτερότητα να είναι πιο ευέλικτοι στο εργατικό δυναμικό (εξωτερικοί συνεργάτες), έτσι ώστε να μπορούν να ρυθμίζουν πρακτικά το capacity των ανθρώπων ανάλογα με τις ανάγκες του εκάτοστε έργου, γιατί συνήθως τα έργα έχουν μεγάλο capacity στην ανάπτυξη και αρκετά μικρότερο στη συντήρηση, οπότε και γίνονται κάποιες φορές handover στο δημόσιο για να συνεχίσει να υποστηρίζεται.

Επεξ/σία 1 Αυγούστου 2021 από thanasis00

[Predatorkill]

Ευχαριστω @thanasis00, ησουν κατατοπιστικος. 
 

Τελευταιες αποριες, γιατι καποιες νεες υπηρεσιες δεν αντεχουν το traffic και πεφτουν; Δεν «τρεχουν» ολες μεσα σε συγκεκριμενα πλαισια «κατω» απο τον ιδιο διαχειριστη; 
 

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

Επεξ/σία 1 Αυγούστου 2021 από Predatorkill

[thanasis00]

19 λεπτά πριν, Predatorkill είπε

Τελευταιες αποριες, γιατι καποιες νεες υπηρεσιες δεν αντεχουν το traffic και πεφτουν; Δεν «τρεχουν» ολες μεσα σε συγκεκριμενα πλαισια «κατω» απο τον ιδιο διαχειριστη; 

Το μεγαλύτερο πρόβλημα που έχουμε διαπιστώσει εμείς, είναι συνήθως ότι κάποιες διαλειτουργικότητες δεν αντέχουν το traffic και πέφτουν, ή κάποιες φορές πέφτουν πολύ έξω όσον αφορά τις απαιτήσεις στα requests per second, και δε κάνουν το απαραίτητο scaling (όχι ότι είναι εύκολο να επιβεβαιώσεις με το current scale πόσο κόσμο αντέχει η υπηρεσία, όταν αναφερόμαστε για μεγέθη εθνικού πλυθησμού επισκεψιμότητας). Δηλαδή εσύ μπορεί να σχεδιάζεις μια υπηρεσία η οποία επικοινωνεί με 3-4 άλλες δημόσιες υπηρεσίες (πχ taxisnet, εφκα, αστυνομία κλπ) και αυτές οι υπηρεσίες είτε έχουν πολύ αργό response time είτε πέφτουν εντελώς, χάνεις την επικοινωνία οπότε δημιουργούνται διάφορα προβλήματα. Τώρα αυτό το ζήτημα είναι αρκετά σύνθετο, γιατί η κάθε διαλειτουργικότητα έχει μία ή περισσότερες υπηρεσίες που φέρνουν τα αποτελέσματα, οπότε μπορεί να μην είναι εύκολο το scaling και να χρειάζεται manual δουλειά για να μπορεί να ανταποκριθεί στα αιτήματα. Όμως όταν τα χρονικά περιθώρια είναι στενά, όπως συμβαίνει στη covid περίοδο και στη κυριολεξία τρέχουμε και δε φτάνουμε (ούτε οι φορείς ούτε τα υπουργεία), είναι λογικό να μη γίνεται ο σωστός σχεδιασμός εξ αρχής και να προκύπτουν τα προβλήματα που αναφέρεις.

EDIT: Δεν απάντησα για το κομμάτι του ίδιου διαχειριστή. Γενικά οι υπηρεσίες τρέχουν σε 3-4 σημεία, από in-house datacenters μέχρι amazon/microsoft cloud. Όμως εξαρτάται πάρα πολύ και πόσο optimized είναι το κάθε έργο. Αν πχ ο ανάδοχος δεν το έκανε optimize και χτυπάει κάποιο εξωτερικό endpoint περισσότερες φορές απ' όσο έπρεπε, δημιουργεί αχρείαστο traffic με τις όποιες συνέπειες. Επίσης πολλές φορές ο ανάδοχος δεν δίνει σωστές προδιαγραφές για τις απαιτήσεις των συστημάτων, και καταλήγει να πέφτει έξω...

19 λεπτά πριν, Predatorkill είπε

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

Εδώ δυστυχώς δε μπορούν να γίνουν πολλά, γιατί δυστυχώς δε μπορείς να περιγράψεις στα απαιτούμενα του έργου "να είναι καλός ο κώδικας". Όλοι οι διαγωνισμοί είναι μειοδοτικοί, δηλαδή η φθηνότερη προσφορά κερδίζει, και ο κάθε ανάδοχος συνήθως κάνει το bare minimum για να καλύψει τις απαιτήσεις του έργου. Οπότε αναλαμβάνεις μια υπηρεσία που πρακτικά κάνει αυτό που πρέπει, αλλά μπορεί ο κώδικας να μην είναι επεκτάσιμος ή εύκολα συντηρήσιμος... Ευτυχώς υπάρχουν κάποιες μικρές δικλείδες ασφαλείας που μπορείς να απαιτήσεις, πχ το έργο να υλοποιηθεί με συγκεκριμένο toolset, που έχεις και εσύ in-house, ή ακόμα καλύτερα να απαιτήσεις από τον ανάδοχο να χρησιμοποιήσει δικές σου βιβλιοθήκες για την ανάπτυξη, οπότε κάπως φέρνεις το έργο στα δικά σου μέτρα, ανάλογα με το context πάντα βέβαια.

Επεξ/σία 1 Αυγούστου 2021 από thanasis00

[PC_MAGAS]

Συνήθως legacy undocumented κομμάτια τα κάνω τackle ως εξής:

1. Διαβάζω κομμάτι κώδικα
2. Σημειώνω google docs αν είναι το ίδιο feature τότε το σημειώνω σε ίδιο document.
3. Κάνω share με το team.

Αυτό παίζει αν εσύ που το κάνεις μένεις αρκετό χρόνο στην εταιρεία έτσι over time αποκτάς μια ιδέα το τι παίζει τι και μειώνεις το bus factor με shared notes. Βέβαια, το document είναι σαν παζλ που το χτίζεις ανάγωγα με το χρόνο/κομμάτια που έχεις δει.

 

Ακόμα κάνω document και διαδικασία manual testing αν δεν υπάρχουν unit tests. Ακόμα δε κάνω και scriptάκια για database population as well ώστε να κάνω το manual testing ευκολότερο.

 

Τέλος, the best specs are Sentry και Γιατί δεν παίζει το π**** δηλαδή μέσω telemetry να αλιεύεις specs.

Καθαρά specs δεν θα λάβεις εις τον αιώνα τον απάντα. Όμως refactor με telemetey, logs και shared notes κάνεις small piece over time, απλά πληρώνεις χε χρόνο/χρόνια σε μικρές δόσεις. Πχ το να log άρω σε βάση σφάλματα σε PHP app has saved my ass. Σε απλά ελληνικά κάνε printf σε db/file για να δεις πως πέζει σε production.

 

Αυτό είναι το τι έχω μάθει από την απειροελάχιστη εμπειρία μου. Code will be always shitty, read, log and unfuck it.

Επεξ/σία 21 Αυγούστου 2021 από PC_MAGAS

[MitsarasAth]

πιστευω παντως πως οι εταιρειες που εχουν δικο τους προιον και το πουλανε χωρις refactor σε νεες τεχνολογιες απλα μελλοντικα δεν θα πανε πουθενα.
κυριως legaciles θα δεις σε τραπεζες που δεν θελουν να μπουνε στην διαδικασια του refactor κια να παρουν την ευθυνη για οτιδηποτε συμβει, και εταιρειες που δεν εχουν το software σαν προοιον αλλα σαν υποστηρικτικα εργαλεια πχ κατι backoffice με ui που παθαινεις ευκολα επιλειψια