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
Discussion :
Ce qui fait la différence entre un simple projet et un bon projet
Bonjour,
ne sachant trop ou poster, j'ai finalement opté pour la conception...ma question est vraiment d'ordre général.
Quelles sont les caractéristiques qui font la différence entr eun simple projet et un bon projet, je pense par exemple aux fameux:
- Réutilisabilité
- Portabilité
- Maintenabilité
- ...
Si des personnes ayant plus d'expérience professionnelle que moi (il doit il y en avoir un bon milliard) pouvaient me donner leur avis sur la question, c'est volontiers!
Merci d'avance
Ca ce sont des caracteristiques possibles du code.Envoyé par TheCaribouX
J'avoue ne pas comprendre la notion de simple vs. bon projet. En tout cas, un projet reussi doit repondre aux besoins du client et etre termine selon le planning et le budget prevus.
Mmh, disons, comme je le vois, un simple projet répondra effectivement aux besoins du clients et au budget fixé, mais un bon projet vois un peu plus loin et part du principe que le code sera remanié et certainement par quelqu'un d'autre et doit donc avoir certaines caractéristiques de réutilisabilité par exemple.
Mon but est juste de demander si, au travers des différents projets rencontrés, certaines personnes sauraient énumérer d'autres caractéristiques qui font que lorsqu'on étudie le code, on sait qu'on a affaire à une personne qui a de l'expérience et pas à un mec qui a codé en trois jours un projet qui ne sera compréhensible que par lui-même
Ceci est déjà un bon projet, car peu de projets "réussissent" c'est à dire couvrent les besoins dans les temps et le budget impartit, tout en satisfaisant l'utilisateur (qui n'est pas forcément le client)...un simple projet répondra effectivement aux besoins du clients et au budget fixé
Tu ne vois pas d'autres caractéristiques qui seraient un + hed?
Si, le ROI
Sinon les critères de réutilisabilité, maintenabilité, sont plutot difficiles à juger, notamment si la situation "je dois réutiliser un morceau" ou "je dois faire évoluer" n'apparait jamais...
Attention ! Je ne dis pas que ces critères sont inutiles, loin de là !
ROI?
j'ai beau chercher sur, la
ou encore
(
), soit je trouve des post mentionnant ce fameux ROI sans en dire plus, soit des articles concernant toute la monarchie française
, un petit indice pour un débutant qui ne sait pas de quoi il s'agit?
Return On Investment : le retour sur l'investissement correspond au délai à partir duquel le projet sera "remboursé" et deviendra donc rentable.
Par exemple, un projet tout nul, développé par un stagiaire non formé coutera très peu. Même si le gain du projet est très faible (1€ par mois on va dire) , le ROI peut être pas trop mauvais.
Un projet extrèmement couteux (équipe de 50 experts) qui fait gagner 500€ par mois aura un très mauvais ROI (ûn cas aussi extrème doit être détecté très tôt !)
C'est donc le rapport entre cout et gain par mois. Cela donne un délai de rentabilité.
Merci!
je dois m'avouer surpsi de voir que la qualité du code ait si peu d'importance, en soit un code moche impliquera une plus grosse équipe pour reprendre un code et donc un ROI plus faible lors du remaniement du code.
Est ce que donc, dans la pratique, un code n'est que rarement remanié? A ce moment la, autant n'embaucher que des stagiaires... (tiens on parle de moi?
non non non , je n'ai jamais voulu dire ca !
Pour les grands chefs, ce qui compte n'est pas le code.la qualité du code ait si peu d'importance
Pour les chefs "plus proche des developpeurs", il faut un code de qualité aussi rapidement qu'un code sale
Non, pas forcément, puisque la TMA est facturée. Cela ne rentre pas dans le calcul du ROI.et donc un ROI plus faible lors du remaniement du code.
non, on remanie du code. J'ai juste dit que a priori les critères de maintenabilité sont difficile à jauger, puisque par définition il faut envisager des modifications qui n'ont pas encore été demandées. Ce n'est qu'une fois qu'on a maintenu un code que l'on peut dire : "oui, ce code est maintenable." Idem pour "réutilisable".un code n'est que rarement remanié?
desolé
La seule méthode pour développer un bon projet est donc d'avoir des années d'expérience? Moi, stagiaire zelé, qui pensais que je pourrais tenter de directement prendre de bonnes habitudes
C'est possible de prendre de bonnes habitudes, mais il faut beaucoup de rigueur, éviter de dire : "oh, ca c'est moche, mais tant pis, pas le temps je corrigerai plus tard"...
Les commentaires, qui ne doivent pas paraphraser le code...
Donc je peux pas faire beaucoup plus que:
- Bien commenter
- Etre strict dans le codage
- utiliser des design patterns
- Documenter avec des shémas UML entre autre
?
ou y'a t'il d'autres points importants pour "bien débuter dans le monde professionel"? (qu'on ne me dise pas programmer rapidement
Sans parler business mais en parlant cette fois technique, voici quelques idees en vrac.ou y'a t'il d'autres points importants pour "bien débuter dans le monde professionel"? (qu'on ne me dise pas programmer rapidement
1) Un point important est de prendre conscience que chaque programmeur introduit des bugs provenant soit des ses propres erreurs de logique, soit de la non gestion des cas inattendus, etc. Pour y remedier, il faut programmer de maniere defensive pour gerer les cas inattendus et ses propres erreurs de logique.
2) Il faut aussi prendre conscience qu'un logiciel est ecrit une fois par la premiere equipe de programmeurs. Mais une fois en phase de maintenance, le logiciel sera lu des milliers de fois par des personnes chargees de corriger les bugs. Donc, il faut que le code soit lisible. N'importe qui doit comprendre l'intention de depart du programmeur originel. Non pas comment il le fait, mais pourquoi il le fait.
3) Il faut essayer d'appliquer les bonnes pratiques du metier ou d'une technologie, d'un langage, etc. Et pour ca, il faut se documenter, toujours avoir envie d'apprendre. Comme tu le fais avec ce post ;-)
4) Dans la mesure du possible, il faut utiliser les bibliotheques deja disponibles avec le langage au lieu de reinventer la roue. (ex. BOOST pour C++)
5) Pour finir, je te conseille la lecture des deux ouvrages suivants:
* "Métier développeur : Kit de survie" de Jean-Christophe Arnulfo
* "Tout sur le code : Pour concevoir du logiciel de qualité" de Steve McConnell
Merci pour les conseils (et les réfèrences!)
je vais tâcher de les suivre dans la mesure de mes "moyens"
je ne sais pas si ce post mérite d'avoir été déplacé dans cette partie du forum (réservé pour les pros, pas les apprentis-pros) mais si qui que ce soit a d'autres conseils, je suis preneur!
Pour ce qui est de "programmer de manière défensive" j'avoue ne pas voir exactement comment le mettre en oeuvre, à part des exemples "gros comme un camion" qui reviendrait à vérifier le type de chaque variable à chaque utilisation... Les vérifications de la logique d'un code ne sont-elles pas faites par les tests unitaires? (je n'en ai entendu parler qu'en théorie pour l'instant).
Et, tant que j'y suis, le framework .NET peut il être considéré comme un moyen de ne pas réinventer la roue? (je programme en c#, je dois donc etre un "monsieur Jourdain" de l'informatique qui fais du .NET sans le savoir
merci encore!
exemple de programmation défensive. Une application(une transaction, par exemple) génere des flux de données. Ton application les récupère pour les traiter. Eh bien si tu pars du principe que tout ce qui sort de l'application en amont est bon, tu vas au devant de graves déconvenues.
==>Toujours vérifier que les données au format numérique sont numériques
==>Toujours éliminer les caractères spéciaux qui font planter l'application
==>Toujours vérifier la cohérence des données(un montant en Yen ou en Won qui a des chiffres après la virgule, ça pue)
==>Toujours vérifier le code retour des modules appelés(enfin, ça, ça dépend de l'architecture choisie; mais dès que tu fais appel à ce qui n'est pas à toi, alors vérifie).
etc.....
Les test unitaires ne testent que des bouts de code. Il y a ensuite les étapes d'integration et de recette(ou bien assemblage et homologation, y'a plein de noms différents), ou progressivement on s'aperçoit que les bouts de code qui marchent très bien tout seuls font planter le reste de l'univers(j'exagère à peine), et on corrige jusqu'à ce que l'on ne vois plus de bugs.....et évidemment, on en a laissé passer quand même.
Il m'est arrivé de tester, sur un écran de clôture de carte bleue, le bon fonctionnement de tous les motifs de clôture présents sur la liste déroulante. La logique était donc bonne après test unitaires. Il ne m'était pas venu à l'idée que des utilisateurs pouvaient forcer la liste déroulante pour y imposer un autre code, et passer outre le message d'insultes leur demandant de changer de code. Moralité : 4 plantages de la machine de production en une matinée.....et 10 jours pour comprendre après la remise en place de l'ancienne version. Et les félicitations du jury.....
Les utilisateurs font n'importe quoi(toujours). Les autres programmeurs font n'importe quoi(pas toujours, mais assume que si, la confiance te sera fatale, dans ce métier). Donc prémunis toi contre toute forme de stupidité. Si quelque chose ne doit pas arriver, alors programme défensivement pour que ça n'arrive jamais.
Merci pour les explications, c'est vraiment plus clair!
et ca:
ca résume très bien
C'est l'application à l'art du développement du principe (ou loi) de Murphy, qu'on peut énoncer de façon lapidaire par : "s'il y a une chance pour que ça puisse m...r, ça m...a".
A la liste assez complète de el_slapper, je n'ajouterai qu'une chose : protéger l'intégrité des données. Quand une application gère d'une manière ou d'une autre des données persistantes (par ex. enregistrées dans un SGBDR) qui ne peuvent pas être reproduites autrement qu'en étant ressaisies, ou alors coûteuses à synthétiser, ses développeurs doivent toujours mettre en place des mécanismes visant à éviter la corruption des données même dans le pire des scénarios. Ca passe par des mécanismes de tampons, de transactions avec rollback possible, etc.
Par ordre croissant de gravité, on a donc :
- L'application boguée
- L'application en DOS (Denial Of Service), ne fonctionnant carrément pas
- L'application boguée (ou pas) qui corrompt les données et oblige - ô funeste sort ! - à en faire une restauration
FAQ XML
------------
« Le moyen le plus sûr de cacher aux autres les limites de son savoir est de ne jamais les dépasser »
Giacomo Leopardi
programmation defensive
En fait, plus c'est gros comme camion, plus c'est necessaire de le verifier vu que tu n'attends pas a ce que la condition a verifiee soit fausse. Ca peut etre un type de variable ou autre chose...
Prenons des exemples.
- Avant d'ouvrir un fichier, tu verifies que le fichier existe et que tu as les droits en ecriture.
- Si tu lis un fichier XML, tu peux verifier que le fichier est conforme au DTD. Si le fichier n'est pas conforme, il faut prevoir une gestion de l'erreur.
- Imagines que tu declares une variable "distance". En lisant on ne sait pas quelle est l'unite (km, Hm, cm, mm, etc.). Donc, tu peux renommer la variable en "distanceKm". L'unite est maintenant contenue dans le nom. Ca peux t'eviter un bug!
- Avant de calculer la racine carre d'un nombre, tu verifies que ce nombre est positif. Ou avant de calculer l'arccosinus, tu verifies que les valeurs sont comprises entre -1 et 1.
- Si tu ecris une fonction avec plusieurs arguments. Il faut s'assurer que les valeurs fournies en entree sont correctes. Si l'argument est un pourcentage, tu verifies que la valeur est bien entre 0 et 100. Si c'est un code postal, tu peux verifier que le code postal est valide. Plus generalement, on parle de programmation par contrat. En entrant dans une fonction, tu verifies les pre-conditions qui doivent etre vraies. En sortant tu verifies les post-conditions qui doivent etre vraies. Par exemple, si ta fonction retourne un pourcentage, tu peux verifier que la valeur retournee est bien comprise entre 0 et 100. En pratique, tu peux utiliser les assertions ou ajouter du code pour gerer les exceptions/erreurs. Il faut aussi faire attention de ne pas trop en faire pour ne pas ajouter de bug en trop voulant s'en defendre! C'est un juste milieu.
- Quand tu ecris des egalites du genre if(toto == 0), tu peux inverser et ecrire if(0 == toto). Si tu oublies un '=' le code ne compilera pas, contrairement a la premiere version.
- Si tu ecris un switch/case ou des if/elif qui gerent tous les cas, tu peux ajouter un defaut ou un else qui gere la valeur inattendue.
Disons que c'est surtout un etat d'esprit, il faut etre le plus pessimiste possible. Si tu peux imaginer un cas ou quelque chose d'inattendu peut se produire, alors il faut le gerer. Il faut essayer de penser a tous les cas particuliers possibles. Sachant qu'en plus, tu auras des bugs avec les cas particuliers que tu n'as pas prevus. ;-)
Les tests unitaires verifient que le code fonctionne comme prevu. Mais il ne faut pas se "reposer" dessus pour faire du code de qualite. Les tests ne peuvent pas tout tester.
Je ne connais pas le C#, .NET et co. Mais c'est un langage de haut niveau, donc tu devrais etre tranquille. En fait, je pensais aux briques de base d'un programme comme les conteneurs, les files, les piles, les listes, etc.Et, tant que j'y suis, le framework .NET peut il être considéré comme un moyen de ne pas réinventer la roue? (je programme en c#, je dois donc etre un "monsieur Jourdain" de l'informatique qui fais du .NET sans le savoir
Tout d'abord merci pour les efforts que vous mettez à m'expliquer tout ça.
En partant du principe que d'autres programmeurs, par définition maladroits et peu précautionneux (c'est pas une insulte, j'applique vos principes), vont toucher à mon code, je suppose que je dois appliquer ces vérifications même pour ce qui est des méthodes privées (bien que pour le moment je sois le seul à les utiliser) ?
Alors c'est du tout cuitEn fait, je pensais aux briques de base d'un programme comme les conteneurs, les files, les piles, les listes, etc.
Répondre avec citation
Partager