L'algorithmie pour les nuls ou l'histoire du littéraire qui galère

[Grosnours]

Avant que tu sautes par la fenêtre, rappelles toi quand même que les informaticiens étant très fainéant, on ne compte que jusqu'à deux. Donc le mal est moindre....

[Septa]

Avant que tu sautes par la fenêtre, rappelles toi quand même que les informaticiens étant très fainéant, on ne compte que jusqu'à deux. Donc le mal est moindre....

C'est pas faut ça...

Un bon codeur est un codeur fainéant... Mais des fois on fait pleins d'effort pour pouvoir être fainéant...


Et heu...
Enfin la logique informatique c'est pas non plus des maths très compliqué... Enfin ça dépend du domaine dans lequel on bosse.
Mais dans pas mal de cas, la plus part du temps c'est surtout "que de la logique".

Enfin je me comprends...

[L-F. Sébum]

Avant que tu sautes par la fenêtre, rappelles toi quand même que les informaticiens étant très fainéant

Ca me rappelle un truc pas idiot que m'a dit un pote informaticien :

Dans la plupart des domaines techniques, faire un essai est coûteux (en matières premières, par exemple) du coup les ingénieurs prennent le temps de planifier et de réfléchir avant d'agir.

En informatique c'est différent. Au pire, si ça foire, on change deux lignes de code et on compile à nouveau. Résultat : la technique "essai/erreur" est beaucoup plus tentante.

[Grosnours]

Enfin la logique informatique c'est pas non plus des maths très compliqué...

Enfin ca peut devenir assez tendu quand meme en informatique parrallele, en theorie des grahes ou autres machines de Turing....

Enfin ça dépend du domaine dans lequel on bosse.
Mais dans pas mal de cas, la plus part du temps c'est surtout "que de la logique".

Oui, bien d'accord.

Ca me rappelle un truc pas idiot que m'a dit un pote informaticien :

Dans la plupart des domaines techniques, faire un essai est coûteux (en matières premières, par exemple) du coup les ingénieurs prennent le temps de planifier et de réfléchir avant d'agir.

En informatique c'est différent. Au pire, si ça foire, on change deux lignes de code et on compile à nouveau. Résultat : la technique "essai/erreur" est beaucoup plus tentante.

L'éternel problèmes du besoin de la spécification et de la preuve de programme (tiens encore un truc un peu chaud, d'ailleurs).

D'ou le fait qu'on utilise ces techniques que si on a pas le droit a l'erreur (lancement spatiaux par exemple, et oui je sais Ariane V s'est plante pour une rreur d'informatique, mais disons que c'est l'exception qui confirme la regle...)

[Djal]

C'est pas faut ça...
Un bon codeur est un codeur fainéant...

Je suis un codeur de génie

[Lazyjoe]

Je suis un codeur de génie

Il n'y a de place que pour un seul Lazy sur ce forum, étranger....

[Septa]

Je suis un codeur de génie

Le pire étant que le prof qui nous expliquait ça défendait la chose très bien...

Le bon informaticien il "factorise" un maximum son code parce que comme ça c'est moins fatigant de corriger les bugs tu le fait à un seul endroit.
Il fait un code clair pour pas se creuser la tête quand il y revient trois mois après.
Etc...

Du coup on fait plein d'effort pour en faire le moins possible au final...
C'est beau l'info.

[Therapy2crew]

Ma seule expérience avec la programation, ça a été au lycée avec ma casio.
Je me souviens que je faisais mes lignes avec Goto, if, then, conneries ... je pense pas que je serai capables de le refaire maintenant ...

Mais il était vachement bien mon petit jeu, fallait faire avancer un dièse sur un symbole "étoile" et là tu tombait sur un ennemi et ...

[Lazyjoe]

Le pire étant que le prof qui nous expliquait ça défendait la chose très bien...

Le bon informaticien il "factorise" un maximum son code parce que comme ça c'est moins fatigant de corriger les bugs tu le fait à un seul endroit.
Il fait un code clair pour pas se creuser la tête quand il y revient trois mois après.
Etc...

Du coup on fait plein d'effort pour en faire le moins possible au final...
C'est beau l'info.

Mieux la programmation générique, tu te casse la tête comme un fou à faire fonctionner une structure ou une fonction générique, et après tu la réutilise avec plein de types de données différents.

[Guest62019]

Mieux la programmation générique, tu te casse la tête comme un fou à faire fonctionner une structure ou une fonction générique, et après tu la réutilise avec plein de types de données différents.

Par générique, t'entends l'utilisation des wildcards ?

[Jeremy]

Aller hop, allons y pour les conseils surement déjà donné.
- commencer par la logique booléenne
- enchaîner avec les automates
- continuer avec les bases de l'algo (algos simple, preuves d'algo etc.)
- puis, les algos un poil plus relous : les tris
- qui dit tri, dit structures. Donc tout d'abord les arbres
- puis les graphes, car les graphes, c'est la vie

Avec ça, tu as de quoi te bourrer le mou pendant quelques mois.
Et si tu te mets à aimer les algorithmes, le parallélisme t'attend avec ses algos efficaces pas encore trouvés.

[Lazyjoe]

Par générique, t'entends l'utilisation des wildcards ?

Bah la généricité au sens large, ça varie pas mal selon les langages utilisés je pense, genre les templates en C.

[Yasko]

Ca me rappelle un truc pas idiot que m'a dit un pote informaticien :

Dans la plupart des domaines techniques, faire un essai est coûteux (en matières premières, par exemple) du coup les ingénieurs prennent le temps de planifier et de réfléchir avant d'agir.

En informatique c'est différent. Au pire, si ça foire, on change deux lignes de code et on compile à nouveau. Résultat : la technique "essai/erreur" est beaucoup plus tentante.

Tu as même une technique de développement (TDD pour ne pas la citer) qui consiste à commencer par faire échouer ton programme.
Tu commences par écrire un test du comportement que tu souhaites implémenter. Si c'est une nouvelle classe / méthode / signature de méthode, ton code ne va plus compiler, la 1ère étape sera donc de faire en sorte qu'il compile à nouveau (créer une méthode creuse par exemple).
Ensuite, il faut faire en sorte que le test réussisse (que la méthode ramène le bon résultat par exemple).

[magnifique nom]

Aller hop, allons y pour les conseils surement déjà donné.
- commencer par la logique booléenne
- enchaîner avec les automates
- continuer avec les bases de l'algo (algos simple, preuves d'algo etc.)
- puis, les algos un poil plus relous : les tris
- qui dit tri, dit structures. Donc tout d'abord les arbres
- puis les graphes, car les graphes, c'est la vie

Heum heum, il faudrait peut etre voir les structures de données avant les algos machin toussa, enfin je dis ça je dis rien

J'espere que le prof de bellorophon est aussi au courant.

sinon en bouquin, je me rappelle plus du titre mais il y avait un gros pavé vachement bien foutu, je crois que c'est ça, peut etre deja conseillé.

[Yasko]

Bah la généricité au sens large, ça varie pas mal selon les langages utilisés je pense, genre les templates en C.

Oui, ou d'une manière générale : les design patterns (ou bonnes pratiques de conception).

Elles font que l'on a un code plus facilement maintenable (faible couplage, pas de redondance de code, etc.).
Avoir un code maintenable est très important lorsque l'on développe de manière itérative (agilité...) car le code est très fréquemment modifié. Avoir une bonne conception permet de limiter l'accouchement des nouvelles fonctionnalités dans la douleur, et que la qualité de l'application se dégrade au fur et à mesure qu'elle évolue.

Tu as des design patterns techniques (le singleton est probablement le plus connu) et des design patterns d'architecture (MVC par exemple).

[Lazyjoe]

De toutes façons la meilleure méthode de développement, c'est http://www.cafenware.com/la-rache/

[psycho_fox]

EDIT : oh putain on a eu la même idée ...

[L-F. Sébum]

Tu as même une technique de développement (TDD pour ne pas la citer) qui consiste à commencer par faire échouer ton programme.
Tu commences par écrire un test du comportement que tu souhaites implémenter. Si c'est une nouvelle classe / méthode / signature de méthode, ton code ne va plus compiler, la 1ère étape sera donc de faire en sorte qu'il compile à nouveau (créer une méthode creuse par exemple).
Ensuite, il faut faire en sorte que le test réussisse (que la méthode ramène le bon résultat par exemple).

Tiens, comme Monsieur Jourdain qui faisait de la prose sans le savoir, je fais de la TDD sans le savoir...

C'est exactement la méthode que j'ai utilisée pour écrire un système de classes dans un jeu (classe abstraite "entité" d'où sont dérivées les classes "objet", "créature", etc...).

EDIT: Et le pire est qu'à la fin j'ai obtenu un code nickel chrome, que je n'aurais sûrement jamais eu en planifiant tout à l'avance (je suis trop feignant pour ça)

[johnnyblaguos]

C'est aussi surtout qu'avec les design patterns, tu réinventes pas la roue et t'as du concept déja tout bien.

[Lazyjoe]

EDIT : oh putain on a eu la même idée ...

Je t'aime ! Fais-moi des petits renardeaux blonds !

Sinon on va en discuter au café, ou alros on abandonne de suite ?

[Jeremy]

Heum heum, il faudrait peut etre voir les structures de données avant les algos machin toussa, enfin je dis ça je dis rien

Plutôt en même temps. Parce que les structures seules, c'est ce qu'on avait tenté de me faire apprendre et ça n'avait pas réussi la première fois. C'est pas que ça paraît totalement inutile, mais presque.
"- Voilà, ça c'est un arbre binaire.
- Cool, ça sert à quoi ?
- Attend, on va maintenant voir les arbres équilibrés.
- zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz."

[psycho_fox]

Des lazy fox non mais t'imagines ...

[Jeremy]

Tu as même une technique de développement (TDD pour ne pas la citer) qui consiste à commencer par faire échouer ton programme.
Tu commences par écrire un test du comportement que tu souhaites implémenter. Si c'est une nouvelle classe / méthode / signature de méthode, ton code ne va plus compiler, la 1ère étape sera donc de faire en sorte qu'il compile à nouveau (créer une méthode creuse par exemple).
Ensuite, il faut faire en sorte que le test réussisse (que la méthode ramène le bon résultat par exemple).

Euh, sauf erreur, la TDD (Test Driven Development) ce n'est pas du BDD (Bug Driven Development : ton truc, faire échouer ton code wtf).
Le truc est de préparer les tests avant de coder.
Puis de coder tes méthodes/fonctions et voir si ça passe tes tests. En ajoutant une méthode par contrat (post-condition, pre-conditions, invariables) ça commence à devenir robuste.

Mais trés relou car en fait les tests doivent eux-mêmes être programmé ce qui reportent le problème des vérifications. L'avantage étant aprés, comme on a automatiquement tous les tests faits, faire des vérifications de regression est simplifié.

[Yasko]

De toutes façons la meilleure méthode de développement, c'est http://www.cafenware.com/la-rache/

J'ai fait tourner sur la messagerie interne.
Si ca se trouve, on est déja à la RACHE compliant...

[Yasko]

Euh, sauf erreur, la TDD (Test Driven Development) ce n'est pas du BDD (Bug Driven Development : ton truc, faire échouer ton code wtf).
Le truc est de préparer les tests avant de coder.
Puis de coder tes méthodes/fonctions et voir si ça passe tes tests. En ajoutant une méthode par contrat (post-condition, pre-conditions, invariables) ça commence à devenir robuste.

Le BDD que je connais, c'est behavior driven development : http://behaviour-driven.org/
Sinon, oui, c'est ça. C'est du "test first". Dans ce mode de développement, les tests font office de spécifications, de commentaires de code (pour savoir ce qu'est censé faire une appli, regarde ses tests, les commentaires, c'est mal ), et... de tests.
Faire échouer la compilation n'est qu'une conséquence.
Ecrire le test en 1er permet d'écrire la fonctionnalité telle que l'on voudrait qu'elle se comporte d'un point de vue extérieur (appel d'une méthode par exemple).
Cela permet également de rester focalisé sur l'objectif en cours qui est de faire réussir ton test, ni plus ni moins. Si ton test est :
assertEquals(add(3,4), 7), tu peux implémenter une méthode add(x, y) qui fait contient uniquement un return 7.
Si le comportement de ton application n'est pas complet, c'est qu'il te manque des tests.

Il y a plein de docs sur le net sur le TDD. Un des meilleurs bouquins est celui de Kent Beck.

Mais trés relou car en fait les tests doivent eux-mêmes être programmé ce qui reportent le problème des vérifications. L'avantage étant aprés, comme on a automatiquement tous les tests faits, faire des vérifications de regression est simplifié.

C'est un peu plus long au départ puisqu'il faut effectivement écrire le test en 1er (un seul hein, on itère, test, implémentation, test, implémentation, ...), mais on constitue ainsi une suite de non régression avec un taux de couverture très important.
Ce qui facilite ensuite la maintenance (on sait facilement si la modif qui nous paraissait pourtant si anodine a en fait complètement cassé notre appli).

[Jeremy]

Jusqu'au jour où tu dois changer tes specs (méthodes agiles) et où il faut changer les tests et les retester.
J'attends impatiemment le TDD appliqué au dév des tests.

[Yasko]

TDD est une des méthodes les plus utlisées pour l'agilité.
Changer tes specs revient à changer tes tests puisque tes tests sont tes specs. Il y a même des outils comme FIT, GreenPepper, JBehave, RSpec, Concordia, ... qui permettent "d'externaliser" une partie des tests afin que les personnes non techniques (MOA par exemple) puissent agir (comprendre, écrire) sur les tests.

D'une manière générale, on ne fait pas de tests pour tester les tests de code, car on considère qu'ils sont suffisamment élémentaires et simples (notamment pour les tests unitaires, ça peut se compliquer un peu pour les tests d'intégration) pour ne pas avoir à les tester, mais dans la pratique, on les teste quand même, mais sans formaliser ces tests de tests.

Ce n'est pas vrai pour les automates de test d'IHM par exemple qui eux sont des applications à part entière, et idéalement nécessitent d'être testés (manuellement). Dans la pratique, c'est rarement le cas, c'est déjà bien qu'un projet automatise ses tests.

[johnnyblaguos]

Arrêtez de le faire flipper bordel. Pourquoi ne pas l'achever en lui parlant d'assembleur, de latchs, de z80 et de "la matière qui ne peut pas être mise en pratique qui implique des pid et des jetons ainsi que des moyennes annuelles de 05/20".

[bellerophon_mwc]

:monte sur un tabouret et passe sa tête dans un noeud coulant:

"Adieu monde crue..Aaaarghhhl"

[Yasko]

Attend, remonte, je crois que Tramb veut te parler de comment on optimise en assembleur.

Nan mais c'était juste un aparté, et ça concerne plus les méthodes de développement que la programmation en elle-même (donc plutôt un HS qu'un aparté en fait).
Commence par le commencement.