L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
23
avr.
2003
Communauté
L'analyse conduit-elle au code ou le code conduit-il à l'analyse ? La question pourrait sembler stupide. Le logiciel libre remet pourtant en question quelques pratiques bien établies en matière de développement informatique.

La pratique d'un développement itératif a remis en question l'importance de l'analyse. La disponibilité croissante de composants logiciels libres de qualité va également dans ce sens. Cette évolution annonce un rééquilibrage de l'importance relative du code et de l'analyse (ainsi qu'une redéfinition de cette dernière). Et révèle le rôle majeur d'un architecte logiciel.

Aller plus loin

  • # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

    Posté par  (site web personnel) . Évalué à 10.

    Comme d'habitude, la seule vérité acceptable est issue de définitions circulaires. Et puis de toute manière, c'est comme ca que nous réagissons non? Il n'y a pas beaucoup de systèmes parfaits qui ne redemande pas une deuxième analyse en passant l'épreuve du temps ... (à part peut être Latex, qui semble avoir été designé comme ca :)
    Du coup, je me dis oui, l'analyse conduit au code et oui, le code conduit à l'analyse, quoi de mal a tout cela? Interressant néanmoins.

    • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

      Posté par  (site web personnel) . Évalué à 8.

      Entierement d'accord :

      Analyser Jusqu'au bout de ses propres limites (experience, theorie)
      Coder (=> Augmente experience et theorie)
      Analyser Jusqu'au bout de ses propres limites (experience, theorie)
      ...

      Donc deux aspects importants sont oublies dans l'article :

      - la qualite du codeur/analyste (experience / fond theorique)

      - L'aspect innovant d'un code ( par rapport au theorie actuelle)

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 9.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

        Posté par  (site web personnel) . Évalué à 2.

        Ouaip, n'empêche qu'une bonne phase d'analyse préliminaire doit avant tout permettre l'évolutivité, l'ouverture du produit ... c'est en tout cas, ce kon dit à l'école. Dans la vraie vie, si l'analyse est pas trop bonne au départ, ca permet de la refaire plus tard = $muchos.
        Ya toujours ce bon vieux décalage entre ce qui est bon pour l'utilisateur et ce qui rapporte de l'argent (malhonnêtement). Je crois penser que nous sommes tous ici conscients de ca.
        Enfin, une bonne analyse, c'est bien.

  • # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

    Posté par  (site web personnel) . Évalué à 9.

    J'avais lu qq part une réflexion, où l'on se demandait se qu'il valait le mieux un expert super pointu ou une poigné de développeur qui "essayent".

    La réponse de l'auteur était l'expert *si le problème est clairement identifié* or il le ne serait jamais en informatique, car il y aurais trop de paramètre en jeux.

    "La première sécurité est la liberté"

  • # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

    Posté par  . Évalué à 2.

    Dans le libre, il y a aussi un paramètre à ne pas oublier : le développement ce fait par des passionnés. Et à mon avis ca compte. (cf le journal http://linuxfr.org/~Xate/2099.html(...) )

    Dans l'article :
    L'entreprise économise en temps de développement et peut se consacrer à ce qu'elle fait bien. Le logiciel libre gagne en crédibilité du fait de son utilisation par des professionnels.
    Ca me donne l'impression que le libre ne peut fournir que des librairies.

    [maVie]
    Pour moi, c'est souvent, un peu de conception (enfin quelques schèmas en MaNotationAMoi, un algo posé à plat si besoin), du code, puis la post-conception s'il y a besoin de doc.
    [/maVie]

    • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

      Posté par  (site web personnel) . Évalué à 6.

      > Ca me donne l'impression que le libre ne peut fournir que des librairies. Certes non. De nombreux projets d'applications pour utilisateurs finaux prouvent d'ailleurs le contraire : Apache, Open Office, Gimp, etc. Dans l'exemple donné avec Apache, Apache est bien utilisé comme un produit à part entière. La réflexion proposée ici partait d'une question : compte tenu de tout le code libre disponible, comment optimaliser le développement de produits innovants ? Comment consacrer l'énergie de l'entreprise à ce dans quoi elle est forte, sans réinventer la route. Cette démarche-là implique la réutilisation et l'intégration de composants (librairies ou autre) comme dans l'exemple de Claroline. Clairement, il s'agit donc d'une stratégie de produit, parmi d'autres stratégies possibles. Par ailleurs, en complément à l'article, j'ajouterai que le gain d'image de marque peut être mutuel (gagnant-gagnant). Si le libre peut être crédibilisé par un usage professionnel, un produit commercial peut être crédibilisé par l'usage d'un produit libre. Un produit basé sur Apache ou Mozilla fera plus sérieux qu'un même produit basé sur un système inconnu. Le libre gagnerait certainement à développer des stratégies de co-promotion, car il s'agit typiquement d'une stratégie gagnant-gagnant.

      • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

        Posté par  (site web personnel) . Évalué à 1.

        Récupérer du code libre, envoyer des patchs, payer des fonctionnalités, ok mais partir sur un développement commun, je n'ai jamais encore vu. (2 boites séparées qui n'ont aucun rapport juridique décide de produire un produit libre et leur équipe de dev bossent ensemble) Cela ne peut marcher que si une des 2 boites prends le leadership des choix techno sinon cela va vite être le bordel. Quoique...

        "La première sécurité est la liberté"

        • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

          Posté par  . Évalué à 3.

          Pas une boite, mais une personne. Il devient le chef de projet. Et il prend en compte les desiderata des 2 boites comme s'il faisait partie des 2 boites.

          Comme ca, ca peut marcher tres bien. Si y'a leadership, d'une boite sur l'autre, alors l'autre ne peut que devenir cliente et on sort du cadre d'un co-developpement.

          Ensuite, si le projet devient gros, y'a soit creation d'une boite, soit creation d'un consortium. Et hop

          Yves

        • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

          Posté par  (site web personnel) . Évalué à 3.

          Lorsque je parlais de co-promotion, je ne parlais pas de co-développement (je suppose que c'est à cela que tu faisais allusion quand tu parlais de partir sur un développement commun, je n'ai jamais encore vu). La co-promotion, c'est en quelque sorte de la publicité où les deux marques sont évoquées.

          Par exemple, l'entreprise B utilise le logiciel libre A. B fait une campagne de promotion, où il explique qu'il utilise A. Et A explique sur son site communautaire qu'il est utilisé par B. D'où :

          -> A gagne en crédibilité du fait de son usage professionnel (à condition que l'entreprise soit crédible évidemment et "librement correct" :).
          -> B gagne en crédibilité du fait de son usage d'une solution libre reconnue.

          Cette façon de procéder implique évidemment que les grosses communautés contrôlent leurs principales marques : par exemple, la marque Debian est déposée et ne peut donc pas être utilisée par n'importe qui.

          Quand à l'aspect co-développement / développement commun entre une communauté et une entreprise, il y a de nombreux exemples qui fonctionnent bien : Roxen, Zope, Linux Kernel, etc. Deux points clefs me semblent une bonne communication entre les différents protagonistes (fixer dès le départ les objectifs, les moyens d'y arriver, etc) et la fixation des interfaces (pour perturber au minimum les autres développements).

          Ca se rapproche en fait assez fort de la gestion de projet dans l'automobile, où la voiture est progressivement décomposée en modules (plate-formes, embrayages, moteurs, etc) en vue de permettre le co-développement et le partage entre différents projets (la Megane II et la future Almera partageant la même plate-forme, la Micra et la Clio II partageant les mêmes diesels, etc).

          Cela pose néanmoins une question : comment ne pas tuer l'innovation architecturale, dès lors que l'on fige les interfaces ?

  • # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

    Posté par  . Évalué à 10.

    Si l'on remplace le débat analyse/codage par celui de technique/art alors un éclairage nouveau ràmène au grand jour les faits souvent énoncés suivants :
    1/ il y a des codeurs doués.
    2/ certains programmes (au sens de l'algorithme ET des spécificités du langage mis en oeuvre) sont 'beaux'.

    On se rend compte dès lors, et ce au grand désarroi de nos chers profs ou des technocrates adeptes de l'ISO9001 que le fait programmatique relève de l'art et que l'art ne se normalise pas.

    Qui ne connait pas un de ses codeurs fous qui construisent l'analyse 'au vol' dès lors qu'il entamment leur première ligne de code ? Certains objecterons : 'oui ... mais tout dépend de la complexité' et le hacker (au sens premier du teme) répliquera fort à propos : 'je ne cherche pas à tout résoudre d'un coup, je réduis et j'incrémente.'.

    Bref le LL n'est pas le révélateur de la puissance de la force collective brute, mais bel et bien celui de la jubilation de talents individuels se reconnaissant comme tels.

    • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

      Posté par  (site web personnel) . Évalué à 3.

      > Bref le LL n'est pas le révélateur de la puissance de la force collective brute, mais bel et bien celui de la jubilation de talents individuels se reconnaissant comme tels.

      fouillaillaille, c'est beau ça...

      T'as oublié l'émulation ? (aka concurrence saine ?)

    • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

      Posté par  . Évalué à 3.

      ISO9001
      Pour rappel, ISO9001 est une norme de qualité, introduite en France, ne concernant __que__ le cadre du projet informatique, la gestion du risque, la qualité <=> traçabilité des procédures... rien d'autre et surtout pas la qualité du code. Cette norme fournit encore moins de garde-fous quant aux spécifications techniques. Dans ce but, il faut plutôt s'intéresser à des normes américaines ou canadiennes...

      Comme quoi nos chers profs ou des technocrates adeptes de l'ISO9001 ne prétendent en rien normaliser cet art (qui n'est en substance que __ta__ dénomination d'une activité professionnelle le plus souvent bien laborieuse pour une majorité de "codeurs")...

      • [^] # Re: L'oeuf ou la poule ? L'analyse prime-t-elle toujours sur le code ?

        Posté par  . Évalué à 2.

        L'iso9001 était citée de manière 'générique' et comprends bien un volet qualité concernant la phase d'étude / recherche & développement . La dernière fois où j'ai entendu parler de normalisation plus spécifique au dev informatique, c'était un constat d'échec des différent protagonistes... ce qui tend à confirmer mes propos.

        >> qui n'est en substance que __ta__ dénomination d'une activité professionnelle le plus souvent bien laborieuse pour une majorité de "codeurs"

        C'est bien ce que je dis, la programmation est bien un art réservé à des artistes, les autres ma foi ne sont (comme le prévoyait Nietzche ) que des 'fonctionnaires de la science' sans talent mais disciplinés.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.