Ακύρωση feature.

[Alithinos]

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

 

Έρχεται λοιπόν η στιγμή να υλοποιήσουμε ένα τέτοιο feature, και συμπεραίνουμε ότι η υλοποίησή του δεν θα είναι σχετικά εύκολη, όπως της πλειοψηφίας των features, αλλά το συγκεκριμένο είναι μεγάλη σπαζοκεφαλιά.

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

 

Μπορούμε να 'κολλήσουμε' σε ένα τέτοιο feature ομως και να το παλεύουμε ίσως παραπάνω από ότι πρέπει. Κάποια στιγμή αντιλαμβανόμαστε πως έχουμε μείνει πίσω στην ανάπτυξη του λογισμικού, και αυτό που μας βγάζει εκτός προγράμματος είναι αυτό το ένα και συγκεκριμένο feature. Σε εκείνη τη περίπτωση πρέπει να πάρουμε μια δύσκολη απόφαση.

 

1) Ακυρώνουμε το feature και συνεχίζουμε την ανάπτυξη για να είμαστε εντός χρονοδιαγράμματος.

2) Συνεχίζουμε να ασχολούμαστε με το feature, μέχρι τελικά να το καταφέρουμε.

 

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

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

 

Έχετε βρεθεί σε τέτοια θέση, και πως το αντιμετωπίσατε το θέμα ;

Τώρα βρέθηκα εγώ σε μια τέτοια περίπτωση, και καλούμαι να κάνω αυτή την επιλογή. Θα στεναχωρηθώ κάπως άμα το ακυρώσω τελικά και θα νοιώσω άσχημα που δεν το κατάφερα, αλλά απ' την άλλη θα μου φύγει το άγχος του χρόνου και θα μπορέσω να συνεχίσω σε άλλα features, τα οποία θα τα φτιάχνω και με καλύτερη διάθεση. Πείτε κάποια συμβουλή αν υπάρχει.

 

 

 

[KenJiNx]

Δεν υπάρχει δυνατότητα να αφήσεις το feature, να βγει η εφαρμογή ή να τελειώσει το project, και να παιδευτείς μέχρι να ολοκληρώσεις το feature αργότερα, ώστε να το προσθέσεις σαν update ; 

 

[Alithinos]

Τεχνικά υπάρχει.

Αυτό που φοβάμαι είναι ότι συνήθως διάφορα sites κτλπ που παρουσιάζουν αξιολογήσεις το κάνουν συνήθως με τη κυκλοφορία, και δύσκολα θα ασχοληθούν να κάτσουν να γράψουν κάτι για ένα update ύστερα, αν δεν έχει ήδη γίνει επιτυχία. Έτσι ένας πιθανός χρήστης ο οποίος θα κοιτάξει τις αξιολογήσεις που γράφτηκαν κατά τη κυκλοφορία ίσως να μη μάθει για τα νεότερα features, και να χαθεί μια ευκαιρία να σχηματίσει μια καλύτερη γνώμη.

[Επισκέπτης]

Το πιθανότερο είναι ότι έχεις κάνει λάθος ανάλυση/εκτίμηση και θεωρείς ότι ένα και μόνο feature αρκεί για να καταστήσει μια εφαρμογή επιτυχημένη.

[Alithinos]

Από μόνο του ίσως να μη τη κάνει επιτυχημένη, αλλά σε συνεργασία με άλλους παράγοντες είτε τελικά είναι επιτυχημένη είτε όχι, σίγουρα θα ευχαριστήσει περισσότερο αυτούς που θα το χρησιμοποιήσουν.

[Επισκέπτης]

Ε ωραία, επένδυσε τότε στους άλλους παράγοντες αφού αυτό δεν μπορείς να το φτιάξεις. Problem solved.

[Alithinos]

Ευχαριστώ πολύ όλους για τις απαντήσεις σας! Με βοηθήσατε να παίρνω αποφάσεις με περισσότερο θάρρος στο μέλλον.

 

Για την ιστορία όμως θα σας πω ότι τελικά το feature... το έφτιαξα! 

Απλά έπρεπε να ρίξω την υπερηφάνια μου και να ρωτήσω στο κατάλληλο μέρος.

 

Πιο συγκεκριμένα, το feature βασιζόταν σε μια συνάρτηση του API που ήθελα να χρησιμοποιήσω.

Χωρίς να το αναφέρει το documentation ομως η συνάρτηση τρέχει concurrently by default, επειδή οι δημιουργοί του API σκέφτηκαν πως επειδή οι υπολογισμοί που πρέπει να κάνει παίρνουν πολύ χρόνο, θα ήταν καλή ιδέα και να είναι concurrent by default. 

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

 

Έτσι το πρόβλημα λύθηκε με το να φτιάξω ένα χρονόμετρο και να καλώ τη συνάρτηση εκ νέου, αφού το χρονόμετρο έχει ολοκληρώσει.

 

 

Έφαγα τόσο χρόνο απ τη ζωή μου προσπαθόντας να βγάλω άκρη, και αυτό θα μπορούσε να είχε αποφευχθεί με 1 πρόταση. "You don't want to do it too often, because it has to generate a new path every time."  

Επεξ/σία 6 Οκτωβρίου 2017 από Alithinos

[anon667]

Επειδή το concurrent μάλλον μπερδεύει, μήπως εννοείς asynchronous;

[Alithinos]

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

 

Επίσης πιστεύω πως αν ήταν async θα το ανέφερε στο όνομα της. Ή τουλάχιστον έτσι θα έπρεπε. πχ αντί για SetDestination() θα ονομαζόταν SetDestinationAsync().

[anon667]

Και δεν έχουν υλοποιήσει κάποιον τρόπο για να ελέγχεις αν έχει ολοκληρώσει την εκτέλεση της;

[Alithinos]

Έχεις δίκιο. Υπάρχει μια bool. 

Έβαλα if λοιπόν και έσβησα το χρονόμετρο.