Τσακ μπακ και αρπα κόλα ή κάποια καλή αρχιτεκτονική;

[PC_MAGAS]

Καλησπέρα,

Ουκ ολίγοι έχουν μια ιδέα και θέλουν να την υλοποιήσουν. Όμως λεφτά γιοκ και μια λύση είναι να βρουν investor. ΄Ετσι υπάρχει το δήλημα να δώσω έμφαση σε αρχιτεκτονική και να κόβω features ή να κάνω πολλά features hardcoded ίσα ίσα να έχω ένα demo για να πλησιάσω investors;

Ακόμα και σε crowdfunding να πας πρέπει να δείξεις κάτι ή να έχεις κάτι, άρα ένα demo είναι μια επιλογή. To να πεις απλά θα κάνω μια εφαρμογή που θα κάει το χ-ψ δεν είναι και τόσο ελκυστικό από το να πεις α έχω μια εφαρμογή και θέλω να προσθέσω το χ-ψ ή θέλω λεφτά για περισσότερους developers.

 

Έτσι είσαι σε δίλημα:

• Να επικεντρωθώ στην αρχιτεκτονική ώστε αργότερα να μπορώ να έχω λιγότερα refactors ή το refactor να μου έρθει ποιο αργά.
• Η να κάνω άρπα κόλα σε ότι ξέρω ή να πάρω κανά junior ίσα ίσα να έχω ένα demo καλό, μέχριθ να βρεί τα λεφτά;

[MitsarasAth]

αν μιλαμε για μανατζαρεους πουδ εν ξερουν γραμμη κωδικα,ειτε επειδη ειχαν παιξει σουπερ μαριο μια φορα και νομιζουν οτι ειναι προγραμματιστες ξεκαθαρα αρπα κολα.

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

Ορισμένες επισημάνσεις:

Πρώτον, υπάρχει και τρίτος δρόμος που λέγεται bootstraping. Δηλαδή στήνεις την ιδέα μόνος σου και προσπαθείς να βρεις πελάτες. Για μένα απείρως προτιμότερο από την χρηματοδότηση καθώς άπαξ και πάρεις λεφτά θα πρέπει να μπεις σε πορεία ταχείας ανάπτυξης, κάτι που εννιά στις δέκα φορές σκοτώνει το ίδιο το προϊόν.

Δεύτερον, χρειάζεσαι το λεγόμενο MVP, ήτοι minimum viable product. Δηλαδή μια έκδοση με τα απολύτως απαραίτητα που θα δουλεύει πολύ καλά με σκοπό τον δειγματισμό. Ας έχει το 10% των τελικών features. Αρκεί να καταλάβει κάποιος τι είναι αυτό που θες να κάνεις. Δεν μιλάμε όμως για άρπα κόλλα δουλειά, αλλά για κάτι που θα λειτουργεί σωστά. Αν πας να δειγματίσεις κάτι στημένο στο πόδι θα φας τα μούτρα σου. Ο εκάστοτε χρηματοδότης έχει γύρω του ομάδα από τεχνικούς συμβούλους που θα ξεψαχνίσουν την εφαρμογή σου.

Τρίτον, λεφτά θα βρεις μόνο αν μπορείς να αποδείξεις ότι υπάρχει ζήτηση/ανάγκη για το προϊόν σου. Πρέπει να μιλήσεις με δυνητικούς πελάτες και να πάρεις feedback πριν μπεις στην διαδικασία να βρεις χρηματοδότη.  

[παπι]

Δεν ειμαστε στο 2000. Σημερα εχουμε παρα πολλα design patterns, παρα πολλα frameworks και παρα πολλα tools. Δεν νοειται να μπεις στη διαδικασία να γραψεις μια μακαροναδα για παρουσίαση. Καταρχήν υπαρχει tool που φτιαχνεις ενα κουφαρι/σκετς της εφαρμογης για παρουσίαση.

[PC_MAGAS]

Στις 24/12/2018 στις 6:53 ΜΜ, MitsarasAth είπε

αν μιλαμε για μανατζαρεους πουδ εν ξερουν γραμμη κωδικα,ειτε επειδη ειχαν παιξει σουπερ μαριο μια φορα και νομιζουν οτι ειναι προγραμματιστες ξεκαθαρα αρπα κολα.

Ουσιαστικά ρωτώ λόγο ότι έχω δει το μοντέλο "Αντάρτικο"  σαφώς δεν το πολυκατάλαβα καλά αλλά κατάλαβα κάνω ένα feature ίσα ίσα να πάρω λεφτά με team καθαρά από Juniors.

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

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

[PC_MAGAS]

Στις 24/12/2018 στις 8:34 ΜΜ, elorant είπε

Ορισμένες επισημάνσεις:

Πρώτον, υπάρχει και τρίτος δρόμος που λέγεται bootstraping. Δηλαδή στήνεις την ιδέα μόνος σου και προσπαθείς να βρεις πελάτες. Για μένα απείρως προτιμότερο από την χρηματοδότηση καθώς άπαξ και πάρεις λεφτά θα πρέπει να μπεις σε πορεία ταχείας ανάπτυξης, κάτι που εννιά στις δέκα φορές σκοτώνει το ίδιο το προϊόν.

Δεύτερον, χρειάζεσαι το λεγόμενο MVP, ήτοι minimum viable product. Δηλαδή μια έκδοση με τα απολύτως απαραίτητα που θα δουλεύει πολύ καλά με σκοπό τον δειγματισμό. Ας έχει το 10% των τελικών features. Αρκεί να καταλάβει κάποιος τι είναι αυτό που θες να κάνεις. Δεν μιλάμε όμως για άρπα κόλλα δουλειά, αλλά για κάτι που θα λειτουργεί σωστά. Αν πας να δειγματίσεις κάτι στημένο στο πόδι θα φας τα μούτρα σου. Ο εκάστοτε χρηματοδότης έχει γύρω του ομάδα από τεχνικούς συμβούλους που θα ξεψαχνίσουν την εφαρμογή σου.

Τρίτον, λεφτά θα βρεις μόνο αν μπορείς να αποδείξεις ότι υπάρχει ζήτηση/ανάγκη για το προϊόν σου. Πρέπει να μιλήσεις με δυνητικούς πελάτες και να πάρεις feedback πριν μπεις στην διαδικασία να βρεις χρηματοδότη.  

Βασικά η ιδέα που έχω είναι καθαρά να αναπτύξω κάτι μέσω PhD στο θεωρητικό κομμάτι και μετά να ψάξω τρόπο να το χρηματοδοτήσω σαν Open Source Project που θα γίνετε από έναν Non-profit org.

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

Makes sense αλλά έχε κατά νου ότι τα open source projects είναι πιο δύσκολο να χρηματοδοτηθούν.

[Alithinos]

Στις 24/12/2018 στις 6:36 ΜΜ, PC_MAGAS είπε

Καλησπέρα,

Ουκ ολίγοι έχουν μια ιδέα και θέλουν να την υλοποιήσουν. Όμως λεφτά γιοκ και μια λύση είναι να βρουν investor. ΄Ετσι υπάρχει το δήλημα να δώσω έμφαση σε αρχιτεκτονική και να κόβω features ή να κάνω πολλά features hardcoded ίσα ίσα να έχω ένα demo για να πλησιάσω investors;

Ακόμα και σε crowdfunding να πας πρέπει να δείξεις κάτι ή να έχεις κάτι, άρα ένα demo είναι μια επιλογή. To να πεις απλά θα κάνω μια εφαρμογή που θα κάει το χ-ψ δεν είναι και τόσο ελκυστικό από το να πεις α έχω μια εφαρμογή και θέλω να προσθέσω το χ-ψ ή θέλω λεφτά για περισσότερους developers.

 

Έτσι είσαι σε δίλημα:

• Να επικεντρωθώ στην αρχιτεκτονική ώστε αργότερα να μπορώ να έχω λιγότερα refactors ή το refactor να μου έρθει ποιο αργά.
• Η να κάνω άρπα κόλα σε ότι ξέρω ή να πάρω κανά junior ίσα ίσα να έχω ένα demo καλό, μέχριθ να βρεί τα λεφτά;

Άποψή μου πως το ζήτημα refactor το προσεγγίζεις λάθος. Μη το βλέπεις ως κάτι κακό που πρέπει να αποφύγεις,  αλλά ως κάτι καλό που κάνει τη ζωή σου καλύτερη. Refactor κάνεις για να βελτιώσεις ότι ήδη υπάρχει. Κάνεις το κώδικα πιο ευανάγνωστο και εύκολο στην εργασία. Η Agile συστήνει το συνεχές refactoring: https://resources.collab.net/agile-101/code-refactoring Τη νοοτροπία δηλαδή ότι με το που αντιληφθείς ότι μπορείς να κάνεις κάτι στο κώδικα για να τον βελτιώσεις, να το κάνεις επί τόπου, και να μην τα αφήνεις να μαζεύονται. Γιατί όσο περισσότερο μαζεύονται, τόσο πιο δύσκολο θα είναι να δουλέψεις με το κώδικα που έχεις όσο περνά ο καιρός. Για αυτό να εύχεσαι να μη χρειαστεί να κάνεις refactor αργά, αλλά να κάνεις όσο πιο συχνά μπορείς. Σε κάτι που δουλεύω 41 ημέρες τώρα, κάνω λίγο refactor κάθε 4-7 ημέρες. Τουλάχιστον 1 φορά την εβδομάδα. Δεν είναι δύσκολη υπόθεση γιατί διατηρώ συνέχεια το κώδικα καθαρό και έτσι εντοπίζω εύκολα τα code smells. Και είναι κάτι που ευχαριστιέμαι να το κάνω, γιατί κάθε φορά που το ολοκληρώνω ο κώδικάς μου καταλήγει να είναι πιο ευανάγνωστος και με λιγότερες γραμμές, που έχει ως αποτέλεσμα τη μείωση του χρόνου όπου διαβάζω το κώδικα που έχω ήδη γράψει.

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

Σκέψου να φτιάξεις ένα πρωτότυπο. https://en.wikipedia.org/wiki/Software_prototyping

Στις 28/12/2018 στις 4:09 ΜΜ, elorant είπε

Makes sense αλλά έχε κατά νου ότι τα open source projects είναι πιο δύσκολο να χρηματοδοτηθούν.

Εξαρτάται τη χρησιμότητα τους.. Το Blender είναι όχι απλά open source αλλά free software (GNU). Και έχει σταθερά κάθε μήνα κάποιο εισόδημα για έναν αριθμό developers, και έχει έδρα με γραφεία κανονικά, δε δουλεύουν απ' τα σπίτια τους . Αλλά το Blender είναι και το μοναδικό εργαλείο για 3D γραφικά που να είναι ελεύθερο και τσάμπα. Ο μοναδικός <<ανταγωνιστής>> του είναι το Maya που ζητά συνδρομή 190ε το μήνα! Και υπάρχει κόσμος που το χρησιμοποιεί καθημερινά για τη δουλειά του, ε και κάποιοι απ' αυτούς λένε <<απ το να σταματήσει το Blender και να πρέπει να σκάω 190ε κάθε μήνα στην Autodesk, ας δίνω μια στο τόσο 5-10-20-30 ευρώ στο Blender.>>  Είναι το τρίτο που έγραψες στο προηγούμενό σου μήνυμα, εξαρτάται τη ζήτηση..

[PC_MAGAS]

Στις 30/1/2019 στις 7:27 ΠΜ, Alithinos είπε

Άποψή μου πως το ζήτημα refactor το προσεγγίζεις λάθος. Μη το βλέπεις ως κάτι κακό που πρέπει να αποφύγεις,  αλλά ως κάτι καλό που κάνει τη ζωή σου καλύτερη. Refactor κάνεις για να βελτιώσεις ότι ήδη υπάρχει. Κάνεις το κώδικα πιο ευανάγνωστο και εύκολο στην εργασία. Η Agile συστήνει το συνεχές refactoring: https://resources.collab.net/agile-101/code-refactoring Τη νοοτροπία δηλαδή ότι με το που αντιληφθείς ότι μπορείς να κάνεις κάτι στο κώδικα για να τον βελτιώσεις, να το κάνεις επί τόπου, και να μην τα αφήνεις να μαζεύονται. Γιατί όσο περισσότερο μαζεύονται, τόσο πιο δύσκολο θα είναι να δουλέψεις με το κώδικα που έχεις όσο περνά ο καιρός. Για αυτό να εύχεσαι να μη χρειαστεί να κάνεις refactor αργά, αλλά να κάνεις όσο πιο συχνά μπορείς. Σε κάτι που δουλεύω 41 ημέρες τώρα, κάνω λίγο refactor κάθε 4-7 ημέρες. Τουλάχιστον 1 φορά την εβδομάδα. Δεν είναι δύσκολη υπόθεση γιατί διατηρώ συνέχεια το κώδικα καθαρό και έτσι εντοπίζω εύκολα τα code smells. Και είναι κάτι που ευχαριστιέμαι να το κάνω, γιατί κάθε φορά που το ολοκληρώνω ο κώδικάς μου καταλήγει να είναι πιο ευανάγνωστος και με λιγότερες γραμμές, που έχει ως αποτέλεσμα τη μείωση του χρόνου όπου διαβάζω το κώδικα που έχω ήδη γράψει. 

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

Σκέψου να φτιάξεις ένα πρωτότυπο. https://en.wikipedia.org/wiki/Software_prototyping

Αλήθεια είναι αλλά έχω εμπειρία που αξιοποιήθηκε ένα λάθος framework (με μη πλήρη γνώση αυτού ή κάποιων τεχνολογιών) και tight deadlines με understaffed ομάδα. Έτσι ένα μέγα refactor/redesighn ήταν απλά χρονοβόρο έτσι λέω πως να αποφύγω ΜΕΓΑΛΑ κοστοβόρα refactors.

Συνήθως το μοντέλο "αναρτης" εκεί είναι ο συνδυασμός:

• features ASAP/deliver ASAP να πάρουμε τα λεφτά.
• έχε κάτι παίζει και DONT TOUCH IT .

Πράγμα που οδηγούσε σε κακής ποιότητας λογισμικό, και θέλω στην ιδέα μου να ΜΗΝ το έχω, πόνεσα πολύ, νευρίασα πολύ (και γι αυτό θέλω να κάνω και δικό μου project). Παρόλα αυτά διατηρούσε κάποιο team.

Τα μικρά refactors σε tickets είναι το καλύτερο κατ' εμέ. Κατ' εμέ μικρές μπουκιές σε μικρά dealines = καλό software.

Επεξ/σία 1 Φεβρουαρίου 2019 από PC_MAGAS