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

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


Επισκέπτης

Ερώτηση

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 0
1 ώρα πριν, asxs είπε

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

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

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

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

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

Φίλε ακόμα και ελληνικές εταιρίες leaders σε κλάδους έχουν οργάνωση τουλάχιστον μπο*ρδέλου.

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

Αυτά που λες δεν είναι τίποτα.

Σε μια εταιρία δεν δούλευε σωστά το Internet.

Δεν έγραψα λάθος.

Δεν ήξερες αν το επόμενο 5λεπτο θα είχες Internet ή θα είχε πέσει.

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

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

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

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

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

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

Οι εταιρείες (ειδικά οι μικρότερου μεγέθους) επιτρέπουν αυτό το χάος γιατί βγαίνει η δουλειά όπως λες και άρα υπάρχουν τα απαιτούμενα κέρδη.

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

Για τα προβλήματα που αναφέρεις, παντού θα συναντήσεις διάφορες παρόμοιες καταστάσεις. Μπορεί κάπου να είναι καλά στο κομμάτι του documentation ή του stack, αλλά ταυτόχρονα να υπάρχει άρρωστη κουλτούρα γενικότερα σε συμπεριφορές, πίεση κ.λπ.

Αυτό που μπορείς να κάνεις είναι όταν σου δίνεται το βήμα, να εκφράζεις με επιχειρήματα τα προβλήματα που αντιμετωπίζεις (πχ σε ένα Retrospective event αν κάνετε Agile, μάλλον πολλά ζητάω βέβαια, ή μέσω μέιλ στον team leader/line manager σου).

Αν αυτα τα προβλήματα παραμένουν και όντως δεν την παλεύεις, απλά παράλληλα με την δουλειά σου, ψάχνεις για αλλού!

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

Επίσης να σημειώσουμε στο σημείο αυτό, ότι όλο αυτό που συζητάμε λέγεται management πληροφορικής και συνήθως στις Ελληνικές εταιρίες είναι ανύπαρκτο με αποτέλεσμα developers να μην βάζουν καθόλου σχόλια ποτέ και πουθενά (από στρατηγική επιλογή), έτσι ώστε να 'δένονται' με την εταιρία και να μην μπορεί να τους απολύσει, αφού μόνο αυτοί γνωρίζουν πως δουλεύουν τα περισσότερα πράγματα.

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

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

Τα πράγματα είναι απλά....κάποιος/α κάπου κάποτε κάνει κάτι ή το βρίσκει έτοιμο...του/της βγαίνει...και μετά ο κόσμος είναι δικός του/της.

Όλα τα άλλα είναι οδοντόκρεμες...κάνεις υπομονή...μαζεύεις γνώσεις εμπειρίες και μόλις μπορείς την κάνεις....αν δεν μπορείς καλά θα ήταν να επενδύεις τον χρόνο σου και σε παράπλευρες δραστηριότητες (freelancing)

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

Η εταιρία που δούλευα πριν, χτίζει προϊόντα που πωλούνται σε μέρη όπως ο Αμερικανικός στρατός και είναι το ίδιο με αυτό που περιγράφεις και χειρότερα.

Ο (Έλληνας) Manager για το development team στην Ευρώπη είναι καραγκιόζης και δεν θέλει καν να σκεφτεί τις προτάσεις που του κάναμε για την αλλαγή μεγάλων legacy τμημάτων στον κώδικα του προϊόντος, με αποτέλεσμα να πρέπει να ξοδεύουμε ατελείωτες ώρες με workarounds για αυτονόητα πράγματα. Η εταιρία είναι μέλος κολοσσού με 14 δις ετήσιο τζίρο και παρόλα αυτά, ήταν λες και μου είχανε δώσει να σκάψω έναν λάκκο με κουταλάκι του γλυκού. 

Από το να προσπαθείς να αλλάξεις την κατάσταση που βρίσκεται η εταιρία, καλύτερα ψάξε να πας αλλού. 

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

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

Βασικά, αν ο κώδικας θέλει σχόλια, κάτι λάθος έχει γίνει. Όλα τα best practices και linters δηλώνουν ότι αυξάνουν το θόρυβο. 

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

Βασικά, αν ο κώδικας θέλει σχόλια, κάτι λάθος έχει γίνει. Όλα τα best practices και linters δηλώνουν ότι αυξάνουν το θόρυβο. 

Εισαι πολυ λαθος. Πιασε μεγαλα repos και δες ποσα κιλα σχολια εχουν μεσα. Το σχολιο το γραφεις και για τον εαυτο σου, οχι μονο για τους αλλους.

δες πχ την (σχεδον καρδια) της react:

https://github.com/facebook/react/blob/master/packages/react-dom/src/client/ReactDOMComponent.js

 

εδω react-native-firebase:

https://github.com/invertase/react-native-firebase/blob/master/packages/firestore/lib/index.d.ts

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

Εισαι ποκυ λαθος. Πιασε μεγαλα repos και δες ποσα κιλα σχολια εχουν μεσα. Το σχολιο το γραφεις και για τον εαυτο σου, οχι μονο για τους αλλους.

Για αυτό λέμε για το management της πληροφορικής.

Φαντάσου να είσαι στο ίδιο team με τον από πάνω και να μη σου βάζει σχόλια ποτέ!

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

Και επίσης πιθανότατα εγωίσταρος.

Επεξ/σία από skiabox
  • Like 4
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • -1

Γενικά νομίζω ότι η ύπαρξη σχολίων είναι code smell. Είναι μια πολύ πιο εύκολη κι ελκυστική λύση από το να φτιάξεις σωστά τον κώδικά σου. Κάνεις μία μαγεία κι αντί να τη φτιάξεις σωστά πετάς ένα σχόλιο και καθάρισες. Σίγουρα υπάρχουν legit χρήσεις των σχολίων, αλλά η αλήθεια είναι ότι δυσκολεύομαι να τις δω αν έχεις έναν σωστό κώδικα και σωστό documentation. Προφανώς αυτό δεν είναι πάντα εφικτό, ειδικά σε legacy συστήματα που γίνεται ο κακός χαμός. Αυτό δε σημαίνει ότι το "σωστό" είναι ένα σχόλιο κι όχι ένα refactor. Απλώς επειδή πολλές φορές αυτό είναι πρακτικά αδύνατο, το next best thing είναι να βάλεις ένα σχόλιο.

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

Και εγώ θα συμφωνήσω για τα σχόλια. Αν είναι καλο-γραμμένος ο κώδικας με σωστά design pattern δεν χρειάζονται. Δούλευα σε εταιρεία που είχε εκατομμύρια κλάσεις στο προϊόν της, δεν είχε ούτε μια γραμμή σχόλιο και καταλάβαινες απόλυτα τι γίνεται!
Βέβαια δεν ανέβαινε τίποτα στο develop branch χωρίς code review (κάτι που οι περισσότερες ελληνικές εταιρείες δεν γνωρίζουν καν τι είναι) και αν δεν ακολουθούσες best practises η έστω 1 κενό η μια παρένθεση να μην ήταν στοιχισμένη, σε έστελνε πίσω να το διορθώσεις.



Τώρα όσο αφορά τον ts, εγώ άλλαξα δουλειά τον Σεπτέμβρη και γενικώς υπάρχει πολύ μεγάλη κινητικότητα στην αγορά. Έχω πολλούς φίλους και γνωστούς που έφυγαν από τις εταιρείες που ήταν και ξεκίνησαν σε καινούριες , μέσα στο lockdown. Εγώ να φανταστείς στο γραφείο εχω πάει συνολικά κάτω από 10 φορές.

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

Βασικά, αν ο κώδικας θέλει σχόλια, κάτι λάθος έχει γίνει. Όλα τα best practices και linters δηλώνουν ότι αυξάνουν το θόρυβο. 

Σχολια γραφεις οταν υλοποιεις εναν πολυπλοκο αλγοριθμο και πρεπει μετα να τεκμηριωσεις οτι εχει υλοποιηθει σωστα. Αν δεν βαλεις σχολια οταν θα προκυψει σφαλμα στην υλοποιηση δεν θα το καταλαβεις ποτε σε ποιο σημειο ειναι, τοσο απλα. Και δεν αναφερομαι σε τπτ αλγοριθμους τυπου bubble sort εννοειται. Σχολια επισης γραφεις για τους συναδελφους σου οταν δουλευετε μαζι το ιδιο μερος της εφαρμογης και αντι να σπαταλας χρονο να του εξηγεις καθε λιγο και λιγακι τι εχεις κανει, του τα σημειωνεις μεσα σε σχολια. Αν εχεις καλο editor και εφαρμοζει καλο text formating δεν θα σε ενοχλησουν ποτε τα σχολια στον κωδικα.

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

Γενικά νομίζω ότι η ύπαρξη σχολίων είναι code smell. Είναι μια πολύ πιο εύκολη κι ελκυστική λύση από το να φτιάξεις σωστά τον κώδικά σου. Κάνεις μία μαγεία κι αντί να τη φτιάξεις σωστά πετάς ένα σχόλιο και καθάρισες. Σίγουρα υπάρχουν legit χρήσεις των σχολίων, αλλά η αλήθεια είναι ότι δυσκολεύομαι να τις δω αν έχεις έναν σωστό κώδικα και σωστό documentation. Προφανώς αυτό δεν είναι πάντα εφικτό, ειδικά σε legacy συστήματα που γίνεται ο κακός χαμός. Αυτό δε σημαίνει ότι το "σωστό" είναι ένα σχόλιο κι όχι ένα refactor. Απλώς επειδή πολλές φορές αυτό είναι πρακτικά αδύνατο, το next best thing είναι να βάλεις ένα σχόλιο.

Καλά πως. Σχόλια δεν γράφεις (μόνο) για να εξηγείς πως κανεις κάτι, αλλά και γιατί. Πχ έχεις διαλέξει ένα magic number σε configuration: γράψε γιατί. Σε ένα απι για παράδειγμα μπορεί να παίρνεις σαν απάντηση όχι το αποτέλεσμα , αλλά επειδή είναι asynchronous, το αποτέλεσμα να είναι το operation ID. Ε θέλεις να το σημειώσεις στο κώδικα σου, αλλιώς μετά από 6 μήνες θα κοιτάς και απορείς γιατί το έκανες αυτό. 1002 παραδείγματα μπορείς να βρεις παρόμοια.

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

Σχολια γραφεις οταν υλοποιεις εναν πολυπλοκο αλγοριθμο και πρεπει μετα να τεκμηριωσεις οτι εχει υλοποιηθει σωστα. Αν δεν βαλεις σχολια οταν θα προκυψει σφαλμα στην υλοποιηση δεν θα το καταλαβεις ποτε σε ποιο σημειο ειναι, τοσο απλα. Και δεν αναφερομαι σε τπτ αλγοριθμους τυπου bubble sort εννοειται. Σχολια επισης γραφεις για τους συναδελφους σου οταν δουλευετε μαζι το ιδιο μερος της εφαρμογης και αντι να σπαταλας χρονο να του εξηγεις καθε λιγο και λιγακι τι εχεις κανει, του τα σημειωνεις μεσα σε σχολια. Αν εχεις καλο editor και εφαρμοζει καλο text formating δεν θα σε ενοχλησουν ποτε τα σχολια στον κωδικα.

Στην τελευταία μου δουλειά συνάδελφος δεν έγραφε σχόλιο ΠΟΥΘΕΝΑ.

Ούτε μια γραμμή όμως.

Και μάλιστα όχι σε strongly typed language.

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

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

 

4 ώρες πριν, skiabox είπε

Για αυτό λέμε για το management της πληροφορικής.

Φαντάσου να είσαι στο ίδιο team με τον από πάνω και να μη σου βάζει σχόλια ποτέ!

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

Και επίσης πιθανότατα εγωίσταρος.

 

Τα σχόλια θα μπουν στο task description. Το task θα έχει συγκεκριμένα specs, ώστε να ξέρει ο καθένας το πρέπει να παραδώσει. Είμαστε στο 2020 και υπάρχουν συγκεκριμένα process και εργαλεια για project management . Άντε να δικαιολογησω κάποιο //TODO στο develop branch , αλλά μέχρι εκεί. Για production δε το συζητάμε, ούτε κατα διάνοια. Είναι απλά θόρυβος για όσους εμπλέκονται στο project. 

Το γράψιμο και η συντήρηση σχολίων μέσα στο codebase επιβαρύνουν το devepoment process χωρίς ουσιαστική ανταποδοτική αξία. Αν πρέπει να εξηγείς περιφραστικα τι κάνει το function, τότε έχεις παραβει το single responsibility rule. 

Ο σωστός κώδικας είναι περιγραφικός από μόνος του. Δεν χρειάζεται σχόλια. Ένας έμπειρος προγραμματιστης ξέρει πως να δομησει και ονοματισει τα components του ώστε να βγαίνει νόημα. 

Κάπου είχα ακούσει μια συμβουλή και ήταν πραγματικά spot on. Ο κώδικας είναι σαν ένα ανέκδοτο. Αν χρειαστεί να το εξηγήσεις, τότε έχεις κάνει κάτι λάθος. Έτσι και με τον κώδικα σου. Πρέπει αυτός που τον διαβάζει, να τον καταλαβαίνει κατευθείαν. Αν αυτό δε συμβαίνει, δεν προσπαθείς να τον εξηγεις με comments. Πας πίσω στον editor και κάνεις refactoring. 

Το documentation είναι ξεχωριστό κεφάλαιο όπου πρέπει να το έχεις συγκεντρωμενο κάπου κεντρικά ώστε να γινεται reference και update όσο πιο εύκολα γίνεται. 

Όσο για το θέμα του εγωισμού και κατά πόσο μπορεί  να συνεργαστεί, ας κοιτάξει πρώτα να γράψει τα unit test του, να περάσει τον linter, να περάσει το e2e test, να περάσει το code review που θα του κάνει η ομάδα , να ακολουθεί το git-flow της ομάδας , να περασει το regression test, να ενημερώσει το task στο board και χάρισμα του τα comments. Μια χαρά βγάζεις άκρη και χωρίς αυτά. 

Επεξ/σία από liakos356
  • Like 7
  • Haha 2
Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

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

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

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

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

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

Σύνδεση

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

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

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

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