Écrire mon approche de résolution de problèmes sur papier? [fermé]

Je suis un étudiant de première année en sciences informatiques et nous venons juste de commencer à faire de vrais projets en Python. J'ai constaté que je suis très efficace lorsque j'utilise la méthode du stylo et du papier proposée par mon professeur en classe. Mais quand je ne peux pas écrire mon problème et travailler mes algorithmes sur papier, je suis vraiment lent. Pendant les travaux en laboratoire, je semble toujours obligé de ramener le travail à mon dortoir. Quand j'arrive et que je l'écris, je résous le problème qui m'a pris toute la classe en environ 5 minutes.

C'est peut-être parce que je suis stressé de voir des gens résoudre des problèmes de laboratoire avant moi. Ou peut-être que c'est la méthode du stylo et du papier.

Je parcourais des forums et quelqu'un a écrit que si vous deviez écrire vos programmes sur papier, vous ne devriez pas être un programmeur. Je suis vraiment inquiet parce que je suis tellement mieux quand je peux voir ce que fait le programme et suivre mon chemin avant de taper le code réel. Est-ce que je fais quelque chose de mal?

Edit: Désolé de ne pas être clair, mais quand j’ai dit écrire sur papier, j’entendais mon approche de résolution de problèmes (écrire des exemples, créer des tableaux avec des valeurs, etc.) et non mon code réel. J'utilise simplement le papier pour exprimer mes idées.

Il n'y a rien de mal à travailler vos algorithmes sur papier en premier. Pas tellement pour le codage quotidien, mais pour les algorithmes plus complexes, les programmeurs professionnels travaillent constamment sur du papier ou un tableau blanc, surtout si un format graphique le rend plus clair. Pour un étudiant, chaque programme est complexe.

Toutefois, si vous souhaitez améliorer la conception d’algorithmes sur un ordinateur, vous pouvez appliquer certaines techniques. Ne commencez pas simplement par écrire le code, écrivez les mêmes choses que vous mettriez sur papier sous forme de commentaires, puis développez-les en code réel ou en commentaires plus détaillés, un par un.

Par exemple, si je supprime un élément du milieu d'une liste chaînée, je pourrais commencer par quelque chose comme:

// find the element
// point the previous element to the next element
//    How do I get a pointer to the previous element?
//        doubly-linked list?
//        another find?
//        keep track during the first find?
// delete the element

Ensuite, je pourrais remplacer // find the elementpar une fonction avec plus de pseudo-code et continuer jusqu'à ce que je dispose d'une solution complète. Ne pensez pas que le code doit être écrit de manière linéaire.

Fonce! Si nous appelons ce que vous faites en pensant et en concevant votre solution, il est alors logique que votre processus soit beaucoup plus rapide que de simplement exploser du code.

Les gens aiment penser (et les plus bruyants aiment nous dire) que leur façon de faire est meilleure. Mais la combinaison de capacités et de compétences de chacun est différente. Alors fais ce qui fonctionne pour toi. Au fur et à mesure que vous vous entraînerez, vous allez probablement vous consacrer davantage à la conception et utiliser du papier pour les plus gros problèmes.

Une chose à surveiller est la forme que prendront les examens. Seront-ils sur papier ou seront-ils sur ordinateur? S'ils sont à base de papier, votre façon de faire vous donnera un avantage. Si elles sont basées sur un ordinateur, alors c'est bien aussi: faites n'importe quel dessin sur papier, puis écrivez le code. Tout ce qui fonctionne le mieux!

Je ne mets pas le code réel sur papier, mais pour tout ce qui n'est pas anodin, je commence presque toujours par un tableau blanc ou un cahier. J'ai l'habitude de dessiner:

• Algorithmes / processus / flux de contrôle
• Structures de données
• Des relations
• Composants (comment résoudre ce problème)

C'est généralement une combinaison de croquis, pseudocode et anglais.

Je trouve qu'en faisant cela, il est plus facile de visualiser que je commence à coder. Je vais également repérer les défauts avant de commencer dans le code, car je peux tout voir devant moi (au lieu d'un défilement incessant et d'un saut dans les fenêtres). Non seulement cela, une fois qu'il est écrit, je peux laisser les choses se former dans mon esprit alors que je travaille à d'autres tâches. Je peux aussi travailler de manière non linéaire, en inscrivant une idée sur papier quand elle me frappe, puis en revenant au moment où j'en ai besoin.

Conserver quelque chose sur papier est une aide précieuse pour la conservation de la mémoire. Le slogan de la marque de cahiers Field Notes est le suivant:

Je ne l'écris pas pour m'en souvenir plus tard, je l'écris pour m'en souvenir maintenant.

Après avoir adopté une approche plus ciblée pour écrire des choses sur papier, même si je fais une entrée dans l'application ToDo sur mon téléphone un moment plus tard, je trouve que cette pensée est bien ancrée dans ma tête, bien mieux que de simplement écrire une note électronique. IOW, en planifiant mon codage sur papier / tableau blanc, les idées restent mieux dans ma tête.

C'est aussi une référence pratique lorsqu'il est temps de documenter ce que j'ai écrit.

Je pense qu'il n'y a rien de fondamentalement faux dans la rédaction de code (pseudo ou autre) sur papier en premier. Ce n'est vraiment pas différent d'écrire sur un tableau blanc, ce que font beaucoup de gens lorsqu'ils discutent de la manière de résoudre un problème.

Est-ce que vous écrivez d'abord les versions préliminaires des essais pour les classes non CS avant de les taper? En fait, je le faisais il y a des années quand j'étais encore étudiant, mais après ma première année d'études, je me suis forcé à écrire tous les brouillons sur un écran, car cela simplifiait grandement la rédaction des brouillons suivants, et la même idée s'applique pour écrire du code.

Je vous suggérerais d'essayer de saisir vos algorithmes, même si ce n'est que dans un éditeur de texte comme Word. Plus vous le faites, plus vous serez à l'aise de ne pas compter sur le papier et le stylo. Et si vos compétences en dactylographie manquent quelque peu et que c’est en fait la source de votre frustration, suivez un cours de dactylographie! Ce serait la meilleure chose à faire pour votre future carrière.

Résoudre le problème et écrire le code qui implémente votre solution sont deux activités différentes.

Si vous ne connaissez pas une langue, vous passerez beaucoup de temps sur le code lui-même - et pas assez sur la recherche d'une bonne solution. Si le papier, le tableau blanc ou le plafond vous aident à cet égard, faites-le.

(Personnellement, je me retrouve à sortir de l'ordinateur et à tourner en rond pour essayer de construire une solution dans mon esprit)

Vous allez réussir des interviews! Ils vous font écrire du code sur du papier ou sur le tableau blanc. Je suis l'exact opposé. Essayer d'écrire des bretelles ou des couper / coller avec un stylo est tellement fastidieux!

Mon père a utilisé beaucoup de papier lors de la programmation en COBOL. Je pense que c'est juste ton style de pensée.

Auparavant, nous avions une classe de deux semestres appelée Les bases de la programmation. Les tests de mi-semestre et les examens à la fin ont été effectués sur papier. Si vous avez commis des erreurs de compilation, vous avez perdu beaucoup de points. Si vous avez commis d’énormes erreurs de compilation, vous avez échoué. Cependant, j'estime qu'il a développé la capacité en nous de jeter un coup d'œil sur n'importe quel code et de trouver des lignes boguées en un temps relativement court.

Il n’ya rien de mal à ce que vous faites, j’ai appris à programmer aussi avec du papier et un stylo.

Comme d'autres l'ont suggéré, faites ce qui vous convient. Je me souviens que le premier programme Java que j'ai écrit était principalement sur papier, puis j'ai passé deux heures à le taper et quinze minutes à pleurer quand j'ai constaté plus de 200 erreurs de compilation. Il y en avait plus mais le compilateur ne montrerait que les 200 premiers! Ce que je veux dire, c’est qu’en écrivant le code sur papier, j’ai été en mesure de réfléchir à l’algorithme de base et aux fonctionnalités de ce que le programme devait faire. Le compilateur a souligné les raisons pour lesquelles mon programme ne fonctionnait pas. 90% des problèmes étaient des exceptions hors limites avec des tableaux.

Plus vous gagnerez en expérience et en confiance, plus vous utiliserez moins de stylo et de papier. Vous saurez déjà comment utiliser les concepts de base tels que les boucles, etc. Vous aurez des exemples dans d'autres programmes, que vous pouvez réutiliser. Vous utiliserez le compilateur et un IDE pour trouver des bugs évidents lors de l'écriture du programme. En ce moment même si tu n’as pas cette expérience.

En lisant votre question, je me demande si certains de vos problèmes pourraient être dus à la concentration. Si utiliser un stylo et du papier dans un environnement calme vous aide à bien vous concentrer.

Tu es toujours à la fac et tu apprends toujours. En fin de compte, tout ce que vous faites est ce qui fonctionne pour vous. Si, en utilisant du papier et un stylo, vous commandez vos pensées et que vous pensez clairement et calmement, vous programmez.

Mon code est bien mieux organisé lorsque je note et aborde des notes et des notes sur un bloc-notes, des chéquiers, des sites Web et que j'y réfléchis. Je suis aussi beaucoup plus visuel, donc dessiner des images avec des structures de données est très utile. Je n'écris pas chaque ligne, mais je griffonne ce que je considère comme des fragments «importants» ou des fonctionnalités clés. Pour les projets plus importants, je lance Visio. Je ne suis pas sûr de savoir pourquoi quelqu'un préconiserait de sauter directement sur un clavier à moins d'être beaucoup plus efficace ou de ne pas être payé à l'heure.

Faites ce qui vous convient le mieux. Je n'écrirais pas de code sur papier. J'écris des pseudo-codes et dessine des organigrammes sur du papier, mais écrire le code complet semble être une perte de temps.

Je suis également confronté au même problème lors de ma première journée d’acquisition de compétences techniques.

Mais cette pratique type ne devrait pas donner le succès à 100%, car si nous écrivons du code sur papier, nous n’avons aucune chance de corriger un bogue, nous avons une chance de résoudre les erreurs et les exceptions lorsqu’il s’agit de travailler sur papier.

Ainsi, le travail sur papier ne permet pas la navigation pour résoudre les problèmes. Et nous pouvons obtenir la vitesse de frappe en prime en raison de la pratique du système.

Je travaille également sur papier, mais lorsque, avant d’implémenter mes fonctionnalités, il ne reste plus qu’à effectuer une estimation approximative. Je vais alors commencer mon implémentation sur le système.

S'il vous plaît essayez de passer plus de temps sur la pratique du système. Cela donnera 100% de confiance et de résultat.