Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Loi de Murphy
Loi de Brooks
Loi de Hofstadter
Loi de Conway
Loi de Postel ou principe de robustesse
Loi de Pareto
Principe de Peter
Principe de Kerckhoffs
Loi de Linus
Loi de Moore
Loi de Wirth
Principe du 90-90
Principe d'optimisation de Knuth
Loi de Norvig
Autres (à préciser)
Pas d'avis
90-90
Une petite coquille s'est glissée dans le principe des 90-90 :
Le développement des premiers 90 % du code représentent 10 % du temps de développement. Les 10 % restants prennent 90 % du temps de développement.
+1 pour le principe d'optimisation de Knuth
Non. C'est voulu cf la phrase suivante:Envoyé par said026
Cela fait donc 180 % du temps de développement
J'ai un prof d'algo qui se basait énormément sur les travaix de knuth, et qui résumait sa pensée ainsi :
1. Make it work
2. Make it well
3. Make it fast.
En clair, l'objectif premier d'un programme est de fonctionner, sinon il n'a pas raison d'être.
Ensuite, il faut qu'il soit maintenable, sinon il n'a pas de raison de subsister
Enfin il peut être rapide. Mais s'il ne fonctionne pas, ou alors qu'il est déjà peu maintenable, aucune chance d'aboutir à quelque chose de potable.
ça tombe sous le sens. En pratique, avec ma petite expérience, on me laisse rarement le temps de bien finir l'étape "Make it well"...
Pas mal de lois que je ne connaissais pas mais dont je me rend compte qu'elles s'appliquent à mes projets et à mon entreprise.
C'est très intéressant comme Trolldi.
Dans l'embarqué c'est plutôt :
1. Make it work
2. Make it fast
3. Make it well (qu'on a jamais le temps)
Voir j'ai même eu des chefs qui disaient que la vitesse d'exécution était plus important que le fait que cela fonctionne...
J'aimerai pas être le client.
Sinon, il y en a quelques-une que j'adore et qui ne sont pas citées :
Loi de wirth
La loi de Wirth est trop vraie.
Un C64 mettait moins de 2 secondes entre l'appui sur le bouton power et la disponibilité du système près à recevoir des commandes au clavier. Aucune machine actuelle ne fait ça, quel que soit le noyau ou le shell.
Mon 486 avec une contrôlleur VLB + mémoire cache mettait moins de temps à démarrer Win3.1 qu'un bousin d'aujourd'hui à charger windows 10. Attention, par charger, je veux dire sans tâche de fond qui continue à mouliner le SSD ou le disque dur après l'affichage du shell.
Toutes les autres lois sont valides, à l'exception de la loi de Moore qui se heurte à la taille minimale (quantique) du transistor.
le plus souvent - trop souvent - , ce que je constate c'est l'application de la loi de la gravitation :
tout élément incompétent parachuté dans un projet finit par s'écraser .
Mes chefs ont trouvé la parade depuis longtemps : il demandent au métier la date de dead-line. Ensuite, il faut deux mois de tests fonctionnels ? ils enlèvent deux mois. Il faut un mois de tests unitaires ? ils enlèvent un mois. Deux mois de débuggage et de mise au point ? Ils enlèvent encore deux mois. Ce qui reste, c'est pour le développement. Le développeur, c'est moi.
C'est sur que parfois ca peut très bien se passer. Le problème pour moi c'est qu'il y a une certaine pression social, on entend trop souvent "quoi à 35ans tu est encore dev, tu devrai être chef d'équipe au minium ?". Pour moi il n'y a pas de honte a dire qu'on est bien là ou on est.Au lieu de changer de poste on devrait juste augmenter les salaires...
Mais après je pense que c'est parfois jouable qu'un développeur devienne chef de projet (selon ce qu'on entend par "chef de projet").
Selon la méthode, le chef de projet est un des développeurs de l'équipe qui a des responsabilités en plus.
Ah ca c'est un autre problème aussi très vrai, et pas que dans l'informatique ! De mon expérience c'est jamais très bon d'avoir un chef qui commande un truc dont il ne comprend pas le fonctionnement.Parfois il y a des chefs de projets qui n'ont jamais été développeur, c'est un peu dommage.
Le pire ça restera les commerciaux, ils n'y connaissent rien et font des promesses au client...
Qu'est-ce qu'il y connait aux femmes Rick Hunter ?
Qu'est-ce qu'il y connait au métier le commercial ?
Celle qui est la plus déprimante au travail, et qui n'est pas dans le sondage... c'est la loi du plus fort !
ce n'est pas vraiment une loi mais plutôt un paradoxe mis en évidence par l'économiste américain Robert SolowVotre loi préférée a-t-elle été omise ? Si oui, de quelle loi s'agit-il ? Que dit-elle et comment vous impacte-elle ?
On peut voir les ordinateurs partout sauf dans les statistiques de productivité
Y'a pas une loi qui dit que les besoins évoluent toujours mais on ne sait pas comment / dans quel sens à l'avance ? Et qu'au fur et à mesure des livrables les idées se posent plus clairement, les stupidités se voient, donc s’interprètent et cadrent mieux le projet et que c'est pas grave de jeter des trucs à la poubelle tant qu'on en retient l'intellectuel ?
Ça ferait du bien de pouvoir prouver qu'il est totalement inutile de passer des mois et des mois à faire des réunions pour pondre un cahier des charges de 600 pages sensé exprimer les besoins de production des 3 prochaines années pour assurer le business des 15 prochaines années.
Des boucliers se lèveraient, et c'est normal. Je pense à ces rédacteurs, relecteurs, valideurs. Tous ces chefs toujours plus intelligents que leur voisin ça risque de leur piquer les fesses le jour où on pourra prouver qu'ils ne servent à rien voire passent leur temps à parasiter.
Pour la Loi de Wirth je l'aurai pas formulée comme ca. C'est plutot un ensemble de truc qui débouchent là dessus.
+Vieux soft codé y'a des lustres sur une techno dépassée mais qu'on ne veut jamais mettre à jour parce que pas le temps/envie/argent.
+ les délais de plus en plus court de dev
+ on s'en fout d'optimiser, avec les pc actuels y'a plus a s'embéter avec les delete ou la gestion de la mémoire. La mémoire vive est infinie (entendue deja de la bouche d'un cp)
+ pleins d'autres joyeusetés
Après des lois on peut en rajouter plein.
Plus y'a de gens sur un projet, et moins il avancera, parce que c'est un probleme de comm comme evoqué dans une des lois citées, mais parce que forcément les gens vont intervenir sur les mêmes sources, et qu'on va perdre un temps de dingue parce que certains auront codés la même fonction mais differrement, ou que le gestionnaire de source aura mergé comme un porc .....
Mais ma préférée ca reste : "on ne change pas un code qui marche". Si ca marche il ne faut surtout pas chercher de faire mieux, c'est toujours une perte de temps, une cause de bug, et au final si on y arrive, le gain est pas toujours evident
Il peut y avoir plusieurs bonnes raisons de modifier un code qui marche.
Par exemple, quand on doit développer une nouvelle fonctionnalité qui ressemble à une fonctionnalité déjà existante, mais que le code de la fonctionnalité déjà existante n'est pas réutilisable, alors modifier le code de la fonctionnalité existante puis le réutiliser pour la nouvelle fonctionnalité est souvent ce qu'il faut faire.
Ou alors, quand on se demande comment marche une fonctionnalité existante, quand on plonge dans le code qui sert de doc et quand on tombe sur un code difficile à lire (fonctions de plusieurs centaines de lignes, noms de variables et de fonctions qui ne correspondent pas à ce qu'elles représentent, etc.), alors améliorer le code existant permettra aux prochains lecteurs de perdre moins de temps à déchiffrer le code.
Le fait que changer un code existant soit une si grande source de bogues est surtout un signe qu'il n'y a pas assez de tests unitaires.
plus c est simple plus c est dur
en gros des fois je m attelle à une réalisation que je juge très difficile et oh miracle ca marche du 1er coup
inversement un truc que je juge hyper simple faisable en 10 minutes et oh desespoir j y passe une semaine
Cette règle appliquée aux traitements, oui, appliquée aux données, non : l'optimisation des données doit commencer dès la phase de conception c'est à dire le MCD !
Quoi que ... prématuré signifie "trop top", du coup, la réponse est contenue dans la question
Au grand dam de ces dames !
[...] une des raisons qui font que [...] : ce sont les raisons qui font
Répondre avec citation
Partager