Je n'arrive toujours pas à savoir comment programmer?


122

J'ai lu beaucoup de livres pour divers langages de programmation, Java, Python, C, etc. Je comprends et connais toutes les bases des langages et je comprends les algorithmes et les structures de données. (Équivalent de, disons, deux ans de cours d'informatique)

MAIS, je n'arrive toujours pas à comprendre comment écrire un programme utile.

Tous les livres de programmation vous montrent comment écrire le langage, mais PAS comment l'utiliser! Les exemples de programmation sont tous très basiques, comme construire un catalogue de cartes pour une bibliothèque ou un simple jeu, utiliser des algorithmes, etc. Ils ne vous montrent pas comment développer des programmes complexes qui ne font rien d’utile!

J'ai regardé les programmes open-source sur SourceForge , mais cela n'a pas beaucoup de sens pour moi. Il y a des centaines de fichiers dans chaque programme et des milliers de lignes de code. Mais comment puis-je apprendre à faire cela? Il n'y a rien dans aucun livre que je puisse acheter sur Amazon qui me donne les outils nécessaires pour écrire ces programmes.

Comment passez-vous de la lecture de Introduction à Java ou de la programmation Python, ou du langage de programmation C, etc. à la possibilité de dire que j'ai une idée du programme X? Est-ce comme ça que je vais le développer?

Il semble que l'écriture d'un programme implique bien plus que ce que vous pouvez apprendre dans un livre ou dans une classe. J'ai l'impression qu'il y a quelque chose.

Comment puis-je être mis sur la bonne voie?


52
Certaines personnes ne sont tout simplement pas censées programmer. Vous seul pouvez savoir si un autre chemin vous tracera ou s'il est temps d'essayer autre chose. Il est peu probable que vous obteniez une réponse qui sera utile ici.
duffymo

3
Que considères-tu comme "utile"?

7
@Michael - J'ai voté pour le sujet hors sujet, puis je suis passé à P.SE. Je pensais que ce serait un lieu plus approprié pour une discussion sur la programmation en tant que carrière et métier.

12
@ duffymo: Et certaines personnes ne sont pas censées commenter des questions.
davidk01

4
Je pense que vous faites juste trop de sauts. Passer des exemples du livre aux projets à part entière de Sourceforge est vaste et intimidant. Au lieu de cela, essayez d'étendre ce que vous avez déjà construit. Ajouter des fonctionnalités, ajouter des interfaces graphiques, ajouter des fonctionnalités réseau; et très bientôt, j'imagine que vous aurez votre propre projet sur Sourceforge.
Gablin

Réponses:


93

Construire des programmes plus complexes vient avec l'expérience. Quand j'ai programmé pour la première fois, je pensais que je m'en sortais bien s'il comptait plus de 25 lignes (et que je devais utiliser la barre de défilement). Maintenant, j'écris des centaines de lignes par jour pendant des années sur la même application.

Vous pourriez trouver cette page intéressante "Apprenez à programmer en dix ans" http://norvig.com/21-days.html

BTW: Il est très difficile de démarrer un programme. Un écrivain pourrait appeler cela "le bloc des écrivains". Au lieu de cela, je vous suggère de commencer à écrire du code et à l'améliorer. N'ayez pas peur de supprimer les grandes sections qui ne font pas ce dont vous avez besoin. Recommencez, cette fois, vous écrivez avec une meilleure idée de ce que vous faites. Recommencez et vous constaterez que vous n'avez pas besoin de la moitié de ce que vous avez écrit la dernière fois. Lorsqu'un auteur écrit une histoire, cela prend beaucoup de temps, beaucoup d'écriture et de réécriture, etc. Il y a beaucoup de critiques et de commentaires, et ce n'est terminé que lorsqu'il doit être publié (publié).


13
+1 Pour ce que Bill a dit et pour avoir discuté du "blocage de l'écrivain".
David Weiser

gawd, je fais cela depuis quelques années (10 + -2) et j'écris toujours un tas de code de temps en temps et je finis par le supprimer. J'ai eu quelques "refactors" sur lesquels j'ai travaillé pendant quelques jours et défait (via le contrôle de la source) parce que j'étais un retard (pour être franc).
Ken Henderson

5
+1 pour l'analogie avec l'écriture d'une histoire. Mes programmes en sont encore au stade "Il était une fois ...".
Andy

4
Un des aspects les plus effrayants de la programmation est un document vide. Une fois cet obstacle franchi, vous avez bien progressé.
Gablin

1
bloc de l'auteur. vous l'avez cloué là!
abel

70

J'ai toujours été submergé par de très grands projets, comme ceux que vous trouvez sur SourceForge ou GitHub. Je me demandais comment quiconque, voire une équipe, pouvait comprendre ce qui se passait entre 10 et 100 fichiers, avec des milliers et des milliers de lignes de code.

Personne ne le fait. Au moins au début.

Les projets sont des choses organiques. Ce qui commence comme une idée très simple peut rapidement devenir un travail énorme. C'est, je pense, la principale raison du développement itératif au lieu de l'approche classique de la cascade.

Pensez à construire une voiture. Bien que cela paraisse assez simple de l’extérieur, il suffit de fouiller un peu pour découvrir qu’il existe un grand nombre de considérations, de compromis et d’affaires innocentes qui doivent être traités.

Exemple:

Dans le cas d'un projet semi-grand, il commence souvent petit. "Je veux construire un serveur de cache". Donc, vous passez quelques jours à vous débrouiller et à arriver à quelque chose qui fonctionne, mais qui pourrait être amélioré de façon spectaculaire. Donc, vous ajoutez le concept de threading.

Ensuite, vous rencontrez des problèmes de concurrence dus à ce threading. Donc, vous corrigez en passant à des structures de données simultanées.

Maintenant, le processus a ralenti. Vous modifiez donc les structures de données simultanées en structures normales, mais vous fournissez des mécanismes de verrouillage pour la synchronisation.

Tout semble bien fonctionner, sauf que les utilisateurs commencent à se plaindre que les opérations ne sont pas atomiques et que les données sont corrompues.

Vous ajoutez donc des opérations atomiques classiques, telles que l’incrémentation et la sauvegarde. Cela fonctionne et vos utilisateurs sont contents. Mais quelqu'un ouvre un ticket demandant s'il est possible d'effectuer des opérations de liste.

Vous passez donc une semaine ou deux à créer cette fonctionnalité. À peu près à ce moment-là, un ami décide de vous aider. Vous travaillez ensemble, complétez et relâchez-le.

Deux billets sont ouverts. Il y a un bogue dans le traitement de la liste et il y a quelques rares cas de blocage.

Votre ami travaille sur le bogue de traitement de la liste pendant que vous vous attaquez au blocage. Vous vous rendez compte qu'une réécriture assez importante aux opérations atomiques doit avoir lieu.

... et ainsi de suite.

Cela semble assez typique de la croissance d’un projet. Une dizaine de fichiers viennent d’augmenter à 20 en quelques semaines. De nouvelles fonctionnalités sont ajoutées qui ne font pas partie du plan original. Des corrections de bogues complexes ont été ajoutées pour augmenter considérablement la taille du code.

Mon conseil:

Ne soyez pas submergé. Si vous avez une idée, implémentez des fonctionnalités. Si cela vaut la peine de poursuivre après cela, ajoutez petit à petit. Laissez votre projet grandir naturellement.


Oui, c'est presque comme si cela venait de
mon

@ Nick, n'avons-nous pas tous eu une expérience similaire avec le projet "X" avec les fonctionnalités "Y" et "Z"? J'ai eu deux projets similaires dans la dernière année. Ni l'un ni l'autre n'étaient Redis = P
Josh Smeaton

Ceci décrit presque tous les programmes que j'ai écrits.
Tim Post

Alors ça va. Kurt Vonnegut rencontre la programmation informatique
Zoot

1
Excellent exemple, mais si cela avait pu commencer un peu plus petit, cela aurait été encore mieux. Par exemple, en commençant par créer quelques structures de données, puis un code fournissant une API pour ces structures de données, puis un code utilisant cette API pour implémenter la fonction de cache, puis enfin une interface graphique. Voilà, vous avez écrit un serveur de cache!
Gablin

28

Même le plus gros programme commence par une idée et est écrit ligne par ligne.

Le meilleur (peut-être le seul) moyen d'apprendre à écrire des programmes réels est de commencer à le faire. Lorsque vous rencontrez des problèmes, vous effectuez une recherche sur le Web ou demandez ici des solutions à ces problèmes. Finalement, vous gagnerez de l'expérience et devrez demander moins souvent.

Cependant, vous devez être conscient dès le début de certaines choses:

  • Presque aucune grosse application n’est complètement écrite à partir de rien de nos jours. Vous pouvez faire beaucoup plus en moins de temps si vous utilisez des bibliothèques et des frameworks de haute qualité. Commencer avec ces techniques est souvent frustrant et demande plus de travail que de le faire soi-même, mais ce n’est presque jamais vraiment vrai.
  • Réfléchir à la manière dont vous structurez votre programme (comment le concevoir) est très important une fois que vos programmes sont devenus plus grands. Passez un peu de temps là-dessus et lisez quelques livres sur le design (je recommanderais tout particulièrement "Clean Code"), le génie logiciel ainsi que sur les bases techniques.

6
"Le meilleur (peut-être le seul) moyen d'apprendre à écrire des programmes réels est de commencer à le faire." Plus ou moins ce que je vais dire. Vous pouvez seulement lire et "comprendre les bases" tellement ... le caoutchouc doit prendre la route quelque part.
WernerCD

1
+1 pour la ligne "Commencez à le faire." Vous ne pouvez pas apprendre de l'expérience d'un livre.
Riwalk

+1 pour avoir mentionné le livre "Clean Code". Vous devriez toujours rendre votre code lisible. Facile à lire == facile à comprendre == facile à modifier
Igor Popov

15

Vous parlez de plus de génie logiciel que de programmation. C’est un peu l’architecture, un peu les «meilleures pratiques» et les «modèles de conception», un peu en collaboration avec d’autres. Bien que certains livres puissent aider, l'essentiel provient de l'expérience. Personne ne commence à écrire, disons, Microsoft Word.

Pensez à un grand "vrai" programme que vous voudriez écrire. Pensez maintenant aux différents éléments à construire pour que votre travail fonctionne comme vous le souhaitez. Par exemple, dans un jeu à la première personne moderne, vous aurez besoin d’un moteur graphique 3D, d’une intelligence artificielle non-joueur, d’un module de musique / son, d’un moteur physique et d’un module de niveau supérieur appliquant les règles du jeu. "carte", comment les différents personnages interagissent, etc.). Et puis, il y a les œuvres d'art et la conception des personnages et la musique, dont aucun n'est du code mais qui sont nécessaires pour que le jeu soit complet.

Maintenant: Lesquels construirez-vous vous-même et lesquels obtiendrez-vous ailleurs? La plupart des grands projets logiciels ne sont pas programmés à partir de rien. Peut-être utiliserez-vous un moteur 3D standard et un module musique / son pour ne programmer que les éléments qui rendent votre jeu unique. OK, vous devez donc déterminer quels modules tiers vous allez utiliser, ce qui implique des facteurs tels que le coût, les langues avec lesquelles ils travaillent, les fonctionnalités dont ils disposent, la manière dont leur API est conçue (c.-à-d. comment cela s’adapte-t-il à votre style de programmation personnel, etc.). Vous pourrez peut-être écrire des "preuves de concept" ou tester des programmes en utilisant un ou deux candidats pour les différents modules tiers, afin de vous assurer qu'ils feront tout ce dont vous avez besoin et qu'il est facile à utiliser.

En outre, même le code que vous voulez écrire vous-même peut être un travail trop gros pour que vous puissiez le faire seul dans les délais que vous avez en tête. De combien d'autres programmeurs avez-vous besoin pour travailler sur le projet? Comment allez-vous diviser le travail? Comment les différents modules seront-ils conçus de manière à ce qu'ils s'intègrent bien, même s'ils ont été écrits par des personnes différentes? Comment allez-vous tous travailler sur le même code source sans effacer les modifications des autres (answer: control de version, ce qui est extrêmement utile lorsque vous travaillez en solo mais qu'il est indispensable lorsque vous travaillez avec d'autres).

Une fois que vous avez déterminé quels modules vous souhaitez écrire en interne, vous effectuez le même processus. Déterminez les éléments de chaque module, comment ils doivent s'emboîter et que vous écrirez vous-même et que vous obtiendrez ailleurs. Continuez à décomposer les choses jusqu'à ce que chaque pièce soit suffisamment petite pour que vous puissiez la retenir, pour que vous puissiez dire: "Ouais, je pourrais écrire ça!" Et ensuite le faire. Ce faisant, vous rencontrerez des obstacles imprévus quant à la manière dont les différentes composantes de votre programme s’harmonisent. C’est frustrant, mais c’est une opportunité pour vous d’en apprendre davantage sur votre métier et vous devriez le voir de cette façon.

Au départ, vous ne pourrez garder dans votre esprit que de très petites parties de votre programme (par exemple, des fonctions individuelles). Vous devrez donc décomposer beaucoup de choses avant de commencer à coder. À mesure que vous gagnerez de l'expérience, vous réfléchirez aux fonctions plutôt que d'avoir besoin de penser à des fonctions et de commencer à penser à des objets. Et ensuite, vous allez penser à des objets et à des modules plus grands. Enfin, vous réfléchirez à des modules et à des programmes entiers, volumineux et réels.

Et ensuite, vous découvrirez que vous avez encore beaucoup à apprendre ... mais c'est tout. Si, en tant que programmeur, vous arrêtez d'apprendre, vous êtes obsolète et vous serez remplacé par un modèle plus récent.

Quoi qu'il en soit, n'ayez pas peur et ne vous inquiétez pas si cela sonne ... horrible ou impossible et vous ne voulez vraiment pas être programmeur après tout. Ce n'est pas pour tout le monde. J'aime la musique et les desserts, et je peux jouer un peu des touches et cuisiner des plats, mais je ne suis pas prêt à mettre le temps qu'il faut pour devenir un grand musicien ou un grand chef.

S'il s'avère que vous ne voulez pas être un programmeur écrivant de grandes et vraies applications de bureau, il existe d'autres types de tâches de programmation. Vous pourriez par exemple devenir un programmeur intégré. L’écriture de programmes intégrés pose des défis intéressants et intéressants, et vous faites un travail utile, mais en général, les programmes sont plutôt plus petits que les applications de bureau. Ou vous pourriez écrire des applications Web. Sur le Web, il est facile de coller des petites fonctionnalités, vous pouvez donc écrire (par exemple) un système de commentaires Web, ce qui serait utile même s'il ne s'agit pas d'une application Web complète. Il est également facile d’améliorer progressivement le contenu Web, vous pouvez donc commencer avec un client de messagerie Web de base et, au fil du temps, le transformer en quelque chose comme Gmail. (Mais ne faites pas cela, car vous serez alors en concurrence avec Gmail.)

Si vous ne voulez pas du tout être programmeur, mais que vous voulez tout de même travailler avec des ordinateurs, vous pourriez peut-être vous lancer dans l'informatique ou dans un autre domaine technique. Dans ces cas, connaître autant de programmation que vous le faites déjà est très utile, car vos pairs n'en auront peut-être même pas autant. Ou bien, vous savez, devenir musicien si cela vous tente, car (comme dans la plupart des domaines), il implique les ordinateurs aujourd'hui. Ecrivez de petits programmes qui manipulent des fichiers audio ou MIDI de différentes manières, faisant de vous un meilleur musicien. Vous constaterez que toutes les compétences en programmation que vous possédez peuvent être appliquées dans de nombreux domaines pour vous rendre meilleur dans votre travail.


Je ne suis pas d'accord pour dire que les programmes intégrés sont généralement plus petits que les applications de bureau. C'était peut-être le cas par le passé, mais j'ai travaillé sur quelques produits intégrés qui ont nécessité plus de 100 années de développement et ceux-ci n'ont pas été considérés comme particulièrement volumineux.
Bart van Ingen Schenau

1
Je suppose que cela dépend de ce que vous entendez par "intégré". Si vous voulez parler de quelque chose comme un smartphone ou un système automobile intégré, je peux en croire vos 100 années-hommes. Il reste cependant beaucoup de petits systèmes sur lesquels travailler.
kindall

+1 pour commencer à penser sur les petites choses, puis de passer à penser dans les mêmes choses et sur les plus grandes choses.
Gablin

1
Quel est le mal à concurrencer GMail? Si quelque chose que vous avez écrit seul peut réellement rivaliser avec quelque chose que Google a publié, vous pouvez vous considérer comme un sacré bon programmeur.
Gablin

La raison principale est que je considère que GMail a résolu le courrier Web. La plupart des programmeurs ne trouvent pas cela très intéressant de travailler sur des problèmes déjà résolus (et bien résolus) par d’autres. Vous pouvez probablement trouver un problème qui n'a pas encore été résolu et qui vous apporte beaucoup plus de plaisir - et le mettre potentiellement sur le marché sans avoir à faire concurrence à un gorille de 800 livres.
kindall

9

Vous ne saurez pas comment programmer à moins que vous ne soyez confronté à une tâche réelle. Aucune théorie ne remplacerait jamais une tâche simple du monde réel. Avant de commencer à travailler sur des scénarios alternatifs, je lisais naïvement de nombreux livres, avec tous les exemples, mais lorsque je rencontrais un problème réel, je ne pouvais tout simplement pas rassembler toutes mes connaissances théoriques pour mener à bien cette tâche. Si vous êtes débutant, je vous recommanderais de faire les tâches n'importe où. Ne pensez pas qu'ils sont inutiles à moins de les avoir résolus. Dans un premier temps, essayez de résoudre les problèmes de structure de données, tels que le tri d’une liste chaînée, la réalisation de DFS, de BFS sur des arbres, des graphiques, etc. , qui me font confiance est une connaissance précieuse. Ensuite, quand vous saurez que vous pouvez basculer avec des pointeurs, récursivité,

Ligne de fond. Tout est question de pratique. Il suffit de continuer à creuser et code, code, code.


7

Commencez avec des jeux informatiques, comme tout le monde. Un bon jeu est à la fois un défi de programmation et de conception, nécessite une réflexion approfondie sur la structure interne et utilise des bibliothèques système de manière très didactique, mais sans casser des choses et sans exiger une "bonne raison pour un bon résultat". comme le fait le logiciel "utile" fait.

La règle générale est qu'après avoir écrit assez de choses, une sorte d'illumination se produira inévitablement.

Un bon point pour commencer (si vous vous sentez comme C) est http://gamedev.net/ , en particulier http://nehe.gamedev.net/ . Il y a aussi beaucoup d'autres bons points pour commencer: D


4
(Oh et je viens de comprendre pourquoi tout le monde commence avec les jeux. Brillant et joli c'est motivant.)

10
tout le monde ? Revendication audacieuse.

4
Je n'ai pas commencé avec un jeu. Je trouverais ça au-delà du complexe = P
Josh Smeaton

4
De nos jours, la plupart des gens commencent avec une application Web, une barrière d'accès beaucoup plus basse (il ne s'agit que de texte).
Slebetman

4
Votre premier commentaire était probablement meilleur que votre réponse - des choses brillantes et jolies sont motivantes . C'est ce qui compte.
Scorchio

6

Vous regardez l'ensemble du programme et cela semble impossible. Mais tout cela est constitué de petits programmes stupides comme ceux que vous dites "ne faites rien d'utile".

Ce dont vous avez besoin, c'est de l'expérience nécessaire pour décomposer d'énormes tâches complexes en tâches très simples. C'est la racine de toute la programmation. Le reste n'est que sémantique.


6

Tout comme pour la conduite ou la cuisine, la programmation est quelque chose que vous apprenez à faire en le faisant. La pratique est irremplaçable.

Si les exemples de manuels sont déjà trop élémentaires pour vous, tant mieux! Il est temps de passer à quelque chose de plus complexe - et vous pouvez déjà comprendre quelques exercices difficiles pour vous-même.

Ou, si vous avez une idée en tête, brisez-la. Résolvez d'abord un petit sous-ensemble du problème. Puis développez. Lorsque l'intégration du nouveau code dans votre code existant devient difficile, vous devez tout redéfinir.


5

Écrivez un script de 200 lignes. Alors commencez à l'améliorer.

En un rien de temps, featuritis vous proposera 100 fichiers sources et plusieurs centaines de KLOC :)


5

"Ils ne vous montrent pas comment développer des programmes complexes qui font réellement quelque chose d'utile!"

Sans une définition du terme "utile", nous ne pouvons vraiment pas faire grand chose pour vous mettre sur la "bonne" voie.

Nous ne savons pas comment vous échouez ni ce qui ne va pas. Nous ne pouvons pas dire sur quelle piste vous êtes.

D'une certaine manière, vous avez une idée dans la tête que vous ne communiquez pas.

Le logiciel - la programmation - consiste à obtenir une idée de votre tête dans un langage (Python, Java, anglais, peu importe).

Une étape importante dans la programmation (et poser des questions) consiste à définir vos termes. Qu'entendez-vous par "faire quelque chose d'utile"? Soyez très clair, très complet et très précis.


Voté, je suis vraiment intéressé par la réponse de OP à ce sujet.
Scorchio

5

On me pose tout le temps cette question, par exemple comment commencer. C'est simple, vraiment. Voici une étape par étape.

  1. Venez avec une idée. On dirait que tu as déjà ça.
  2. Simplifiez votre idée à sa base - quelque chose que vous croyez pouvoir vous attaquer
  3. Disposez l'interface utilisateur sur un morceau de papier ou une serviette, peu importe.
  4. Essayez de disposer l'interface utilisateur dans votre environnement de développement.
  5. Si vous rencontrez des difficultés, google, google, google, posez des questions sur stackoverflow, utilisez la merde vivante des ressources Internet pour obtenir de l'aide. Demandez à des amis et des collègues programmeurs de vous aider dans des situations spécifiques. Retournez à l'étape 4.
  6. Commencez à écrire la logique de votre application. Si vous rencontrez des difficultés, passez à l'étape précédente et réessayez.
  7. Bientôt, vous aurez bientôt quelque chose qui fonctionne.

+1 pour le flux de travail - cela devrait fonctionner, d'une manière ou d'une autre. Je ne peux pas dire à quel point la deuxième étape est importante. C'est peut-être l'étape qui décidera si vous pouvez gérer la tâche ou non.
Scorchio

"On dirait que tu as déjà ça." Je contesterais cela. S'il y avait une idée, cela ferait partie de la question.
S.Lott

En fait, à mon humble avis, vous devriez commencer par écrire la logique de l'application, puis y ajouter l'interface utilisateur. C'est plus simple.
CaffGeek

Si vous pensez à un outil / une application, vous l'utiliseriez, ce serait encore mieux. Jeter des projets peut être démotivant. Quoi qu'il en soit, commencez petit et construisez à partir de là. Je suggérerais un outil en ligne de commande.
Carlosfocker

1
@Chad je ne suis pas d'accord avec vous. Pour les noobs, la logique est abstraite, mais l'interface utilisateur est facile à comprendre. L'inverse vient avec l'expérience.
AngryHacker

4

Créer quelque chose de petit. Cela ne vous dérange pas, votre programme sera le 1000ème à le faire.

Quelques idées:

  • une horloge (d'abord numérique, puis analogique),
  • créateur automatique de labirynth,
  • afficheur de structure de répertoire,
  • listeur d'albums mp3,
  • etc.

Choisir la plate-forme, les outils font partie de la tâche.


Je suis d'accord avec vous en principe. Le PO demande cependant des logiciels utiles. Un lecteur d'album mp3 serait un bon choix. Un lecteur MP3 de base serait préférable, car il ferait l'expérience des difficultés auxquelles un projet est confronté. Y compris LOC.
Josh Smeaton

@ Josh, le décodage MP3 n'est pas simple à faire pour un programmeur débutant.

@Thor, c'est absolument non trivial. Mais cela serait utile et enseignerait très rapidement comment les programmes peuvent devenir si volumineux. Toutes les nuances, corrections de bugs, cas de bord. Cela peut ne pas être approprié dans ce cas particulier, mais cela pourrait être approprié en général. Pouvoir utiliser vous-même un logiciel que vous avez écrit est une excellente chose.
Josh Smeaton

@Josh, je ne pense toujours pas qu'un décodeur MP3 soit petit et adapté à cet usage.

3

Ok, commençons par votre idée du programme X qui fait quelque chose d’utile et décomposons-la:

  • Utilisez un logiciel de papier, de cartographie conceptuelle ou de diagrammes pour organiser le ou les flux logiques du programme.

  • Puisque vous débutez, choisissez UN de ces articles (de préférence au début) et décomposez-le encore plus.

  • Écrivez votre code pour ce premier et utilisez-le pour construire

Le programme X doit-il ouvrir un fichier, le manipuler et créer un fichier de sortie? Voyez si vous pouvez ouvrir et afficher le fichier comme première étape. Voulez-vous une interface utilisateur agréable? Construisez-en un qui puisse exécuter votre programme d'écho de fichiers, etc. Vous ne serez pas seulement un code de construction que vous pourrez utiliser dans votre programme complexe, mais vous construirez également vos connaissances linguistiques car vous devez rechercher et rechercher des informations.

Comme dit le proverbe - Gnome n’a pas été construit en un jour :-)


3

(réponse déjà mentionnée dans les commentaires. Il a été suggéré de soumettre cette question après la réouverture de la question.)

Vous commencez avec un problème - quelque chose que vous souhaitez résoudre - quelle que soit sa complexité. Ensuite, vous prenez ce problème et vous l'écrivez et commencez à le diviser en problèmes plus petits. Ensuite, vous décomposez ces petits problèmes, etc. jusqu'à obtenir quelque chose de primitif que vous savez déjà résoudre ou que vous pouvez le faire avec un peu d'effort. Vous commencez à coder chacune de ces pièces et à les organiser en différentes fonctions ou classes, etc.

Ensuite, vous travaillez sur le prochain sous-problème. Pendant que vous travaillez sur chaque problème, vous pouvez écrire de petits cas de test et voir vos progrès se concrétiser. Il y aura toujours des défis en cours de route, mais à aucun moment, il ne sera perçu comme quelque chose de trop colossal pour être même abordé (ce qui semble être en train de se régler maintenant). Cela est vrai pour la programmation et de nombreux défis de la vie. Leur clé est de le casser.

Quant à savoir quoi faire - l'idée. Vous pouvez essayer d'inventer quelque chose de nouveau, mais vous pouvez aussi prendre quelque chose qui pourrait vous passionner et qui existe déjà, mais que vous pouvez améliorer ou même simplement le différencier. J'écris actuellement une application d'accordeur de guitare pour Android pendant mon temps libre. Je sais qu'il existe déjà de nombreuses autres applications d'accordeur de guitare, mais je pensais que ce serait un projet amusant et stimulant, je l'ai donc lancé. Au début, cela semblait presque impossible, mais après que j’ai divisé le problème en étapes plus petites, il s’agissait en réalité d’une bonne entente. Diviser et conquérir et être persistant avec vos objectifs.


3

Une des choses les plus difficiles à faire lorsque vous êtes débutant est de vous fixer des objectifs réalistes pour ce que l’exercice «Comment puis-je améliorer» devrait-il contenir à votre niveau actuel?

Je vous suggère donc de choisir de vous entraîner à résoudre de petits exercices, étant donné que la possibilité de terminer un programme selon une spécification donnée est une chose très précieuse pour tous ceux qui font des programmes pour gagner leur vie.

Je vous suggère de regarder de plus près à http://projecteuler.net/ qui propose de nombreux exercices et un système automatisé de "vérification de réponse" vous permettant de travailler à votre rythme. Les exercices sont bien formulés, mais vous devrez peut-être réfléchir. Certains peuvent même vous demander de réfléchir, mais même si vous ne les résolvez pas, vous apprendrez quelque chose d’utile.

Le libellé complet du problème 1 est le suivant:

Si nous listons tous les nombres naturels inférieurs à 10 qui sont des multiples de 3 ou 5, nous obtenons 3, 5, 6 et 9. La somme de ces multiples est 23.

Trouve la somme de tous les multiples de 3 ou 5 inférieurs à 1000.

Pensez-vous pouvoir résoudre ce problème? Alors fais le!


3

Vous avez besoin d' une expérience du monde réel !! . Aucun livre ne peut vous apprendre ça!

Vous devez apprendre à lire le code des autres utilisateurs, à le maintenir, à le détester (le code et le codeur), à l’améliorer, à penser que vous pouvez le faire mieux et quelques mois plus tard, crier à haute voix . Je vais tuer qui a jamais écrit ce morceau de code !!! Seulement pour découvrir dans le contrôle de version source que c'était vous!

Vous devez comprendre que les livres sont très spécifiques et qu'il est parfois difficile pour ceux qui savent déjà développer des logiciels.

Donc, je vous suggère de trouver un emploi de programmation. Si nécessaire, postulez pour le niveau d'entrée le plus élémentaire. Vous ne gagnerez probablement pas autant que vous pensez mériter, mais utilisez quelques mois pour apprendre comment les logiciels sont développés dans le monde réel (et ils ne sont pas toujours aussi parfaits et avec toutes ces belles pratiques exemplaires lues sur le Web , bien souvent, la qualité du code est très basse, cela dépend de votre lieu de travail, mais cela fait partie de l'expérience)

Continuez à lire vos livres, vous le découvrirez, chaque année, vous comprenez un peu plus (ou différemment) le même sujet, car vous pouvez le voir savoir avec le verre d'expérience.

Si vous parvenez à trouver un emploi auprès de développeurs talentueux, c'est beaucoup mieux. Apprenez d'eux, n'ayez pas peur de faire des erreurs.

Jusqu'à ce que vous ayez à résoudre votre premier bogue urgent de production en direct, vous ne saurez pas ce qu'est un logiciel!

:)


2

Essayez un projet open source et voyez si vous pouvez vous intégrer. Commencez par télécharger le code source et voyez si vous pouvez récupérer des tickets.


15
Les programmeurs débutants ne doivent pas essayer de rejoindre un projet open source; vous allez simplement vous mettre en travers du chemin. Les projets open source ne sont pas là pour aider les débutants.

une alternative à la participation directe est de bifurquer la source d'un projet et d'essayer de réparer les tickets sur votre propre succursale et de simplement en rester là. Les valeurs de lecture de code écrit et revu par plusieurs personnes, de structures de projet bien organisées et pouvant servir de modèles pour vos propres créations, et de compréhension du fonctionnement du processus de collaboration sont nombreuses. Observez simplement les parties publiques et utilisez le code en privé.
jellyfishtree

3
@ jellyfishtree, si vous ne pouvez pas programmer, cela peut paraître un peu trop ambitieux.

@Thorbjorn c'est sûr, mais c'est quelque chose que j'aurais aimé faire plus quand j'ai commencé. Comme pour tout, je pense que vous apprenez beaucoup en osmose et en plongeant la tête la première. Au minimum, vous obtiendrez une meilleure mesure de ce que vous ne connaissez pas / ne comprenez pas - quelque chose de bien plus précieux lorsque vous débutez et que vous désirez savoir où définir vos objectifs et ce sur quoi travailler.
jellyfishtree

@ méduse, bien sûr, et je suis certain que c’est un bon pas à faire, mais pas encore dans ce cas.

2

Lorsque je veux apprendre une nouvelle langue, j'essaie généralement de mettre en œuvre un graphe fractal. De cette façon, vous aurez un retour immédiat sur si cela fonctionne et c'est très enrichissant. Et il y a beaucoup de façons d'améliorer une fractale. L'implémentation naïve de mandelbrot est lente comme l'enfer.

Ce n'est pas très utile, mais vous apprenez beaucoup et c'est beau à regarder.


J'aime cela - une façon assez poétique d'apprendre une nouvelle langue. Mais je ne sais pas si nous devrions le recommander pour un débutant: D
Scorchio

2

La programmation consiste à résoudre des problèmes et à communiquer, et non à écrire beaucoup de code. Le code n'est qu'une nécessité, vous devriez généralement essayer d'écrire moins de code, pas plus.

Si vous ne savez pas par où commencer, vous n’avez peut-être aucun problème!

Regardez Linux et d’autres systèmes de type Unix: ils se composent tous de nombreuses petites applications qui ne font qu’une chose, mais le font bien .

Quand j'avais besoin d'un script pour trouver les 10 plus gros fichiers d'un dossier de mon ordinateur, je ne lisais pas de livres. Je viens de googler et utilisé l'une des solutions existantes. Ai-je écrit du code? - Non. Le problème est-il résolu? - Oui. Ce programme d'une ligne est-il utile? - Heck oui.

Les programmes comportant des milliers de lignes de code sont généralement écrits par plusieurs programmeurs. Vous ne pourrez pas écrire des systèmes d'exploitation entiers seuls et vous n'en aurez pas besoin. Ils utilisent aussi souvent des astuces telles que le contrôle de version et les tests unitaires .


Ne mentionnez pas le contrôle de version et les tests unitaires comme des "astuces". Faire des sauvegardes de votre travail et travailler avec cela est une nécessité. Le contrôle de version ne fait que l'aider à rester sain d'esprit. Même chose pour les tests unitaires: tous ceux qui ont écrit une seule ligne de code savent qu'il faut faire des tests, pourquoi ne pas le garder organisé?
Scorchio

@Scorchio Je voulais juste dire que l'utilisation du contrôle de version et des tests unitaires vous confère un avantage par rapport aux personnes qui ne les utilisent pas (assez). Surtout lorsqu'il s'agit de grands projets.
Kolobos

2

Diviser et conquérir.

C'est aussi simple ou difficile que cela.


2

Quand j'ai commencé à programmer, j'adorais les jeux informatiques. J'ai donc commencé à écrire mes propres jeux, dès que j'ai eu les outils nécessaires pour le faire.

Tout naturellement, mon tout premier jeu était une aventure textuelle. De même, vous pouvez commencer par un quiz ou quelque chose du genre, ou une sorte de jeu de devinettes.

En outre, vous pouvez commencer avec quelque chose, comme une machine à sous (vous n'avez pas vraiment besoin d'animations, ni même d'images. Utilisez simplement A = pomme, L = citron, S = départ, P = Prune, etc.).

Cela vous apprendra les bases de la gestion de certaines entrées utilisateur, du maintien de l'état du jeu et de la génération de la sortie en conséquence.

Je me suis dirigé assez loin dans cette voie. J'ai progressivement appris à lire l'état du clavier ou la souris, à utiliser du code graphique. J'en ai appris davantage sur le langage lui-même (j'ai commencé avec PASCAL) et je l'ai utilisé pour améliorer mes jeux existants ou juste pour commencer quelque chose de nouveau.

Je pense que les jeux sont vraiment intéressants pour apprendre la programmation. Même avec peu d'expérience, vous pouvez créer de petites choses qui vous procurent de petits moments de fierté. Parce que vous créez quelque chose, c'est amusant. Construire des applications réelles est tout à fait inutile, car il faut beaucoup de travail pour créer quelque chose d’utile, alors qu’il est étonnamment simple de créer un petit jeu qui crée une dépendance.

Vous voudrez peut-être utiliser une langue d’enseignement (dans mon cas, c’était PASCAL et, rétrospectivement, je pense que c’était un très bon choix). Beaucoup d'entre eux visent spécifiquement à créer des jeux et autres.

Créer des applications, c'est plus que créer des algorithmes. Vous devez concevoir des fonctionnalités, vous devez organiser et structurer votre code en différents couches et modules. Contrairement aux problèmes plutôt "atomiques" que vous rencontrez à l'université, les applications sont parfois mieux développées de manière incrémentale. Vous commencez avec quelque chose et vous ajoutez des choses en plus. Ainsi, ayant déjà quelque chose pour commencer (comme vous le feriez dans certaines des langues répertoriées dans l'article de Wikipédia), vous évitez beaucoup de frustration et commencez à créer quelque chose tout de suite. (Un de mes collègues a commencé à programmer en écrivant Quake 2 Mods). À un moment donné, vous allez trouver les limites de ces outils faciles à utiliser, mais jusque-là, vous aurez beaucoup plus de perspicacité et de compréhension. Probablement assez,


2

À l'université, il y avait un cours appelé programme de programmation qui enseignait essentiellement cette rampe. Au début, on vous a donné une interface utilisateur pour une application de magasinage de base, et vous avez dû coder le backend, le dernier mois était Tetris à partir de zéro. Je pense qu'environ 50% des nouveaux étudiants (sans reprendre la classe) ont échoué, car il est extrêmement difficile de passer de petit à grand.

Je suggérerais un ou plusieurs des éléments suivants:

  • Téléchargez un projet open source et ajoutez quelque chose. Cela n'a pas besoin d'être utile ou bon, mais vous devrez regarder la structure, ce qui vous donnera une idée de la taille du projet.

  • Il suffit de concevoir votre projet final sur papier, avec des flèches pour les dépendances. Si vous fabriquez un serpent, vous pourriez avoir la tête, la queue de serpent, la nourriture, un espace vide, un mur, un tableau, la direction actuelle, etc.

  • Prenez un projet de base et agrandissez-le. Vous allez probablement faire beaucoup de refactoring et, espérons-le, apprendre à créer des projets plus petits, faciles à ajouter.

  • Si vous connaissez une personne expérimentée, expliquez-lui votre idée de projet et demandez-lui d'écrire vos cours + quelques méthodes importantes, cela prendrait probablement une heure environ. De cette façon, vous pouvez simplement compléter les méthodes et toujours savoir ce que vous devez faire ensuite.

Enfin, quoi que vous fassiez, vous devriez probablement utiliser un modèle de conception de base MVC (Model, View, Controller). Sans entrer trop dans les détails, placez votre vue (interface utilisateur) dans plus de 1 classe, votre contrôleur (entrée, sortie, etc.) dans plus de 1 classe et votre modèle (logique, données, essentiellement tout le reste) dans plusieurs classes. C'est un moyen facile d'obtenir une organisation de base.

Rappelez-vous, cette étape est difficile. Il est vrai que certaines personnes ne peuvent tout simplement pas programmer, mais vous êtes probablement bloqué à ce stade. Bonne chance!


2

Premièrement, vous remplissez déjà les conditions préalables en prenant des cours, en lisant des documents de référence, en consultant des projets open source et en restant curieux de poser des questions. J'insiste sur ce point parce que j'ai personnellement rencontré des questions similaires avant que la personne n'ait effectué un travail de jambes de sa part (en particulier, des personnes contournant les cours et espérant prendre des raccourcis). Maintenant, je repense à l'époque où nous avions des laboratoires sur les machines Turing et au fait qu'à l'époque j'avais l'impression que ce n'était pas une vraie programmation. Ce sont les expériences que vous garderez que ceux qui prennent des raccourcis sautent.

  • Inscrivez-vous pour des projets d'étudiants. Je me suis impliqué avec (CSUA) avec un groupe d'étudiants partageant les mêmes idées pour construire un jeu pour le stand de carnaval de ma dernière année. Si vous continuez à en profiter et pensez que vous souhaitez élargir votre participation, profitez réellement des ressources. Renseignez-vous sur vos projets, parlez à vos camarades de classe, à vos professeurs et trouvez un stage.

  • Asseyez-vous avec un programmeur expérimenté. Il y a eu environ trois fois dans mon histoire lorsque j'ai regardé une autre émission télévisée qui était vraiment inspirante. Pour eux, ils étaient juste en train d'écrire du code et de réfléchir à haute voix. Sans exagération, je me sentais absorbé plus par leur écoute que par des années de mon temps. Si vous rencontrez plus, vous êtes beaucoup plus riche. Nous avons la chance d’être à une époque où nous pouvons visionner des vidéos, inspecter des référentiels de sources complets et effectuer une recherche instantanée dans un vaste magasin de connaissances en ligne. Cela ne remplace pas l'expérience en personne, mais en l'absence de mentor, cela représente une amélioration considérable par rapport au matériel traditionnel. Regarder le code brut par d'autres, en soi, peut ne mener à rien, cependant. Vous voudrez avoir quelque chose en tête et un bon débogueur pour entrer dans la logique. Un de mes moments les plus chers était de créer un mod Quake et ce n’était pas le mod lui-même qui avait quelque chose de mémorable. C'était voir la logique de Carmack dans le jeu. Le mod était juste une raison pour moi de plonger po

  • Entraînez-vous à expliquer et à répondre aux questions posées par votre partenaire de laboratoire. Volontaire pour aider à enseigner. Peut-être former un groupe d'étude et demander à chaque membre de devenir un expert sur un sujet de la classe. Ensuite, faites griller cette personne et demandez-leur de vous faire griller. Lorsque vous êtes obligé de répondre à des questions, vous serez obligé d'apprendre les réponses vous-même. Lorsque vous pouvez expliquer clairement les concepts aux autres, vous avez enrichi votre propre compréhension au point de pouvoir la transmettre en dehors d'un livre et de vos pensées.

  • Enfin, n'ayez pas peur d'apprendre à la dure, se salir les mains, faire des erreurs. Cela peut aussi être appelé expérience. Voici un exemple plus pratique de votre question sur les projets avec une base de code trop lourde et des nombres de fichiers volumineux: procédez comme suit: utilisez un seul fichier pour votre travail. Vraiment je ne plaisante pas. Cette même question a en fait été soulevée par mon entreprise actuelle et précédente. Ici, un autre développeur a observé que je préférais garder un fichier pour chaque classe. Cela lui a paru étranger et, dans le même ordre d'idées, il n'aimait pas non plus les cours partiels. Par conséquent, une façon pour vous de savoir quand et où il est approprié de scinder la logique en fichiers distincts consiste à commencer par un seul fichier. Après avoir appliqué la règle du fichier unique à plusieurs projets, espérons-le, de complexité croissante, vous pouvez vous retrouver dans un projet où vous avez tellement de classes dans le même fichier que vous avez du mal à lire ou en raison du contrôle de version, il devient difficile de collaborer. À ce stade, vous souhaitez créer des fichiers distincts pour regrouper différentes classes. En fonction de vos préférences, vous pouvez décider très tôt d'aimer toutes les classes de données d'un fichier. Puis encore et peut-être plus tard, vous pourrez décider d’aimer des fichiers séparés même entre des classes de données en tant que groupe.


+1 belle réponse. Je dois dire que passer du temps avec un programmeur expérimenté peut aussi être intimidant pour les débutants. Accélérer les choses qui vous auraient pris beaucoup de temps. Mais, selon le type de personne que vous êtes, ce genre de chose pourrait être un facteur de motivation et allumer une partie de ce feu dans votre ventre. Vous poussant à vouloir botter le cul.
Terrance

1

Vous n'avez pas besoin d'avoir une bonne idée pour commencer à programmer quelque chose. Je commencerais par la partie facile. Par exemple, un programme que vous utilisez déjà. Essayez de faire quelque chose que vous savez déjà comment cela fonctionne. Face à vos problèmes, vous apprendrez plus vite. Une fois que vous aurez plus d'expérience, vous commencerez à avoir quelques bonnes idées de programmes pour vous rendre la vie plus facile tout en programmant, ou tout simplement un bon programme pour faire quelque chose que vous n'avez jamais pensé auparavant. Je programme Java depuis près d'un an et d'autres langages depuis quelques années. Il a fallu du temps pour commencer à faire ce que je voulais vraiment faire. Je viens juste de commencer à faire mes propres affaires. Merci à StackOverflow. Je ne le savais pas avant.


1

Donc, il y a une tonne de réponses alors pardonnez-moi si je répète une grande partie de ce qui a déjà été dit, mais voici mes 2 centimes.

Choisissez d'abord une idée. Toute idée ira bien, quelque chose de simple serait probablement mieux que grand. Les projets ont tendance à évoluer très rapidement (certains l’appellent le glissement de fonctionnalités).

Ensuite, créez un squelette pour le projet. Cela nécessitera un peu de connaissances en architecture et en conception et vous vous tromperez probablement les dix premières fois que vous l'essayez - je l'ai fait. Présentez simplement une structure de fichier décente et peut-être un petit squelette de code qui montre les parties importantes du système.

Sauvegardez le squelette dans votre VCS (choisissez votre poison avec celui-ci et attendez quand cela mène à une guerre sainte). Une fois que vous avez commencé à utiliser VCS, l’utiliser constamment pour de petits changements devient une seconde nature, mais assurez-vous de commencer.

Choisissez maintenant une fonctionnalité petite mais importante pour le système et créez-la. Ne vous préoccupez pas de vous assurer que tout est parfaitement encapsulé et qu'il présente le "meilleur" design (qui évoluera avec le système). Obtenez juste quelque chose qui fonctionnera. En outre, certains tests unitaires vous aideront à savoir ce qui s'est passé lorsque quelque chose se casse, si vous exécutez les tests régulièrement.

Construisez votre système. Ce serait également le bon moment pour obtenir un système de construction automatisé et une intégration continue. Si vous ne savez pas ce qu’ils sont alors, apprenez-le et essayez, ou continuez simplement à vos risques et périls; de toute façon continuer à travailler.

Maintenant, choisissez une autre fonctionnalité et répétez et répétez et répétez.

Une fois que vous pensez que cela fonctionne bien, montrez-le à un ami. L'ami n'a pas besoin de savoir programmer ou même de savoir ce que fait le programme. Une que vous voudrez montrer à quelqu'un et deux qui vous aideront à savoir exactement ce que fait le système.

Si vous êtes vraiment sûr de ce que vous avez fait, publiez-le en ligne et essayez d'obtenir des commentaires. Un concentrateur de référentiels ou un sous-programme de programmeurs peut vous fournir des critiques constructives. Essayez de trouver un professeur CS / SE et demandez-lui de l'examiner. Peut-être demander à un programmeur professionnel. Obtenez juste un autre avis de programmeurs.

Une fois que vous avez terminé (ou probablement avant), vous réaliserez que le code que vous avez initialement écrit est bien pire que ce que vous avez créé récemment. Cela est parfaitement naturel et nous arrive à tous. Vous devez maintenant trouver un nouveau projet et apprendre quelque chose de nouveau - peut-être une nouvelle stratégie de test ou comment utiliser l'architecture orientée service.


1

Ce qui peut vous aider, par exemple, est de penser à un problème simple que vous rencontrez au quotidien et que vous pourriez remplacer au crayon et au papier par un programme.

Cela vous donne un problème relativement simple avec une solution assez connue qui nécessite juste un niveau d'automatisation. Gardez à l'esprit qu'il n'est pas nécessaire que ce soit le prochain MS Word / WordPad / NotePad; juste quelque chose qui résout votre (simple) problème.

Par exemple, un problème que je réimplémente sans cesse lorsque je travaille avec une nouvelle langue est une simple application de chronométrage. L'application est utilisée pour suivre les heures facturables à différents projets au cours d'une journée. Un programme assez simple avec beaucoup de pièges, comme comment gérer les redémarrages au milieu de la journée ou comment ajouter / supprimer des éléments de votre liste.


1

Je pense qu’une partie du problème est que, lorsque vous lisez des livres de programmation, ils vous enseignent simplement la langue. Ils omettent de mentionner que pour programmer presque tout, il faut avoir accès à la programmation LIBRARIES, SDKS, etc. Il ne suffit malheureusement pas de connaître la langue.


1

Je suppose que votre problème vient de: 1. le conflit entre la théorie et la pratique, et aussi que ... 2. ... vous devez réaliser que votre code sera exécuté par le code des autres. 3. Vous ne pouvez pas coder quelque chose si vous n'avez aucune idée de ce que vous pourriez faire. 4. Vous connaissez la moitié de la difficulté

  1. Connaître une langue par la théorie ne veut pas dire que vous "parlez": c'est la différence entre lire l'anglais et le parler. De plus, le grand nombre d'outils disponibles pour compiler, lier, éditer un code source vous fera tourner la tête.

  2. lorsque vous apprenez à programmer, le plus souvent si le terminal est utilisé pour saisir / afficher du texte, car il s’agit du moyen le plus simple de procéder à la programmation. En fait, les programmeurs utilisent des bibliothèques (comme Qt), des frameworks (django je suppose) et d'autres codes de raccourci pour être productifs. Bien sûr, si vous sentez que vous pouvez écrire votre propre roue, ne la réinventez pas et lisez des livres sur la conception du compilateur et du noyau: il y a beaucoup à apprendre dans ces domaines: peut-être avez-vous l'impression qu'il est stupide de créer des applications qui n'exigent pas beaucoup de technicité.

  3. Inventer quelque chose ! Bien sûr, vous pourriez faire un éditeur de texte, un jeu, etc. Le fait est que vous ne ferez pas ceux-là si vous ne voyez aucune raison de le faire: ce programme sera inutile pour vous si tout ce que vous pensez a déjà été fait . Personnellement, je rêve toujours de pouvoir coder un protocole p2p décentralisé de type facebook avec chat, messages hors connexion, etc., de manière à pouvoir l’utiliser avec des appareils sans fil intégrés. Internet donne beaucoup de possibilités, n'oubliez pas d'y penser.

  4. En fait, la théorie est nécessaire pour la pratique, mais ce n’est pas tout: les algorithmes et les techniques ne font pas partie de la théorie de la programmation, il existe de nombreux paradigmes et autres moyens "standard" de créer votre code: modèles de conception, listes chaînées, etc.


1

Vous pourriez peut-être choisir un langage de script pour commencer. J'ai commencé à programmer avec le langage C. À mon avis, le langage C est facile à utiliser, mais il faut encore plus de temps pour connaître l’algorithme et connaître le système d’exploitation. Et chaque fois que je fais de l’exercice, c’est simplement avec une interface graphique DOS, cela me rend dépressif.

Et plus tard, j'ai choisi un langage de script appelé ActionScript pour commencer. Le langage de script est un langage orienté objet qui peut contrôler le comportement d’une animation Flash. Le langage de script permet de réaliser facilement des tâches proches du domaine problématique , comme trace("HelloWorld")dans ActionScript pour générer une chaîne. Et il a un puissant IDE pour vous permettre de vérifier si votre programme se passe bien.

En un mot, si vous voulez commencer à programmer rapidement , un langage de script peut être un bon choix :-)


1

Ecrire une spécification. Que voulez-vous que votre programme fasse? Les écrans (s’il s’agit d’un programme basé sur l’UI), la logique, les entrées / sorties, etc. Limitez la portée à ce que vous pouvez faire dans un délai raisonnable (une semaine, un mois?).

Alors construis-le. S'en tenir à la spécification, le faire fonctionner selon ce que la spécification a besoin. Bien sûr, vous rencontrerez des distractions, bien sûr, vous devrez faire des recherches car vous n’avez jamais fait face à un problème particulier auparavant, mais vous allez construire quelque chose que vous voulez construire. Ceci est différent de la construction de quelque chose que vous venez de «pouvoir» construire.

Une fois que vous avez terminé, refactorisez votre code et essayez de le rendre plus efficace. Ensuite, si vous pensez que votre programme n’est pas encore terminé, recommencez, améliorez les spécifications, améliorez le code et continuez ainsi.

N'oubliez pas que la plupart des logiciels commerciaux répondent à un besoin. Il est très important de définir le besoin et la solution pour le combler avant de résoudre le problème. Et au fur et à mesure que le besoin grandit, votre logiciel grandira également avec le temps!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.