Le processus de création en informatique

Bonsoir Raoul,

Pour aller dans ton sens, je te pousse cet article https://sametmax.com/reaction-a-reactjs/ écrit par un expert Python. Le site est fermé, mais reste toujours très bon pour le côté informatique (pour le reste il faut être connaisseur ... )

La bonne conclusion est la PEP 20 de python: https://www.python.org/dev/peps/pep-0020/

Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently. Unless explicitly silenced.

In the face of ambiguity, refuse the temptation to guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than *right* now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!

Amicalement.

S.

Tout cela est fort juste S..

Et conforme à mes pensées profondes.

Mais la création se passe toujours en 2 étapes :

Tout faire pour trouver une solution, même si c'est compliqué.

1. Dès qu'une solution a été trouvée, simplifier au maximum, en reprenant pas à pas la méthode compliquée qui a permis ce résultat , et trouver une nouvelle méthode, plus simple, mieux documentée et plus facile à maintenir.

Cela fait 8 ans que je fonctionne comme cela. Seul pour tout faire. Ce n'est peut-être pas joli, mais efficace, puisque le résultat général est là et probant. Mais je retrouve régulièrement des erreurs, car il y a 70000 lignes de code, pour ce programme de sudoku sur internet. Heureusement que l'on trouve plein de résultats sur internet qui sont très utiles, surtout quand les explications se basent sur des exemples.

L'apprentissage, mieux que la théorie. Et je retrouve régulièrement dans le programme des codes mal foutus, même si cela fonctionne quand même. Et la méthode est toujours la même :

1. Multiplier les exemples, et les étudier jusqu'au bout.

2. Dès qu'une erreur apparaît, reprendre pas à pas, en explorant les zones susceptibles de générer une erreur. Travail ingrat et payant. Car l'erreur est rarement là où on croit qu'elle est.

J'ai corrigé ainsi 3 erreurs ce week-end, et je suis sur une nouvelle erreur, que je viens de localiser. Et je suis confiant pour la corriger. Car, au fil du temps, j'ai bâti des outils efficaces, pour, à la fois corriger les erreurs de syntaxe mais aussi et avant tout les erreurs d'analyse. Bien sûr, en corrigeant, on introduit de nouvelles erreurs, heureusement plus faciles à traiter. C'est cette expérience, et le résultat probant obtenu, que je veux populariser.

Après le savoir-faire, le savoir expliquer. Amicalement. Raoul