Πώς να σχεδιάσω ενα πρόγραμμα απο το μηδεν ?

[xarda]

Θα ήθελα να ρωτήσω σχετικά με τα βήματα που πρέπει να ακολουθήσει ενας ερασιτέχνης προγραμματιστής για να φτιάξει ενα πρόγραμμα απο το μηδέν.Δηλαδη τι θα πρέπει να σχεδιάσει , τι να λάβει υπόψην του κ.τ.λ μέχρι να φτάσει στην συγγραφή του κώδικα.Αν υπάρχει και "tutorial" στην Ελληνική θα ήταν καλό για να το διαβάσω και να αρχίσω.

[Alchemist`]

Θα ήθελα να ρωτήσω σχετικά με τα βήματα που πρέπει να ακολουθήσει ενας ερασιτέχνης προγραμματιστής για να φτιάξει ενα πρόγραμμα απο το μηδέν.Δηλαδη τι θα πρέπει να σχεδιάσει , τι να λάβει υπόψην του κ.τ.λ μέχρι να φτάσει στην συγγραφή του κώδικα.Αν υπάρχει και "tutorial" στην Ελληνική θα ήταν καλό για να το διαβάσω και να αρχίσω.

 

Πολύ βασικό για μένα είναι να δημιουργώ σημειώσεις που αφορούν αρχικά την πλήρη περιγραφή του προγράμματος (στόχοι, features κτλπ) και επίσης σημειώσεις για βασικά/περίπλοκα κομμάτια του κώδικα πριν ξεκινήσω να γράφω... Αν αρχίσεις απλά να γράφεις στον editor, πάνω που τελειώνεις κάτι, θα ανακαλύπτεις συνέχεια πράγματα που θες να προσθέσεις ή να αλλάξεις, με αποτέλεσμα να γίνεται ένα μπάχαλο, και να ξαναγράφεις πολλές φορές από την αρχή το ίδιο κομμάτια κώδικα με τις διορθώσεις... Τέλος με αυτό τον τρόπο βρίσκεις πιθανά bugs/προβλήματα πριν καν χρησιμοποίησεις το πληκτρολόγιο, και φυσικά (πράγμα που μου έχει τύχει πολλές φορές) μπορείς να θυμησείς έυκολα μέσω τον σημειώσεων τι κανεις με τον κώδικα αυτό αν αφήσεις το Project π.χ. για 1-2 μήνες.

 

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

 

Αυτά μου 'ρχονται στο μυαλό τώρα... Το πως προγραμματίζει κανείς είναι βέβαια προσωπικό θέμα, κάθε ένας βολεύεται με τον τρόπο του, έχει το δικό του σύστημα ονομασίας μεταβλητών, και γενικώς ένα προσωπικό στυλ απ' ότι βλέπω... Δεν υπάρχει μια στάνταρντ μεθοδολογία imho...

[V.I.Smirnov]

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

Πρόκειται για την "Τεχνολογία Λογισμικού" (Software Engineering). (Κάτι σαν τις αντίστοιχες τεχνικές οργάνωσης και ελέγχου τεχνικών έργων.)

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

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

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

 

Οι ερασιτέχνες και οι χομπίστες που το πρόγραμμά τους δεν ξεπερνά μερικές χιλιάδες γραμμές γενικά κάνουν του κεφαλιού τους...

 

 

Για κάπως προχωρημένους, τo βιβλίο "3D Game Engine Architecture : Engineering Real-Time applications with Wild Magic" του D. Eberly είναι

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

O συγγραφέας παραθέτει εύλογες συμβάσεις για τις ονομασίες των μεταβλητών, το indenting, δίνει εξηγήσεις για τις επιλογές του στην

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

Δεν έχω δει πιο ξεκάθαρο και καλογραμμένο κώδικα, με τόση συνέπεια και εύστοχες επιλογές σε όλα και σε τόση έκταση (>200Κ γραμμές).

(Μόνον για "δυνατούς" που ασχολούνται με γραφικά.)

 

Επίσης καλή αρχή είναι το βιβλίο "The practice of programming" των B. Kernighan και R. Pike που διαπραγματεύεται θέματα όπως τα

παραπάνω λιγότερο ολιστικά και προσιτά σε κάποιον αρχάριο.

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

 

-

[Timonkaipumpa]

Θα ήθελα να ρωτήσω σχετικά με τα βήματα που πρέπει να ακολουθήσει ενας ερασιτέχνης προγραμματιστής για να φτιάξει ενα πρόγραμμα απο το μηδέν.Δηλαδη τι θα πρέπει να σχεδιάσει , τι να λάβει υπόψην του κ.τ.λ μέχρι να φτάσει στην συγγραφή του κώδικα.Αν υπάρχει και "tutorial" στην Ελληνική θα ήταν καλό για να το διαβάσω και να αρχίσω.

 

 

 

Να αρχίσεις τι; Αυτό που θα πρέπει να ξέρεις πρώτα από όλα, είναι το τι θα φτιάξεις.

 

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

 

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

 

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

 

 

 

Τι ακριβώς τεχνική είναι η UML;

[Evgenios1]

Θα ήθελα να ρωτήσω σχετικά με τα βήματα που πρέπει να ακολουθήσει ενας ερασιτέχνης προγραμματιστής για να φτιάξει ενα πρόγραμμα απο το μηδέν.Δηλαδη τι θα πρέπει να σχεδιάσει , τι να λάβει υπόψην του κ.τ.λ μέχρι να φτάσει στην συγγραφή του κώδικα.Αν υπάρχει και "tutorial" στην Ελληνική θα ήταν καλό για να το διαβάσω και να αρχίσω.

 

Εστω θες να φτιαξεις ενα προγραμμα που θα καταχωρει αποδειξεις ( που ειναι και στη μοδα)

 

1) Επιλογη του target (window,*nix,phone,smart phone..)

2) Επιλογη της γλωσσας

3) "Σπασιμο" του προγραμματος σε υποπρογραμματα (πχ gui,datastore)

4) Ψαχνεις τι υπαρχει (πχ για datastore καποια embedded database ή καποιον xml parser ή ξερω γω. Για gui καποιο api ή framework αυτο που σε βολευει περισσοτερο)

5) Υλοποιεις τα πραπανω

 

Στην ουσια, ενωνεις ενα παζλ.

[djcat]

Τι ακριβώς τεχνική είναι η UML;

Unified Modeling Language

 

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

[Timonkaipumpa]

Unified Modeling Language

 

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

 

 

Το θέμα είναι ότι δεν είναι τεχνική.

 

 

Και ούτε γλώσσα είναι ακριβώς... άσχετο και εάν ονομάζεται "Language". Ένα πρότυπο σχεδίασης είναι... του οποίου την ανάγκη καταδεικνύανε (όταν ήταν ο καιρός) οι "πατέρες" του OOP (όπου ένας από τους μεγαλύτερους ήταν και στην ομάδα που "έφτιαξε" την UML).

 

Πριν από την UML, ο καθένας έβαζε "ό,τι να 'ναι" συμβολάκια για να δείξει inheritance, aggregation και διάφορες σχέσεις και οντότητες. Έτσι, σε κάθε σχέδιο είχες και υπόμνημα. Αυτό (προσπάθησε να) καταργήσει η UML.

[At0m0]

Top-down and bottom-up design

[ΠάρηςΓ]

Υπάρχει μια μεθοδολογια που ειναι πολυ της μοδας.. Agile Programming λεγεται νομιζω.

[Christos75]

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

Πρόκειται για την "Τεχνολογία Λογισμικού" (Software Engineering). (Κάτι σαν τις αντίστοιχες τεχνικές οργάνωσης και ελέγχου τεχνικών έργων.)

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

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

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

 

Οι ερασιτέχνες και οι χομπίστες που το πρόγραμμά τους δεν ξεπερνά μερικές χιλιάδες γραμμές γενικά κάνουν του κεφαλιού τους...

 

 

Για κάπως προχωρημένους, τo βιβλίο "3D Game Engine Architecture : Engineering Real-Time applications with Wild Magic" του D. Eberly είναι

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

O συγγραφέας παραθέτει εύλογες συμβάσεις για τις ονομασίες των μεταβλητών, το indenting, δίνει εξηγήσεις για τις επιλογές του στην

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

Δεν έχω δει πιο ξεκάθαρο και καλογραμμένο κώδικα, με τόση συνέπεια και εύστοχες επιλογές σε όλα και σε τόση έκταση (>200Κ γραμμές).

(Μόνον για "δυνατούς" που ασχολούνται με γραφικά.)

 

Επίσης καλή αρχή είναι το βιβλίο "The practice of programming" των B. Kernighan και R. Pike που διαπραγματεύεται θέματα όπως τα

παραπάνω λιγότερο ολιστικά και προσιτά σε κάποιον αρχάριο.

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

 

-

 

 

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

[georginos1989]

Ναι ειναι μαθημα

Στο τμημα πληροφορικης και επικοινωνιων του τει σερρων στο οποιω φοιτω και βρισκομαι στο 7 εξαμηνο ειναι βασικο μαθημα της κατευθυνσης του προγραμματισμου και μπορω να πω οτι ειναι ωραιο μαθημα αν και δυσκολο

[gtroza]

Timonkaipumpa & Evgenios1*

από ένα +1

 

*

 

+1 για τα τέλεια ελληνικά !

 

 

.

[kagelos]

@V.I.Smirnov

Η ονοματολογία, το indenting και γενικά το στυλ γραφείς του κώδικα είναι πάρα πολύ σημαντικό, αλλά σχεδόν άσχετο με τη σχεδίαση του προγράμματος. Το software engineering δεν περιλαμβάνει καλές πρακτικτές γραφής κώδικα. Η σχεδίαση προηγείται και είναι άλλο κομμάτι.

 

Όπως είπαν και τα παιδιά πιο πάνω, πρώτα να σκεφτείς και να γράψεις (σε χαρτί, στο notepad, σε UML, σε E-R διάγραμμα, σε διάγραμμα ροής - σε ότι σου κατέβει στο κεφάλι) τα επί μέρους κομμάτια του προγράμματός σου και πως αυτά επικοινωνούν. Στη συνέχεια να σκεφτείς πως θα λειτουργεί το καθένα από αυτά και να κάνεις δοκιμαστικά "τρεξίματα" με το μυαλό σου να δεις αν βγαίνει.

 

Όπως όμως λέει και V.I.Smirnov, το να γράψεις μετά το πρόγραμμα είναι άλλο κεφάλαιο και θέλει γνώση και εμπειρία. Ο λόγος είναι ότι όταν πας να γράψεις π.χ. μια βιβλιοθήκη, η εμπειρία θα σε βοηθήσει να την γράψεις ανοιχτή και ευέλικτη ώστε να μπορεί να υποδεχθεί μελλοντικά και νέες λειτουργίες που στην αρχή δεν χρειαζόσουν / δεν είχες προβλέψει.

[V.I.Smirnov]

@kagelos

 

To ξέρω. Γι' αυτό στην αρχή έγραψα ότι το software engineering αφορά και εστιάζει στην διαχείριση μεγάλων projects.

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

τον τρόπο που εκφράζει ο κώδικας τον αλγόριθμο. Π.χ.

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

- πρέπει να τηρείται με συνέπεια ένα στυλ ονοματολογίας και χωροθέτησης στην γραφή ώστε το πρόγραμμα να

είναι ευανάγνωστο και η εποπτεία του να βοηθά και να μην κουράζει το βλέμμα.

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

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

Οι περισσότεροι προγραμματιστές ελάχιστη σκέψη αφιερώνουν σε αυτά τα θέματα, δυστυχώς.

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

τόσο ουσιώδης.

 

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

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

Ο ίδιος ο συγγραφέας γράφει

"I have attempted to convey my thoughts as much as possible on the software engineering and computer science aspects of the engine. "

Όπερ σημαίνει ότι το στυλ γραφής του είναι επηρεασμένο από τις πρακτικές του software engineering που επιχειρεί να τηρεί.

Αυτό που είπα κι' εγώ δηλαδή...

Υπάρχουν κι' άλλα διδακτικά παραδείγματα, π.χ. το Numerical Recipes τηρεί υποδειγματικά πολλούς κανόνες από τους παραπάνω.

 

-

[soulcon]

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