Προς το περιεχόμενο
  • 0
hdonoblepsias

Πως ξεκινατε μια custom ιστοσελιδα/προγραμμα;

Ερώτηση

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

Εγω οταν θελω να φτιαξω κατι σε custom, στηνω το site, εχοντας την βασικη ιδεα ως βαση και φτιαχνω σιγα σιγα τις σελιδες και επεκτεινω την βαση. Δεν μου «παει το χερι» να σχεδιασω σε χαρτι πρωτα ολο το project απαντωντας σε ερωτησεις (πως θελω να ειναι το site, τι ακριβως να κανει, τι σελιδες θα χρειαστω, τι πινακες στην βαση, πως θα λειτουργει). Με αποτελεσμα να εχω φτιαξει κατι και μετα να θελω να τροποποιησω/προσθεσω/σβησω κατι και να γινεται ο κωδικας αχταρμας χωρις να θυμαμαι καποια πραγματα πως τα εκανα και γιατι. Στο τελος καταφερνω αυτο που θελω, αλλα αισθανομαι οτι ενω θελω να φτιαξω ενα δρομο που παει απο Αθηνα εως Θεσσαλονικη, το καταφερνω, αλλα ο δρομος τελικα ειναι ενας πανασχημος δρομος μεσω Ιωαννινων.

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

Βασικα ποιες ειναι οι δικες σας εμπειριες και συμβουλες σε αυτο το θεμα; 

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

Καλες γιορτες σε ολους!!!

Κοινοποιήστε αυτήν την ανάρτηση


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

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

  • 0
1 minute ago, hdonoblepsias said:

Δεν μου «παει το χερι» να σχεδιασω σε χαρτι πρωτα ολο το project απαντωντας σε ερωτησεις (πως θελω να ειναι το site, τι ακριβως να κανει, τι σελιδες θα χρειαστω, τι πινακες στην βαση, πως θα λειτουργει). Με αποτελεσμα να εχω φτιαξει κατι και μετα να θελω να τροποποιησω/προσθεσω/σβησω κατι και να γινεται ο κωδικας αχταρμας χωρις να θυμαμαι καποια πραγματα πως τα εκανα και γιατι.


Την απάντηση την έδωσες μόνος σου.
Θα έπρεπε να μπορείς να απαντήσεις σε αυτά τα ερωτήματα πριν ξεκινήσεις...

Εκεί διαφέρει ο έμπειρος από τον άπειρο.
Ο άπειρος dev θα δει 10 πιθανά cases που θα πρέπει να προσέξει, ο έμπειρος θα δει 100!
Όσο καλύτερο planning κάνεις εξ'αρχής τόσο πιο σωστά θα πάει το έργο.

Οπότε πάντα ξεκίνα με planning και με τον καιρό θα γίνεσαι καλύτερος στο να "προβλέπεις" πιθανά λάθη.

  • Thanks 1

Κοινοποιήστε αυτήν την ανάρτηση


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

Γενικα: Το χαρτι πια εχει «πεθανει», μονο για γρηγορα drafts.

Invision, Figma, Adobe XD, Sketch (mac only).

Αν θες να γλυτωσεις τον εαυτο σου απο back n forth στο κωδικα τοτε αυτα τα εργαλεια ειναι μονοδρομος, ειδικα αν μπλεξεις με πελατη.

Φτιαχνεις οτι ειναι να φτιαξεις, συμφωνει ο πελατης γραπτως (email) και ξεκινας. Ο πελατης στη πορεια μπορει να ζητησει αλλαγες ή προσθηκες οι οποιες δεν ηταν συμφωνημενες  και αυτο σημαινει χρονος αρα χρημα. Με αυτο τον τροπο εχεις τον ελεγχο ωστε να ζητησεις εξτρα χρηματα για κατι που δεν ειχε συμφωνηθει αλλα και να εισαι καλυμενος νομικα αν ο πελατης αρχισει να λεει/κανει τα δικα του.

Επι του θεματος, γνωμη μου ειναι πως πρωτα σχεδιαζεις το app/web page ωστε να αναπτυχθει το υποτιθεμενο functionallity και μετα αρχιζεις και χτιζεις το back end. Το front end μπορει να γινει πολυ γρηγορα πιο πολυπλοκο απο οτι ειχες φανταστει και  αν ειχες σχεδιασει πρωτα το backend, θα εφτανες στο σημειο που αναφερεις και μονος σου, κωδικας σπαγγετι μεχρι να φτασεις εκει που θελεις και να κανεις refactor.

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

πχ προσφατα για ενα custom eshop που ετοιμαζω, μια μαλακισμενη αλλαγη που δεν ειχα υπολογισει στο front end ανεβασε ενα db query απο 50-100ms στα 12 δευτερολεπτα για ενα ευρος 120.000 προιοντων πραγμα που σημαινει αλλαγη στους πινακες για να γλυτωσω το join που κανει τη ζημια.

Επεξ/σία από Predatorkill
  • Thanks 1

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0
Στις 31/12/2018 στις 11:23 ΜΜ, Predatorkill είπε

πχ προσφατα για ενα custom eshop που ετοιμαζω, μια μαλακισμενη αλλαγη που δεν ειχα υπολογισει στο front end ανεβασε ενα db query απο 50-100ms στα 12 δευτερολεπτα για ενα ευρος 120.000 προιοντων πραγμα που σημαινει αλλαγη στους πινακες για να γλυτωσω το join που κανει τη ζημια.

Man μήπως απλά πρέπει να δεις τα indexes? just sayin...

 

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

Αυτό σημαίνει ότι θα φτιάξεις - με όποιο τρόπο, το χαρτί και το μολύβι για πολλούς είναι το καλύτερο σαν αρχή - ένα high level σχεδιάγραμμα με τα όποια λειτουργικά κομμάτια / layers / components / ... αποτελούν την εφαρμογή προσπαθώντας να οριοθετείς λειτουργία και όχι υλοποίηση, με ότι γνώσεις και εμπειρία έχεις. 

Και βέβαια while (true) learn from your mistakes, iterate, improve

  • Thanks 1

Κοινοποιήστε αυτήν την ανάρτηση


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

Man μήπως απλά πρέπει να δεις τα indexes? just sayin...

Τα χω δει αλλα στη mongo ειναι λιγο περιεργα τα index (δεν ειναι μονο ενας τυπος, εχει πολλους και πολλες στραγικες), θελει πολυ καλο σχεδιασμο αλλα και παλι μπορεις πολυ ευκολα να μην μπορεσεις να πετυχεις αυτο που θες και να χρειαστουν αλλαγες. 

Εχω καει τις τελευταιες μερες αλλα βγαζω ακρη σιγα σιγα με δαυτα.

Κοινοποιήστε αυτήν την ανάρτηση


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

Well ο σχεδιασμός εξαρτάτε από:

  1. Πελάτη. Πχ θέλει να βλέπει απ' ευθείας το αποτέλεσμα σε browser ή σε mockup;
  2. Patterns: Εαν php, java και λοιπά αντικειμενοστραφή χρησιμοποιείς τα Gang of 4 patterns?
  3. Framework: Τι frameworks χρησιμοποιείς τι σε βολεύει που.
  4. Χρόνος Refactor και Technical Dept: Προβλέπεις στο συμβόλαιό σου ή στα deadlines σου xρόνο για refactors.

Και γενικά keep it as small as possible. Πχ.βάζε μικρά deadlines ακόμα και internal για να κρατάς χρόνο και για refactors και φρόντιζε συχνό πάρε δώσε με πελάτη. Δοκίμασε να "πουλάς" στον πελάτη και χρόνο για improvements. Δε εάν είναι one time πες θα σου δώσω μια πρώτη version σε Χ χρόνο full features, για να παίζεις και μετά σε Χ+Ν χρόνο μια βελτιστοποιημένη.

  • Thanks 1

Κοινοποιήστε αυτήν την ανάρτηση


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

If you can fill the unforgiving minute
With sixty seconds’ worth of distance run,   
Yours is the Earth and everything that’s in it.... (by Rudyard Kipling)

Αυτό είναι, κατά την γνώμη μου, η πρώτη βασική προϋπόθεση για να φτάσεις εκεί που θέλεις. 

Ανεξάρτητα όμως από την απόσταση που διανύεις μέσα σε κάθε δευτερόλεπτο αν δεν ακολουθείς σταθερό "heading vector", κατεύθυνση, μπορεί στο τέλος να διανύσεις τεράστια απόσταση χωρίς να απομακρυνθείς ποτέ από το σημείο που ξεκίνησες. Για αυτό και χρειαζεται ο σχεδιασμός.

Φτιάχνεις λοιπον έναν χάρτη.

Που βρίσκεσαι; 

Που θέλεις να φτάσεις; 

Και πάνω σε αυτόν σημειώνεις σταθμούς, way points, μέχρι τον προορισμό. Κράτα την απόσταση μεταξύ σταθμούς μικρή,  μεθοδολογία  kaizen (改善) με άλλα λόγια. Σε τελευταία ανάλυση, και το ποιο μακρινό ταξίδι είναι μια σειρά από μικρά βήματα προς την κατεύθυνση του προορισμού. Και το επόμενο βήμα ξεκινάει πάντα κάτω από τα πόδια σου.

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

Όσο για τα βήματα, δεν έχω δει μέχρι στιγμής ούτε ένα project το οποίο δεν μπορείς να το διανύσεις με βήματα 3`. Και κάθε ώρα σου δίνει τον χρόνο για 20 βήματα. Αν μπορείς να αξιοποιήσεις 10 από αυτά, μπορείς να υλοποιήσεις ένα web project, κατά μέσο όρο, σε μια μέρα

 

 

 

Επεξ/σία από ajaxmonkey4hire
  • Thanks 1

Κοινοποιήστε αυτήν την ανάρτηση


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

Για μένα τα projects με τα οποία ασχολούμαι χωρίζονται σε τρεις κατηγορίες:

  • Sites που φτιάχνω για την καύλα μου
  • Sites για πελάτες

  • Β2Β Services

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

Επίσης να αναφέρω ότι κρατάω πολύ λεπτομερείς σημειώσεις για κάθε project αναλύοντας όλα τα βήματα καθώς και την πρόοδο που κάνω. Για κάθε project κρατάω τριών ειδών σημειώσεις, notes όπου γράφω γενικές παρατηρήσεις, logs που γράφω καθημερινά τι έκανα και to-do λίστα με εργασίες που πρέπει να γίνουν. Αν και ακούγεται overkill σε βάθος χρόνου είναι  πολύ χρήσιμο για να βλέπω την πορεία ενός project, αλλά και να μπορώ να επανέλθω άμεσα αν έχει μεσολαβήσει μεγάλο χρονικό διάστημα από την τελευταία φορά που ασχολήθηκα. 

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

Αυτά τα ολίγα. Καλή χρονιά.

Κοινοποιήστε αυτήν την ανάρτηση


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

Χρονια πολλά και καλή χρονιά σε όλο το forum!!! Ευχαριστώ πολύ για τις απαντήσεις σας. Απλά να πω πιο εξειδικευμένα για ποιο λόγο προβληματίζομαι.

Καταρχάς δεν μιλάω για site πελατών. Δεν ασχολούμαι (προς το παρόν) επαγγελματικά με ιστοσελίδες. Απλά έχω πολλές ιδέες και προσπαθώ να τις υλοποιήσω. Είδα οτι δεν βγαίνει με wordpress + plugins για υλοποίηση μιας πολύπλοκης ιδέας που θέλω να είναι στα μέτρα μου, οπότε ξεκίνησα τους τελευταίους 7-8 μήνες και ασχολούμαι με php, html, css, mysql. Βήμα-βήμα το 99% από αυτά που θέλω να κάνω μου βγαίνει μια χαρά. Ασχολούμαι 7-8 μήνες με custom ιστοσελίδες και για να κάνω κάτι που θέλω, ψάχνω πολύ στο google και βρίσκω κάτι πολύ κοντά σε αυτό που θέλω, προσπαθώ να το κατανοήσω και το φέρνω στα μέτρα μου.

Απλά......

Φτιάχνω κάτι σε php και mysql που δουλεύει όπως θέλω. Και ενώ τελειώνω ένα κατεβατό από κώδικα και πολλές php, σκέφτομαι αν είναι καλύτερα να το φτιάξω σε κάποιο framework. Ξεκινάω λοιπόν με codeigniter. Φτιάχνω τελικά αυτό που θέλω με mvc. Μετά βλέπω οτι είναι καλύτερα, κάποια πεδία της βάσης να τα κάνω με άλλο πίνακα και join. Και ενώ λέω "τελείωσα", σκέφτομαι οτι είναι καλύτερα, αντί να στελνω φόρμα για εισαγωγή στην βάση ή επεξεργασία, να το κάνω με js και ajax (*με δυσκολεύει απίστευτα η κατανόηση του τρόπου λειτουργίας της js.  Τώρα έχω αγοράσει αυτό το course και παλέυω). Άντε πάλι από την αρχή.

Eπίσης να σας πω τι με προβληματίζει και θα ήμουν ευγνώμων για απαντήσεις στις παρακάτω ερωτήσεις μιας και είμαι νέος στο προγραμματισμό (όχι στην ηλικία :( ):

  1. Είναι φυσιολογικό που μερικά κομμάτια σε php, css δεν μου βγαίνουν ακόμα "αυτόματα" και πρεπει να κοιτάω ξανά και ξανά τα documentations? Εντάξει δεν μιλάμε για ένα echo ή ένα foreach, αλλά για παράδειγμα, ενω ξέρω τι κάνει η implode και η explode στην php και θέλω πχ να κάνω μία array σε string, μπερδέυομαι για το ποια κάνει τι και πως είναι ακριβώς η σύνταξη. Πρέπει να googlαρω. Είναι φυσιολογικό αυτό; Δηλαδή να μην θυμάμαι;
  2. Είναι φυσιολογικό που δεν μου τρέχει κάτι με την μία και μέσα από αρκετό debugging τα καταφέρνω; Το ρωτάω αυτό, γιατί έχω στο μυαλό μου οτί ένας προγραμματιστής ανοίγει τον editor, γράφει γράφει γραφει και κατά 99% θα δουλεύει αψεγάδιαστα.
  3. Τώρα που ασχολούμαι με πιο custom καταστάσεις, βλέπω οτι μέχρι και απλά πράγματα που ήταν στο wordpress, πρέπει να γίνουν με κόπο εδώ. Είναι φυσιολογικό ή κάτι κάνω λάθως; Πχ στο wp περνάς ένα plugin για contact form, ενώ εδώ πρεπει να φτιάξεις την φόρμα, να την στείλεις στην php, να σετάρεις smtp κλπ.
  4. Φτιάχνοντας κάτι είναι κακό να το φτιάξεις να δουλεύει και σιγά σιγά να το βελτιστοποιείς; Δηλαδή εγώ είναι κακό που το έφτιαξα με submit σε php και reload και τώρα θέλω να τα φορτώνω με ajax? Θα έπρεπε να κόψω το λαιμό μου από την αρχή να το κάνω με ajax και άν δεν μπορώ, να μην κάνω τίποτα μέχρι να μάθω?

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

 

Κοινοποιήστε αυτήν την ανάρτηση


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

Ό,τι γράφεις είναι απόλυτα φυσιολογικό.

Επεξ/σία από pmav99
  • Thanks 2

Κοινοποιήστε αυτήν την ανάρτηση


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

Μην πίνεις το koolaid των frameworks και της κάθε καινούργιας τεχνολογίας που θεωρητικά γαμεί και δέρνει. Διάλεξε πάντα αυτό που γνωρίζεις καλύτερα και είναι αρκετό. Οι ανάγκες καθορίζουν τα εργαλεία κι όχι το αντίθετο. Όταν κι αν σου προκύψουν οι ανάγκες για κάτι πέρα από αυτό που ξέρεις τότε θα το μάθεις. Όχι εκ των προτέρων γιατί θα καταλήξεις να μαθαίνεις διαρκώς το νέο και ποτέ δεν θα ολοκληρώνεις κάτι.

Τώρα για τα υπόλοιπα που ρωτάς:

1). Όλοι κοιτάμε συνέχεια documentation. Με τον καιρό κάποια πράγματα σου γίνονται δεύτερη φύση και τα θυμάσαι.

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

3). Το Wordpress κι όλα τα CMS έχουν φτιαχτεί για συγκεκριμένα πράγματα, βλέπε εταιρικά sites. Λίγο κρασί, λίγο θάλασσα και το αγόρι μου. Για οτιδήποτε custom πρέπει είτε να γράψεις όλο τον κώδικα μόνος σου, είτε αν ξέρεις καλή php παίρνεις plugins και τα αλλάζεις. Οπότε κι αυτό φυσιολογικό είναι.

4.) Κανείς δεν γεννήθηκε ξερόλας. Φτιάχνεις σήμερα αυτό που μπορείς και στην πορεία το βελτιώνεις.

Οπότε όλα καλά. No worries.

Κοινοποιήστε αυτήν την ανάρτηση


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

Το πόσα σου βγαίνουν αυτόματα και πόσα όχι είναι ζήτημα εμπειρίας και εξάσκησης. Τα lookups δεν θα τα ξεφύγεις ποτέ βέβαια. Κανένας δεν θυμάται κάθε λεπτομέρεια για κάθε method για κάθε nth level sub, sub,... object στην JAVA για παράδειγμα. Πέρα από αυτό κάθε γλώσσα προγραμματισμού είναι, πρώτα από όλα, Γλώσσα. Και μάλιστα γλωσσα με περιορισμένο λεξιλόγιο.

Το παράδοξο είναι ότι κάποιος με βασικές γνώσεις ξένης γλώσσας, Γερμανικά για παράδειγμα, που χρησιμοποιεί με άνεση ένα λεξιλόγιο 2000 - 3000 λέξεων συνήθως αδυνατεί να χρησιμοποιήσει με την ίδια άνεση ένα λεξιλόγιο από 200 - 300 javascript keywords και objects. 

 

  • Thanks 1

Κοινοποιήστε αυτήν την ανάρτηση


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

Μερικές φορές ο προγραμματισμός είναι σαν την ζωή τίποτα δεν σου δίνετε τίποτα δεν σου χαρίζετε μπορεί να σου δωθούν 2-3 εργαλεία αλλά its up to u το πως τα χρησιμοποιείς. Όλοι κάνουμε λάθη για πολλούς λόγους γιατί στην τελική άνθρωποι είμεθα. (Γι αυτό υπάρχει η Παναγία και το stackoverflow άλλωστε ;) )

Επεξ/σία από PC_MAGAS
  • Thanks 1

Κοινοποιήστε αυτήν την ανάρτηση


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

Tο stackoverflow! Αν δεν σε σώσει αυτό δεν σώνεσαι ούτε με Παναγίες ούτε με τίποτα.

  • Haha 2

Κοινοποιήστε αυτήν την ανάρτηση


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

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

Κοινοποιήστε αυτήν την ανάρτηση


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

Ο τρόπος που δουλεύεις τείνει προς agile. Δηλαδή δεν κάνεις όλο το σχεδιασμό εξ´ αρχής. Φτιάχνεις ένα full feature (front to back end) και μετά το βελτιστοποιείς. Για αυτό που κάνεις μια χαρά μέθοδος είναι, αφού δε χρειάζεται να δικαιολογείσαι και σε πελάτη. Το refactoring είναι βασικός πυλώνας όλων αυτών των «τεχνικών».

Ερώτηση, χρησιμοποιείς κάποιο versioning tool, όπως git; Νομίζω θα βοηθούσε να κρατούσες εκδόσεις του κώδικα σου ώστε να κάνεις χωρίς «ενοχές» αλλά και με μεγαλύτερη σιγουριά τις αλλαγές που θες. Αν κάτι δε βγει μπορείς να γυρίσεις εύκολα πίσω σε ένα working copy της δουλειάς σου.

Στις 2/1/2019 στις 7:07 ΜΜ, elorant είπε

Για κάθε project κρατάω τριών ειδών σημειώσεις, notes όπου γράφω γενικές παρατηρήσεις, logs που γράφω καθημερινά τι έκανα και to-do λίστα με εργασίες που πρέπει να γίνουν. Αν και ακούγεται overkill σε βάθος χρόνου είναι  πολύ χρήσιμο για να βλέπω την πορεία ενός project, αλλά και να μπορώ να επανέλθω άμεσα αν έχει μεσολαβήσει μεγάλο χρονικό διάστημα από την τελευταία φορά που ασχολήθηκα. 

+1

Αν και γενικά στους developers δε μας αρέσει να γράφουμε οτιδήποτε πέρα από κώδικα. :D

Μπορείς να χρησιμοποιήσεις και online tools για κάτι τέτοιο, όπως π.χ. το trello.com.

Κοινοποιήστε αυτήν την ανάρτηση


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

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

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

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

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

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

Σύνδεση

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

Συνδεθείτε τώρα
×
×
  • Δημιουργία νέου...

Χρήσιμες πληροφορίες

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