Processus pour passer du problème au code. Comment as tu appris?

Question

J'enseigne / aide un étudiant à programmer.

Je me souviens que le processus suivant m’a toujours aidé au début; Cela semble assez intuitif et je me demande si quelqu'un d'autre a eu une approche similaire.

1. Lisez le problème et comprenez-le (bien sûr).
2. Identifiez les "fonctions" " possibles et variables.
3. Ecrivez comment je le ferais étape par étape (algorithme)
4. Traduisez-le en code, si vous ne pouvez pas faire quelque chose, créez une fonction qui le fait pour vous et continuez à vous déplacer.

Avec le temps et la pratique, il me semble avoir oublié à quel point il était difficile de passer de la description du problème à une solution de codage, mais en appliquant cette méthode, j'ai réussi à apprendre à programmer.

Donc, pour une description du projet comme:

  

Un système doit calculer le prix d'un article en fonction des règles suivantes (description des règles ... client, remises, disponibilité, etc., etc.)

Je commence par comprendre le problème.

Identifiez ensuite l'élément, les règles les variables, etc.

pseudo-code quelque chose comme:

function getPrice( itemPrice, quantity , clientAge, hourOfDay ) : int 
   if( hourOfDay > 18 ) then
      discount = 5%

   if( quantity > 10 ) then
      discount = 5%

   if( clientAge > 60 or < 18 ) then
      discount = 5%


        return item_price - discounts...
end

Et passez le ensuite au langage de programmation ..

public class Problem1{
    public int getPrice( int itemPrice, int quantity,hourOdDay ) {
        int discount = 0;
        if( hourOfDay > 10 ) {
             // uh uh.. U don't know how to calculate percentage... 
             // create a function and move on.
            discount += percentOf( 5, itemPriece );
            .
            .
            .
            you get the idea..

        }
     }
    public int percentOf( int percent, int i ) {
             // .... 
    }


}

Avez-vous adopté une approche similaire? .. Est-ce que quelqu'un vous a enseigné une approche similaire ou vous êtes-vous découvert (comme je l'ai fait :()

Answer 1

J'ai fait quelque chose de similaire.

• Déterminez les règles / la logique.
• Calculez le calcul.
• Ensuite, essayez de le coder.

Après avoir fait cela pendant quelques mois, tout est intériorisé. Vous ne réalisez pas que vous le faites avant de vous heurter à un problème complexe qui vous oblige à le décomposer.

Answer 2

Je passe par l'approche basée sur les tests.

1. J'écris (sur un support papier ou un éditeur de texte) une liste de tests ou de spécifications répondant aux besoins du problème.

- simple calculations (no discounts and concessions) with:
    - single item
    - two items
    - maximum number of items that doesn't have a discount
- calculate for discounts based on number of items
    - buying 10 items gives you a 5% discount
    - buying 15 items gives you a 7% discount
    - etc.
- calculate based on hourly rates
    - calculate morning rates
    - calculate afternoon rates
    - calculate evening rates
    - calculate midnight rates
- calculate based on buyer's age
    - children
    - adults
    - seniors
- calculate based on combinations
    - buying 10 items in the afternoon

2. Recherchez les éléments que je pense être les plus faciles à implémenter et écrivez un test pour cela. Les articles simples, par exemple, semblent faciles

L'échantillon utilisant Nunit et C #.

[Test] public void SingleItems()
{
    Assert.AreEqual(5, GetPrice(5, 1));
}

Implémentez cela en utilisant:

public decimal GetPrice(decimal amount, int quantity)
{
    return amount * quantity; // easy!
}

Passez ensuite aux deux éléments.

[Test]
public void TwoItemsItems()
{
    Assert.AreEqual(10, GetPrice(5, 2));
}

L'implémentation réussit toujours le test, passez donc au test suivant.

3. Soyez toujours à l'affût des doublons et supprimez-les. Vous avez terminé lorsque tous les tests sont réussis et vous ne pouvez plus penser à aucun test.

Cela ne garantit pas que vous créerez l'algorithme le plus efficace, mais tant que vous savez quoi tester et que tout se passe bien, cela garantira que vous obtenez les bonnes réponses.

Answer 3

la méthode OO de la vieille école:

• écrivez une description du problème et de sa solution
• entourez les noms, ce sont des objets candidats
• dessinez des boîtes autour des verbes, ce sont des messages candidats
• groupez les verbes avec les noms qui «feraient» l’action; liste tous les autres noms qui seraient nécessaires pour aider
• voyez si vous pouvez reformuler la solution en utilisant la forme nom.verb (autres noms)
• le code

[cette méthode précède les cartes CRC, mais ça fait si longtemps (plus de 20 ans) que je ne me souviens pas où je l’ai apprise]

Answer 4

en apprenant la programmation, je ne pense pas que TDD soit utile. TDD est utile plus tard lorsque vous avez une idée de la programmation, mais, pour commencer, disposer d’un environnement dans lequel vous écrivez du code et visualisez les résultats le plus rapidement possible est le facteur le plus important.

Je passerais de la déclaration du problème au code instantanément. Hack it around. Aidez l’élève à comprendre différentes manières de composer des logiciels / des algorithmes de structuration. Apprenez à l’élève à changer d’avis et à retravailler le code. Essayez d’enseigner un peu l’esthétique du code.

Une fois qu’ils peuvent pirater le code ..., introduisez l’idée d’une restructuration formelle en termes de refactorisation. Puis introduisez l’idée de TDD comme moyen de rendre le processus un peu plus robuste. Mais une seule fois, ils se sentent à l'aise pour manipuler du code afin de faire ce qu'ils veulent. Pouvoir spécifier des tests est alors un peu plus facile à ce stade. La raison en est que TDD concerne le design. Lorsque vous apprenez, vous ne vous souciez pas vraiment de la conception, mais de ce que vous pouvez faire, avec quels jouets devez-vous jouer, comment fonctionnent-ils, comment les combinez-vous. Une fois que vous avez une idée de cela, alors vous voulez penser à la conception et c'est à ce moment-là que TDD entre vraiment en jeu.

À partir de là, je commencerais à introduire des micro-modèles menant à des modèles de conception

Answer 5

Je commence au sommet et je descends. En gros, je vais commencer par écrire une procédure de haut niveau, esquisser les détails à l’intérieur de celle-ci, puis commencer à les compléter.

Disons que j'ai eu ce problème (du projet euler)

  

La somme des carrés du premier   dix nombres naturels est, 1 ^ 2 + 2 ^ 2 +   ... + 10 ^ 2 = 385

     

Le carré de la somme des dix premiers   nombres naturels est, (1 + 2 + ... +   10) ^ 2 = 55 ^ 2 = 3025

     

D'où la différence entre la somme   des carrés des dix premiers   nombres naturels et le carré du   la somme est 3025 385 = 2640.

     

Trouvez la différence entre la somme de   les carrés des cent premiers   nombres naturels et le carré du   somme.

Je commence donc comme ça:

(display (- (sum-of-squares (list-to 10))
            (square-of-sums (list-to 10))))

Maintenant, dans Scheme, il n’existe pas de somme de carrés, de carrés de sommes ni de fonctions de liste. La prochaine étape serait donc de construire chacun de ceux-ci. En construisant chacune de ces fonctions, il se peut que j’ai besoin d’abstraire davantage. J'essaie de garder les choses simples afin que chaque fonction ne fasse qu'une chose. Lorsque je construis une fonctionnalité testable, j'écris un test unitaire pour elle. Lorsque je commence à remarquer un regroupement logique pour certaines données et les fonctions qui les exploitent, je peux le pousser dans un objet.

Answer 6

J'ai apprécié le TDD depuis qu'il m'a été présenté. M'aide à planifier mon code et me met à l'aise avec le retour de tous mes tests avec "succès". chaque fois que je modifie mon code, il me fait savoir que je rentre à l'heure à la maison aujourd'hui!

Answer 7

La fantaisie est probablement l’outil le plus important pour résoudre des problèmes complexes. En cas de doute, supposez qu’une fonction existe pour résoudre votre problème (créez un talon, au début). Vous y reviendrez plus tard pour l'agrandir.

Answer 8

Un bon livre pour les débutants à la recherche d'un processus: Développement piloté par les tests: par exemple

Answer 9

Mon père avait un tas de pochoirs à organigrammes qu'il m'avait l'habitude d'utiliser quand il m'apprenait pour la première fois à programmer. à ce jour, je dessine des carrés et des diamants pour élaborer un processus logique d'analyse des problèmes.

Answer 10

Je pense connaître une douzaine d'heuristiques différentes en matière de programmation et j'ai donc tendance à parcourir la liste de temps à autre avec ce que j'essaie de faire. Au début, il est important de savoir quel est le résultat final souhaité, puis de revenir en arrière pour le trouver.

Je me souviens d'une classe d'algorithmes couvrant certaines des méthodes suivantes:

• Réduisez-le à un problème connu ou à un problème trivial
• Divisez pour conquérir (MergeSort étant un exemple classique ici)
• Utilisez des structures de données qui ont les bonnes fonctions (HeapSort étant un exemple ici)
• Récursion (connaître des solutions triviales et pouvoir les réduire)
• Programmation dynamique

Organiser une solution et la tester pour des situations inhabituelles, par ex. si quelqu'un pense que L devrait être un nombre, c'est ce que j'utiliserais habituellement pour tester l'idée en pseudo-code avant de l'écrire.

Les modèles de conception peuvent constituer un ensemble d'outils pratiques à utiliser dans des cas spécifiques, tels qu'un adaptateur ou l'organisation d'éléments dans une solution d'état ou de stratégie.

Answer 11

Oui .. eh bien, le TDD n’existait pas (ou n’était pas aussi populaire) quand j’ai commencé. TDD serait-il la solution pour passer de la description du problème au code? ... N'est-ce pas un peu avancé? Je veux dire, quand un "avenir" développeur à peine comprendre ce qu'est un langage de programmation, ne serait-il pas contre-productif?

Qu'en est-il de hamcrest qui effectue la transition d'algorithme en code.

Answer 12

Je pense qu'il existe un meilleur moyen de formuler votre problème.

Au lieu de le définir comme "un système", définissez ce que vous attendez en termes d'entrées et de sorties utilisateur.

"Sur une fenêtre, un utilisateur doit sélectionner un élément dans une liste et un encadré doit lui indiquer le coût."

Ensuite, vous pouvez lui expliquer certains des facteurs déterminant les coûts, notamment les exemples d'éléments et leur coût éventuel.

(c’est aussi une idée de type TDD)

Answer 13

N'oubliez pas que si vous bénéficiez de 5% de réduction, puis de 5% supplémentaires, vous n'obtiendrez pas 10% de réduction. Au lieu de cela, vous payez 95% de 95%, ce qui représente 90,25% ou 9,75% de réduction. Donc, vous ne devriez pas ajouter le pourcentage.