Δήλωσε συμμετοχή στα workshops που κάνουμε: bit.ly/2khPvwa Έχουμε βάλει τον κώδικα εδώ bit.ly/2YMcleF , για όποιον θέλει να συμμετάσχει στο challenge. Έχουμε κάνει και το δικό μας pull request. Θα βάλουμε κάποιον τρίτο να διαλέξει τον καλύτερο κώδικα και να το κάνει merge. BTW: Πραγματικά ευχαριστούμε τα άτομα που έχουν συμμετάσχει! Θα βάλουμε credits ανεξαρτήτως ποιον κώδικα θα διαλέξουμε.
@@SocialNerdsGR Καλησπερα σας. Εχω γραψει ενα σχολιο σε αυτο εδω το βιντεο σας: ruclips.net/video/LkATcyD3vxU/видео.html (Πως ξέρω ότι η εφαρμογή μου δουλεύει σωστά; Testing #36, live) Σας κανω tag στο σχολιο μηπως και σας εμφανισει ειδοποιηση στα σιγουρα!
Ουσιαστικά αποφεύγουμε να έχουμε πολλά επίπεδα nesting στον κώδικα. Αυτό μάλιστα είναι παλιό finding από το development του Unix (back in the day) όπου διαπίστωσαν πως τα πολλαπλά επίπεδα nesting κάνουν πολύ κακό στο maintainability. Επομένως αν δει κανείς ιστορικά το μέσο επίπεδο nesting στο unix φτάνει ένα peak μέχρι που τo διαπιστώνουν αυτό και ξαναπέφτει. Στην περίπτωση εδώ με το access που γυρνάει μόνο boolean, θα μπορούσε να γίνει με ένα return $conditionA || $conditionB [...] εάν είχε λιγότερα conditions (Άντε 2-3, με περισσότερα σίγουρα το if το κάνει πιο readable + maintainable).
Παιδιά μπράβο για το κανάλι και την εκπομπή, στην Ελλάδα το content στον τομέα δεν είναι πολύ, επιτελείτε έργο :) Η τέχνη του refactoring δεν είναι εύκολη αλλά έχει μεγάλα οφέλη. Επίσης συμφωνώ πως γενικά το if-else είναι λίγο προβληματικό, προσωπικά δουλεύω αρκετά με C# και Resharper και δεν του πολυαρέσει :Ρ
Ο λόγος που μπόρεσε να γίνει τέτοιο επίπεδο refactoring ώστε το else να φαίνεται "άχρηστο" έχει πραγματικά να κάνει με τη φύση του κώδικα. Στη συγκεκριμένη περίπτωση όντως το else έκανε περισσότερο κακό απ' ότι καλό γιατί δεν υπήρχε άμεσος λόγος ύπαρξης. Το σημαντικό σημείο του κώδικά μας ήταν η μία ή παραπάνω συνθήκες του ενός if. Οπότε και μπορούσαμε να αλλάξουμε τη δομή κατά τον τρόπο τον οποίο έγινε. Αυτού του είδους ο refactored κώδικας βολεύει στο back-end development επειδή το development βασίζεται πάρα πολύ σε ένα data μοντέλο. Δεν πρέπει όμως να λέμε πως η else δεν πρέπει να χρησιμοποιείται γενικά. Απλώς δεν πρέπει να χρησιμοποιείται με αυτόν τον τρόπο που χρησιμοποιείται στον αρχικό κώδικα. Ένα else statement θα πρέπει να χρησιμοποιείται όταν έχει ξεκάθαρο λόγο ύπαρξης. Προφανώς όταν θέλουμε να κάνουμε ένα απλό έλεγχο του τύπου "αν ισχύει αυτό τότε επέστρεψε εκείνο", τότε το else κάνει τον κώδικα λιγότερο ευανάγνωστο. Σε πιο περίπλοκα if blocks όμως ένα else θα πρέπει να χρησιμοποιείται όταν όχι απλά θέλουμε να γράψουμε κώδικα για όταν το if μας δεν ικανοποιείται αλλά όταν είναι ζωτικής σημασίας για τον κώδικα τον οποίον γράφουμε το if μας να μην έχει ικανοποιηθεί. Εν τέλει, στη συγκεκριμένη περίπτωση το πρόβλημά μας δεν είναι τόσο το else όσο το ευρύτερο nesting του κώδικα όπως αναφέρει ο φίλος στο άλλο comment.
Απλά έχουμε δει πολλές φορές να χρησιμοποιείται χωρίς ουσιαστικό λόγο και για αυτό προέκυψε αυτό το video. Φυσικά, αν έχει νόημα το else, ας χρησιμοποιηθεί. Και εμείς το χρησιμοποιούμε σε σημεία και πολλά μεγάλα open source projects το χρησιμοποιούν.
Πολύ ωραίο βίντεο, θα ήθελα να δω και άλλα παρόμοια με αυτό βίντεο και επίσης σαν νέος που είμαι στον χώρο θα μου άρεσε κάποια πράγματα που τα θεωρείται ως δεδομένα να τα εξηγείται ακόμα και αν γίνετε κατ επανάληψη σε κάθε βίντεο.
Σε ευχαριστούμε Jason! Ένας από τους λόγους που κάνουμε το live είναι και αυτό. Για να μπορεί όποιος θέλει να κάνει ερώτηση για αυτό που βλέπει. Πάντως αν έχεις κάποια ερώτηση για αυτό το video, γράψε μας εδώ και θα το δούμε.
Interesting example of guard-style[1] programming. I wish you would've talked about the notion of cyclomatic complexity[2] and its relation to the difficulty of testing (and therefore to the number of probable bugs). In this respect, the first half of the video ony simplifies the reading for the developers, but not the cyclomatic complexity. Only the refactoring done in the second half of the video increases the quality of the code. I would have liked you to also talk about tools like PHPDepend, PHPMD, phploc or VSCode plugins that highlight areas of code that need to be improved or rewritten. Maybe in a future video? :-) [1] en.wikipedia.org/wiki/Guard_(computer_science) [2] en.wikipedia.org/wiki/Cyclomatic_complexity
Μπράβο για τα ενδιαφέροντα βίντεο που ανεβάζεις. Μια ερώτηση σχετικά με το IDE. Βλέπω ότι χρησιμοποιείς το visual studio code. Πιστεύεις ότι είναι αρκετό για μεγάλα έργα σε σχέση με άλλα IDE's όπως το PhpStorm;
Σε ευχαριστούμε πάρα πολύ! Δυστυχώς, όχι. Το PhpStorm χρησιμοποιώ κανονικά. Απλά στις παρουσιάσεις, βάζω το VSCode επειδή έχει πιο καθαρό interface. Αλλά δε βολεύομαι πάρα πολύ (νομίζω ότι φαίνεται στο video).
Όσο περισσότερο αντέχεις. Γιατί όσο περισσότερο ασχολείσαι τόσο περισσότερο θα βελτιώνεσαι οπότε θα γίνεσαι καλύτερος άρα θα μπορέσεις ποιο εύκολα να βρεις μία καλή δουλειά
Χμ...πρέπει να το κοιτάξω λίγο παραπάνω τότε. Αυτό που κάνει στο PhpStorm, είναι ότι αν είσαι σε μία γραμμή και πατήσεις Cmd+d (macOS), σου κάνει copy-paste αυτή τη γραμμή από κάτω. Δεν είμαι πολύ εξοικειωμένος με VSCode. Θα το ψάξω, thanks!
![Kumamoto Masters Japan 2024 | Gregoria Mariska Tunjung (INA) [5] vs. Akane Yamaguchi (JPN) [2] | F](http://i.ytimg.com/vi/EIjZybhsWqA/mqdefault.jpg)
Δήλωσε συμμετοχή στα workshops που κάνουμε: bit.ly/2khPvwa
Έχουμε βάλει τον κώδικα εδώ bit.ly/2YMcleF , για όποιον θέλει να συμμετάσχει στο challenge. Έχουμε κάνει και το δικό μας pull request. Θα βάλουμε κάποιον τρίτο να διαλέξει τον καλύτερο κώδικα και να το κάνει merge.
BTW: Πραγματικά ευχαριστούμε τα άτομα που έχουν συμμετάσχει! Θα βάλουμε credits ανεξαρτήτως ποιον κώδικα θα διαλέξουμε.
Quality content για Ελλάδα, επιτέλους! Μπράβο συνεχίστε έτσι!
Σε ευχαριστούμε!
Μόλις κατάλαβα ότι ο κώδικας μου ήταν ένα χάος. Ευχαριστώ!
Όχι, ο δικός μου κώδικας ήταν ένα χαός :)
@@SocialNerdsGR Καλησπερα σας. Εχω γραψει ενα σχολιο σε αυτο εδω το βιντεο σας:
ruclips.net/video/LkATcyD3vxU/видео.html (Πως ξέρω ότι η εφαρμογή μου δουλεύει σωστά; Testing #36, live)
Σας κανω tag στο σχολιο μηπως και σας εμφανισει ειδοποιηση στα σιγουρα!
Ουσιαστικά αποφεύγουμε να έχουμε πολλά επίπεδα nesting στον κώδικα. Αυτό μάλιστα είναι παλιό finding από το development του Unix (back in the day) όπου διαπίστωσαν πως τα πολλαπλά επίπεδα nesting κάνουν πολύ κακό στο maintainability. Επομένως αν δει κανείς ιστορικά το μέσο επίπεδο nesting στο unix φτάνει ένα peak μέχρι που τo διαπιστώνουν αυτό και ξαναπέφτει.
Στην περίπτωση εδώ με το access που γυρνάει μόνο boolean, θα μπορούσε να γίνει με ένα return $conditionA || $conditionB [...] εάν είχε λιγότερα conditions (Άντε 2-3, με περισσότερα σίγουρα το if το κάνει πιο readable + maintainable).
Παιδιά μπράβο για το κανάλι και την εκπομπή, στην Ελλάδα το content στον τομέα δεν είναι πολύ, επιτελείτε έργο :)
Η τέχνη του refactoring δεν είναι εύκολη αλλά έχει μεγάλα οφέλη.
Επίσης συμφωνώ πως γενικά το if-else είναι λίγο προβληματικό, προσωπικά δουλεύω αρκετά με C# και Resharper και δεν του πολυαρέσει :Ρ
Σε ευχαριστούμε Φίλιππε!
Ο λόγος που μπόρεσε να γίνει τέτοιο επίπεδο refactoring ώστε το else να φαίνεται "άχρηστο" έχει πραγματικά να κάνει με τη φύση του κώδικα. Στη συγκεκριμένη περίπτωση όντως το else έκανε περισσότερο κακό απ' ότι καλό γιατί δεν υπήρχε άμεσος λόγος ύπαρξης. Το σημαντικό σημείο του κώδικά μας ήταν η μία ή παραπάνω συνθήκες του ενός if. Οπότε και μπορούσαμε να αλλάξουμε τη δομή κατά τον τρόπο τον οποίο έγινε.
Αυτού του είδους ο refactored κώδικας βολεύει στο back-end development επειδή το development βασίζεται πάρα πολύ σε ένα data μοντέλο.
Δεν πρέπει όμως να λέμε πως η else δεν πρέπει να χρησιμοποιείται γενικά. Απλώς δεν πρέπει να χρησιμοποιείται με αυτόν τον τρόπο που χρησιμοποιείται στον αρχικό κώδικα.
Ένα else statement θα πρέπει να χρησιμοποιείται όταν έχει ξεκάθαρο λόγο ύπαρξης. Προφανώς όταν θέλουμε να κάνουμε ένα απλό έλεγχο του τύπου "αν ισχύει αυτό τότε επέστρεψε εκείνο", τότε το else κάνει τον κώδικα λιγότερο ευανάγνωστο. Σε πιο περίπλοκα if blocks όμως ένα else θα πρέπει να χρησιμοποιείται όταν όχι απλά θέλουμε να γράψουμε κώδικα για όταν το if μας δεν ικανοποιείται αλλά όταν είναι ζωτικής σημασίας για τον κώδικα τον οποίον γράφουμε το if μας να μην έχει ικανοποιηθεί.
Εν τέλει, στη συγκεκριμένη περίπτωση το πρόβλημά μας δεν είναι τόσο το else όσο το ευρύτερο nesting του κώδικα όπως αναφέρει ο φίλος στο άλλο comment.
Απλά έχουμε δει πολλές φορές να χρησιμοποιείται χωρίς ουσιαστικό λόγο και για αυτό προέκυψε αυτό το video. Φυσικά, αν έχει νόημα το else, ας χρησιμοποιηθεί. Και εμείς το χρησιμοποιούμε σε σημεία και πολλά μεγάλα open source projects το χρησιμοποιούν.
Ευχαριστούμε για το tip.
Πολύ ωραίο βίντεο, θα ήθελα να δω και άλλα παρόμοια με αυτό βίντεο και επίσης σαν νέος που είμαι στον χώρο θα μου άρεσε κάποια πράγματα που τα θεωρείται ως δεδομένα να τα εξηγείται ακόμα και αν γίνετε κατ επανάληψη σε κάθε βίντεο.
Σε ευχαριστούμε Jason!
Ένας από τους λόγους που κάνουμε το live είναι και αυτό. Για να μπορεί όποιος θέλει να κάνει ερώτηση για αυτό που βλέπει. Πάντως αν έχεις κάποια ερώτηση για αυτό το video, γράψε μας εδώ και θα το δούμε.
Interesting example of guard-style[1] programming.
I wish you would've talked about the notion of cyclomatic complexity[2] and its relation to the difficulty of testing (and therefore to the number of probable bugs).
In this respect, the first half of the video ony simplifies the reading for the developers, but not the cyclomatic complexity. Only the refactoring done in the second half of the video increases the quality of the code.
I would have liked you to also talk about tools like PHPDepend, PHPMD, phploc or VSCode plugins that highlight areas of code that need to be improved or rewritten. Maybe in a future video? :-)
[1] en.wikipedia.org/wiki/Guard_(computer_science)
[2] en.wikipedia.org/wiki/Cyclomatic_complexity
This kind of comment was exactly what I had in mind when I created this video. Thanks for the suggestions!
Μπράβο για τα ενδιαφέροντα βίντεο που ανεβάζεις. Μια ερώτηση σχετικά με το IDE. Βλέπω ότι χρησιμοποιείς το visual studio code. Πιστεύεις ότι είναι αρκετό για μεγάλα έργα σε σχέση με άλλα IDE's όπως το PhpStorm;
Σε ευχαριστούμε πάρα πολύ!
Δυστυχώς, όχι. Το PhpStorm χρησιμοποιώ κανονικά. Απλά στις παρουσιάσεις, βάζω το VSCode επειδή έχει πιο καθαρό interface. Αλλά δε βολεύομαι πάρα πολύ (νομίζω ότι φαίνεται στο video).
Μια ερώτηση: Πόσο χρόνος πόσα οκτάωρα μαθήματα Χρειάζονται περίπου για να μάθει κάποιος μια γλώσσα προγραμματισμού όπως η Python .?
Όσο περισσότερο αντέχεις. Γιατί όσο περισσότερο ασχολείσαι τόσο περισσότερο θα βελτιώνεσαι οπότε θα γίνεσαι καλύτερος άρα θα μπορέσεις ποιο εύκολα να βρεις μία καλή δουλειά
Γιατί όχι Ctrl+D για επιλογή του ίδιου editor_text_selection παρακάτω;
Αν κατάλαβα καλά τις λες, νομίζω ότι το VSCode δεν το κάνει αυτό. Το PhpStorm το κάνει.
@@SocialNerdsGR το κάνει. (τουλάχιστον στον υπολογιστή μου δουλεύει 😀 )
Χμ...πρέπει να το κοιτάξω λίγο παραπάνω τότε. Αυτό που κάνει στο PhpStorm, είναι ότι αν είσαι σε μία γραμμή και πατήσεις Cmd+d (macOS), σου κάνει copy-paste αυτή τη γραμμή από κάτω.
Δεν είμαι πολύ εξοικειωμένος με VSCode. Θα το ψάξω, thanks!
@@SocialNerdsGR ctrl+shift+D στο vscode και sublime
Θα γλύτωνες χρόνο αν χρησιμοποιούσες refactor methods.
Το Intellij ειναι μανουλα σε αυτα!
Ναι, σωστά. Κανονικά PhpStorm (JetBrains) χρησιμοποιώ, απλά συνήθως στα video βάζω VSCode γιατί είναι πιο ελαφρύ.