La gaffe
Par jacko - 15/12/2008 16:25
Par jacko - 15/12/2008 16:25
Par Anonyme - 24/07/2020 14:01
Par Anonyme - 03/11/2016 07:01 - Portugal
Par Qwerty - 10/08/2024 00:05 - France
Par Anonyme - 08/11/2023 10:20
Par brebisaveyronnaise - 07/08/2017 12:25
Par piarkzus - 04/06/2011 03:45 - France
Par Anonyme - 26/08/2024 14:05 - Switzerland - Lausanne
Par Anonyme - 24/09/2020 09:30 - France - Orléans
Par Clem - 01/05/2023 16:20 - France - Versailles
Par mememem - 30/05/2020 14:00
Un bon ingénieur devrait reconnaître ses erreurs. VDM pour lui, dommage pour toi. Avec un peu de chance il va te proposer d'en programmer un meilleur =D
Ha ha ha la gaffe! Ca commence bien dis-donc!
Si le logiciel a 10 ans ou plus, c'est un peu normal. D'une part, les outils ont évolué, ce qui permet de se concentrer un peu plus sur la logique et un peu moins sur les détails visuels, d'autre part il y a des modes en matière d'interface ; le top dans les années 90, c'était d'ombrer les boîtes de dialogue en mode texte ; boîtes rouges, fushia, ou autre couleur pêtante avec liseré blanc (on l'a tous fait, j'en suis sûr). Sans compter que les méthodes d'analyse ont aussi évolué : le passage à l'UML est en fait assez récent, il reste là dehors plein de truc qui se sont appuyés exclusivement sur Merise (voir seulement sur le feeling du développeur). La bonne question, c'est combien le soft rapporte à la boîte dans l'état actuel, et combien ça coûterait pour le changer (frais de dév, immobilisation de l'activité, frais de formation, remplacement éventuel du matériel, etc.)
Il faut aussi prendre les coûts de transfert des données de l'ancienne appli dans la nouvelle. Mais aussi les différentes phases de validations... des corrections d'anomalies... ça peut prendre des années...
#14: qu'il ait 10 ans ou pas ne change rien. J'utilise des softs surement plus anciens, bien pensés, et d'autres tout récents qui sont de vrais merdes. Si les capacité d'une interface ont évolué avec le temps, le fait qu'il existe des guidelines et des bonnes pratiques pour chaque époque est là depuis le début. Maintenant, vu que c'est un ingénieur qui apondu le truc, ca ne m'étonne que trop peu qu'il ait jugé utile de réinventer la roue.
#15: ça veut dire quoi ça:"Maintenant, vu que c'est un ingénieur qui apondu le truc, ca ne m'étonne que trop peu qu'il ait jugé utile de réinventer la roue."?
#16 je sais pas ce que ça sous entend pour l'ingénieur, mais je dois avouer que je suis assez fan de l'expression utilisée ^^ VDM pour lui en tous cas, espérons qu'il ne soit pas trop susceptible/rancunier =)
Pour l'expression "re-inventer la roue" c'est simplement que souvent on utilise cette expression pour signaler que : le développeur / ingénieur possède un tel égo qu'il re-écrit ce qui existe déja autre part et souvent il est deja optimisé, corrigé, plus fiable et robuste. Mais bien souvent il re-écrit en moins bien. Car en informatique il n'existe pas une seule façon de faire une chose mais plusieurs. Le fait de re-inventer la roue est contre productif : ça fais perdre un temps fou, alors que le morceau de code existe déjà (bin oui il faut re-analyser, re-developper...), la nouvelle version est rarement stable du premier coup. En bref imaginez simplement que vous vous présentez au bureau des brevet en 2008 avec votre nouvelle invention : "la roue", imaginez ce qu'on va vous répondre ^^
Personnellement, mon problème serait plus l'inverse : Actuellement j'analyse et corrige des anomalies sur une application. Ce qui m'horripile c'est justement les instructions redondantes et simplifiables, surtout lorsqu'une méthode faire pour ça existe déjà... Les controles de liste ni nulle ni vide, de chaine ni null ni égale à ""... les utilisations d'itérateur pour boucler avec un hasNext() lorsque l'on peut utiliser un for ensembliste... Je suis assez sûr de moi, mais les risques de regressions lors de ce type de correction ne sont pas nuls... Mais ça allège le code, simplifie la lecture, diminue la complexité cyclomatique du projet....
MDR sur la VDM, t'as du sentir le gros malaise :D Mais bon t'aurais pu te renseigner avant quand même :D
#14 => Totalement d'accord ! Il y a des logiciels en mode texte qui sont barbares d'aspect mais terriblements efficaces car fonctionnellement parfaits avec des temps de réponses exceptionnels. Souvent des logiciels métiers développés en internes ou faits par des spécialistes métiers nottement dans l'industrie ou chaque entreprise travail différement, dans ce cas la rien de tel que du spécifique à l'ancienne. En plus souvent ils sont amortis depuis des années et ne coutent quasiment rien en terme de licences ou de maintenance. A contrario un grand ERP généraliste qui veut tout faire mais ne fait rien de bien, avec de jolies interface développé en Java et qui rame à mort ça devient vite problèmatique. Sans compter le prix pohibitif des licenses plus des technologies et des paramétrages réservés à des spécialistes extremement pointus qui se prennent pour des Diva et qui sont facturés 1500€ la journée. Ca peut vous "SAPper" le travail =) Restons pragmatiques !
#20 => D'accord avec toi. Mais si demain celui qui a inventé ton joli logiciel spécialisé démissionne et n'a laissé aucune documentation, qui va avoir le courage de plonger dans un joli code COBOL pas commenté ?? Un logiciel fait maison, c'est bien, ça répond plus au métier et aux spécificités qu'un ERP mais ce n'est pas péreint et tu dépends donc souvent d'une personne. En gros un logiciel maison ce n'est pas péreint. Et je te parle même pas de faire communiquer ton logiciel avec d'autres systèmes via interfaces si la personne qui l'a conçu n'est plus là ...
Mots-clés
ba!! au moins il voit que tu t'y connais et pourra peut être te proposé de modifier son prog !! courage ...
Si c'est de la merde, c'est de la merde, rien n'à ajouter. S'il l'a développé, c'est plutôt pour lui la VDM.