On ne flanque pas le premier volume du tome un des oeuvres de
Bourbaki au CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge
On ne flanque pas le premier volume du tome un des oeuvres de
Bourbaki au CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge
On ne flanque pas le premier volume du tome un des oeuvres de
Bourbaki au CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.
Je crois ne jamais avoir vu d'exemple de code étant censé illustrer
le danger des variables globales.
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.
Je crois ne jamais avoir vu d'exemple de code étant censé illustrer
le danger des variables globales.
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.
Je crois ne jamais avoir vu d'exemple de code étant censé illustrer
le danger des variables globales.
En news:47d6ec6b$0$17413$, candide va escriure:On ne flanque pas le premier volume du tome un des oeuvres de
Bourbaki au CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge
Contrairement aux femmes, les hommes n'ont pas de ménopause ;
En news:47d6ec6b$0$17413$426a74cc@news.free.fr, candide va escriure:
On ne flanque pas le premier volume du tome un des oeuvres de
Bourbaki au CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge
Contrairement aux femmes, les hommes n'ont pas de ménopause ;
En news:47d6ec6b$0$17413$, candide va escriure:On ne flanque pas le premier volume du tome un des oeuvres de
Bourbaki au CP. Je le sais, mon aine est au CP.
Tiens, j'avais surévalué ton âge
Contrairement aux femmes, les hommes n'ont pas de ménopause ;
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Comme quoi, un prof en vrai, c'est pas plus mal ;-)
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.
Ben oui. "errno" par exemple.
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Comme quoi, un prof en vrai, c'est pas plus mal ;-)
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.
Ben oui. "errno" par exemple.
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Comme quoi, un prof en vrai, c'est pas plus mal ;-)
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.
Ben oui. "errno" par exemple.
[...] on serait en train de dire que presque tous les artisans
ne font pas le trvail dans les règles de l'art.
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de
ne pas écrire de variables globales ????
[...] on serait en train de dire que presque tous les artisans
ne font pas le trvail dans les règles de l'art.
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de
ne pas écrire de variables globales ????
[...] on serait en train de dire que presque tous les artisans
ne font pas le trvail dans les règles de l'art.
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de
ne pas écrire de variables globales ????
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Non, ce n'est pas pareil, si je te suis on serait en train de dire que
presque tous les artisans ne font pas le trvail dans les règles de l'art.
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Pas du tout, il certainement possible d'expliquer l'idée avec quelques
exemples bien choisis.
Et à ce compte-là, un cours de C ne parle pas de compilation séparée
(d'ailleurs K&R est très léger là-dessus) ou d'oganisation des fichiers
source et des headers (par contre, ça ils en parle).
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants est
capable d'avoir en tête l'organisation d'un code d'environ 5000 lignes,
développé sur 2 mois, sans avoir réellement besoin de conception,
méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de ne
pas écrire de variables globales ????
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
En effet.mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
Le C _d'abord_, la programmation structurée _ensuite_, l'algorithmique
certainement pas (c'est une des erreurs du K&R), ce n'est pas l'objet d'un
cours de C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.
Ça a tout à fait sa place dans un livre.
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Non, ce n'est pas pareil, si je te suis on serait en train de dire que
presque tous les artisans ne font pas le trvail dans les règles de l'art.
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Pas du tout, il certainement possible d'expliquer l'idée avec quelques
exemples bien choisis.
Et à ce compte-là, un cours de C ne parle pas de compilation séparée
(d'ailleurs K&R est très léger là-dessus) ou d'oganisation des fichiers
source et des headers (par contre, ça ils en parle).
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants est
capable d'avoir en tête l'organisation d'un code d'environ 5000 lignes,
développé sur 2 mois, sans avoir réellement besoin de conception,
méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de ne
pas écrire de variables globales ????
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
En effet.
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
Le C _d'abord_, la programmation structurée _ensuite_, l'algorithmique
certainement pas (c'est une des erreurs du K&R), ce n'est pas l'objet d'un
cours de C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.
Ça a tout à fait sa place dans un livre.
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Non, ce n'est pas pareil, si je te suis on serait en train de dire que
presque tous les artisans ne font pas le trvail dans les règles de l'art.
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Pas du tout, il certainement possible d'expliquer l'idée avec quelques
exemples bien choisis.
Et à ce compte-là, un cours de C ne parle pas de compilation séparée
(d'ailleurs K&R est très léger là-dessus) ou d'oganisation des fichiers
source et des headers (par contre, ça ils en parle).
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants est
capable d'avoir en tête l'organisation d'un code d'environ 5000 lignes,
développé sur 2 mois, sans avoir réellement besoin de conception,
méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de ne
pas écrire de variables globales ????
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
Et oui... Ceci dit, les variables globales ne sont pas un pb de "C",
En effet.mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
Le C _d'abord_, la programmation structurée _ensuite_, l'algorithmique
certainement pas (c'est une des erreurs du K&R), ce n'est pas l'objet d'un
cours de C.
C'est à peu prêt jouable quand un cours s'inscrit dans un cursus,
bien plus difficile pour un livre.
Ça a tout à fait sa place dans un livre.
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Non, ce n'est pas pareil, si je te suis on serait en train de dire que
presque tous les artisans ne font pas le trvail dans les règles de l'art.
Comme quoi, un prof en vrai, c'est pas plus mal ;-)
Naturellement mais la difficulté c'est de faire presque aussi bien sans.
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Pas du tout, il certainement possible d'expliquer l'idée avec quelques
exemples bien choisis.
Et à ce compte-là, un cours de C ne parle pas de
compilation séparée (d'ailleurs K&R est très léger là-dessus) ou
d'oganisation des fichiers source et des headers (par contre, ça ils en
parle).
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de ne
pas écrire de variables globales ????
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
Le C _d'abord_, la programmation structurée _ensuite_, l'algorithmique
certainement pas (c'est une des erreurs du K&R), ce n'est pas l'objet
d'un cours de C.
Ben oui. "errno" par exemple.
Non, je ne pensais pas à ça, je pensais à certains exemples illustratifs
dans la norme (partie "language"). Même Kernighan & Pike qui dissuadent
d'en utiliser ("Avoid global variables" page 104) en utilisent dans
leurs exemples, c'est dire si le mal est profond ...
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Non, ce n'est pas pareil, si je te suis on serait en train de dire que
presque tous les artisans ne font pas le trvail dans les règles de l'art.
Comme quoi, un prof en vrai, c'est pas plus mal ;-)
Naturellement mais la difficulté c'est de faire presque aussi bien sans.
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Pas du tout, il certainement possible d'expliquer l'idée avec quelques
exemples bien choisis.
Et à ce compte-là, un cours de C ne parle pas de
compilation séparée (d'ailleurs K&R est très léger là-dessus) ou
d'oganisation des fichiers source et des headers (par contre, ça ils en
parle).
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de ne
pas écrire de variables globales ????
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
Le C _d'abord_, la programmation structurée _ensuite_, l'algorithmique
certainement pas (c'est une des erreurs du K&R), ce n'est pas l'objet
d'un cours de C.
Ben oui. "errno" par exemple.
Non, je ne pensais pas à ça, je pensais à certains exemples illustratifs
dans la norme (partie "language"). Même Kernighan & Pike qui dissuadent
d'en utiliser ("Avoid global variables" page 104) en utilisent dans
leurs exemples, c'est dire si le mal est profond ...
Pourquoi voudrais-ty que les informaticiens soient la seule
profession ou tous feraient correctement leur travail dans les
règles de l'art ? Tu n'a jamais vu un maçon cacher la misère
sous un peu de crépis ?
Non, ce n'est pas pareil, si je te suis on serait en train de dire que
presque tous les artisans ne font pas le trvail dans les règles de l'art.
Comme quoi, un prof en vrai, c'est pas plus mal ;-)
Naturellement mais la difficulté c'est de faire presque aussi bien sans.
Un problème de fond du génie logiciel, c'est qu'il est là
pour permettre de passer à l'échelle ("programming in the large"),
et qu'on ne peut pas, dans le cadre d'un enseignement, que ce soit
dans une formation ou dans un bouquin, dépasser le "programming
in the small".
Pas du tout, il certainement possible d'expliquer l'idée avec quelques
exemples bien choisis.
Et à ce compte-là, un cours de C ne parle pas de
compilation séparée (d'ailleurs K&R est très léger là-dessus) ou
d'oganisation des fichiers source et des headers (par contre, ça ils en
parle).
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
5000 lignes de code ne permettent pas de comprendre la pertinence de ne
pas écrire de variables globales ????
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
mais commun à tous les langages de prog que je connais. Et la question
d'un cours de C est toujours de savoir s'il enseigne l'algorithmique,
la "bonne programmation" structurée ou le C.
Le C _d'abord_, la programmation structurée _ensuite_, l'algorithmique
certainement pas (c'est une des erreurs du K&R), ce n'est pas l'objet
d'un cours de C.
Ben oui. "errno" par exemple.
Non, je ne pensais pas à ça, je pensais à certains exemples illustratifs
dans la norme (partie "language"). Même Kernighan & Pike qui dissuadent
d'en utiliser ("Avoid global variables" page 104) en utilisent dans
leurs exemples, c'est dire si le mal est profond ...
devoir expliquer ce
qu'est un singleton.
Et c'est quoi (j'en suis resté à l'ensemble de cardinal un) en d'autres
termes que "instance unique qui ne doit etre dedoublé" (un court exemple
sera aussi parlant que 10 lignes d'explication) ?
devoir expliquer ce
qu'est un singleton.
Et c'est quoi (j'en suis resté à l'ensemble de cardinal un) en d'autres
termes que "instance unique qui ne doit etre dedoublé" (un court exemple
sera aussi parlant que 10 lignes d'explication) ?
devoir expliquer ce
qu'est un singleton.
Et c'est quoi (j'en suis resté à l'ensemble de cardinal un) en d'autres
termes que "instance unique qui ne doit etre dedoublé" (un court exemple
sera aussi parlant que 10 lignes d'explication) ?
On 2008-03-12, candide wrote:Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
Pärce qu'ensuite, une fois ces deux points énoncés, il faut les
justifier. Et comme je disais, la justifications se trouve dans le
passage à l'échelle, qui ne se justifie que par expérience, personnelle
ou recueillie.
On 2008-03-12, candide <c-candide@wanadoo.fr> wrote:
Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
Pärce qu'ensuite, une fois ces deux points énoncés, il faut les
justifier. Et comme je disais, la justifications se trouve dans le
passage à l'échelle, qui ne se justifie que par expérience, personnelle
ou recueillie.
On 2008-03-12, candide wrote:Ben, K&R dit tout:
- data connections are not all obvious
- the program is hard to modify
Apparemment ce n'est pas très dissuasif (car pas très convaincant).
Pärce qu'ensuite, une fois ces deux points énoncés, il faut les
justifier. Et comme je disais, la justifications se trouve dans le
passage à l'échelle, qui ne se justifie que par expérience, personnelle
ou recueillie.
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Pourquoi ne pas les plonger sur la maintenance d'un petit bout de code
_existant_ (disons, un module de 2000-3000 lignes) inséré dans un projet de
plusieurs dizaines de milliers ?
Avec le phénomène OpenSource, ce ne devrait pas être mission impossible de
trouver cela (qui a dit, un driver pour Linux^W MachinBSD ?)
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.
Euh, en informatique (en France), maintenir une équipe de programmeurs sur
la maintenance d'une application pendant 5 ans, ce n'est pas un objectif
pour les informaticiens, c'est un objectif pour les responsables des
ressources humaines ! :-)
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Pourquoi ne pas les plonger sur la maintenance d'un petit bout de code
_existant_ (disons, un module de 2000-3000 lignes) inséré dans un projet de
plusieurs dizaines de milliers ?
Avec le phénomène OpenSource, ce ne devrait pas être mission impossible de
trouver cela (qui a dit, un driver pour Linux^W MachinBSD ?)
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.
Euh, en informatique (en France), maintenir une équipe de programmeurs sur
la maintenance d'une application pendant 5 ans, ce n'est pas un objectif
pour les informaticiens, c'est un objectif pour les responsables des
ressources humaines ! :-)
Mon expérience d'enseignement est qu'un groupe de 3-4 étudiants
est capable d'avoir en tête l'organisation d'un code d'environ
5000 lignes, développé sur 2 mois, sans avoir réellement besoin
de conception, méthode, etc.
Pourquoi ne pas les plonger sur la maintenance d'un petit bout de code
_existant_ (disons, un module de 2000-3000 lignes) inséré dans un projet de
plusieurs dizaines de milliers ?
Avec le phénomène OpenSource, ce ne devrait pas être mission impossible de
trouver cela (qui a dit, un driver pour Linux^W MachinBSD ?)
Mais, l'objectif des règles de bonne programmation, c'est
d'être capable d'avoir une équipe qui va écrire 50.000 lignes,
et les maintenir pendant disons 5 ans.
Euh, en informatique (en France), maintenir une équipe de programmeurs sur
la maintenance d'une application pendant 5 ans, ce n'est pas un objectif
pour les informaticiens, c'est un objectif pour les responsables des
ressources humaines ! :-)
