Savoir s'il est mieux d'utiliser une liste comme structure de données, ou une matrice d'incidence, ou un tas de fibonacci, ou un AVL... Tout ça, ca peut être dans un développement d'application critique une tache d'ingénierie bien plus poussée qu'un simple pissage de code "allez, j'aime bien les listes".
Les cas critiques, le choix des algos, les méthodes de gestions des types et des zones mémoires je fais tout çà bien avant de me mettre devant mon ordinateur pour programmer.
Quand je suis devant mon ordinateur les décisions que je prend sont : 'ici je fais une boucle for ou un while ?' et 'Pour la lisibilité du code je créé un type ou bien je laisse la notation pointeur telle quelle ?'
Parfois (mais je fais tout pour que ce soit le plus rare possible) je me retrouve à devoir faire des casts à la con. Et dans ces cas là je epux me retrouver au beau milieu du code à avoir des réflexions de type ingénérique.
Maintenant il est vrai que le choix d'une structure particulière dans un langage peut ammener des cas critiques et alourdir bêtement le code, voir plomber le logiciel. Il faut par exemple savoir que les comparaison bit à bit en java c'est rarement une bonne idée, qu'un switch case en C# est plus rapide qu'un eleseif pour une raison obscure, qu'Erlang gère mal les conversions implicites de tableaux en vecteurs etc. Mais çà qu'on le veuille ou non, c'est de la technique. C'est lié au moteur, à la plateforme, au langage, à la lib ou au joyeux mélange de tout çà. De même les réglages de machine virtuelles aux petits oignons, et les partionnement d'espaces mémoires pour le cache sont purements du domaine de la technique.
Maintenant soyons bien clair, contrairement à 99% des recruteurs francais je ne considère pas le techos comme un sous ingénieur raté et/ou incapable. Le technicien et l'ingénieur ont des rôles complètement différents vis à vis d'un programme. Longtemps les deux rôles ont étés confondus (parcequ'il était quasiment impossible lors de l'écriture d'un programme de s'abstraire du matériel et du logiciel sous-jacent). Mais on peut aujourd'hui raisonablement séparer les deux rôles. L'ingénieur qui est en charge de l'algorithmique, des choix techniques et des preuves du programme. Et le technicien qui est en charge de determiner la faisabilité du programme d'après les choix techniques de l'ingénieur, d'implémenter les algorithmes et de vérifier la tenue du tout.
Passer du pseudo code, ou de l'algorithme à un vrai code qui compile et qui tourne bien peut etre plus ardu que tu ne sembles le croire...
Je n'ai jamais dit que c'était facile (à moins que l'on considère que si même un technicien peut le faire, alors c'est forcément évident pour toute personne ayant vu un clavier une fois dans sa vie), j'ai dit que celà relevait de la technique et non de l'ingénérie.
Il arrive qu'en codant on trouve une approche radicalement nouvelle pour résoudre/traiter un problème. Mais c'est extrèmement rare, la plupart du temps, résoudre le problème consiste à choisir parmis X solutions archi-connues celle qui va permettre de garder un code lisible, évolutif, maintenable et fiable.
C'est un problème qui n'a rien de simple, qui est même parfois horriblement complexe (lorsque l'on essaye de faire rentrer un algo dans une machine manifestement trop petite par exemple), c'est un problème qui peut être passionnant, mais ca reste un problème technique.
[^] # Re: Simple
Posté par Jerome Herman . En réponse au journal une grève ?. Évalué à 0.
Les cas critiques, le choix des algos, les méthodes de gestions des types et des zones mémoires je fais tout çà bien avant de me mettre devant mon ordinateur pour programmer.
Quand je suis devant mon ordinateur les décisions que je prend sont : 'ici je fais une boucle for ou un while ?' et 'Pour la lisibilité du code je créé un type ou bien je laisse la notation pointeur telle quelle ?'
Parfois (mais je fais tout pour que ce soit le plus rare possible) je me retrouve à devoir faire des casts à la con. Et dans ces cas là je epux me retrouver au beau milieu du code à avoir des réflexions de type ingénérique.
Maintenant il est vrai que le choix d'une structure particulière dans un langage peut ammener des cas critiques et alourdir bêtement le code, voir plomber le logiciel. Il faut par exemple savoir que les comparaison bit à bit en java c'est rarement une bonne idée, qu'un switch case en C# est plus rapide qu'un eleseif pour une raison obscure, qu'Erlang gère mal les conversions implicites de tableaux en vecteurs etc. Mais çà qu'on le veuille ou non, c'est de la technique. C'est lié au moteur, à la plateforme, au langage, à la lib ou au joyeux mélange de tout çà. De même les réglages de machine virtuelles aux petits oignons, et les partionnement d'espaces mémoires pour le cache sont purements du domaine de la technique.
Maintenant soyons bien clair, contrairement à 99% des recruteurs francais je ne considère pas le techos comme un sous ingénieur raté et/ou incapable. Le technicien et l'ingénieur ont des rôles complètement différents vis à vis d'un programme. Longtemps les deux rôles ont étés confondus (parcequ'il était quasiment impossible lors de l'écriture d'un programme de s'abstraire du matériel et du logiciel sous-jacent). Mais on peut aujourd'hui raisonablement séparer les deux rôles. L'ingénieur qui est en charge de l'algorithmique, des choix techniques et des preuves du programme. Et le technicien qui est en charge de determiner la faisabilité du programme d'après les choix techniques de l'ingénieur, d'implémenter les algorithmes et de vérifier la tenue du tout.
Passer du pseudo code, ou de l'algorithme à un vrai code qui compile et qui tourne bien peut etre plus ardu que tu ne sembles le croire...
Je n'ai jamais dit que c'était facile (à moins que l'on considère que si même un technicien peut le faire, alors c'est forcément évident pour toute personne ayant vu un clavier une fois dans sa vie), j'ai dit que celà relevait de la technique et non de l'ingénérie.
Il arrive qu'en codant on trouve une approche radicalement nouvelle pour résoudre/traiter un problème. Mais c'est extrèmement rare, la plupart du temps, résoudre le problème consiste à choisir parmis X solutions archi-connues celle qui va permettre de garder un code lisible, évolutif, maintenable et fiable.
C'est un problème qui n'a rien de simple, qui est même parfois horriblement complexe (lorsque l'on essaye de faire rentrer un algo dans une machine manifestement trop petite par exemple), c'est un problème qui peut être passionnant, mais ca reste un problème technique.