outils rad comme Clarion et WINDEV prétend être de 10x à 20 fois plus rapidement dans le développement et les utilisateurs de ces outils revendiquent la même chose. Si cela est à travers, pourquoi y a-t-il si peu de gens utilisant ces outils? Si une application est faite en 40 heures au lieu de 400, vous feriez beaucoup plus d'argent, non?
10 Réponses :
rapide ne signifie pas toujours précis. Un exemple que je peux penser, si quelqu'un développait un stimulateur cardiaque, je préfère passer à 400 heures de le faire correctement au lieu de le développer en seulement 40 et risquer un résultat sinistré potentiel.
Je doute que vous puissiez, ou vous devez utiliser un outil RAD pour développer un stimulateur cardiaque. Cela reflète l'une des nombreuses idées fausses sur les outils Rad.
Pas entièrement vrai. Ils peuvent améliorer la productivité de certaines tâches de peu de tâches. Et la plupart des IDE contiennent déjà de nombreux outils pour améliorer la productivité. Par exemple, les modèles de code et l'achèvement du code. Donc, je ne pense pas qu'ils puissent gérer 10 à 20 fois pour tout un projet, comparé à d'autres outils modernes.
Les outils rad ne vous donnent pas la personnalisation de la rédaction de choses. Le client dit généralement quelque chose comme "Ce serait bien s'il fonctionnait exactement comme celui-ci", ce qui serait un changement très rapide si vous l'aviez codé, mais vous aurez besoin d'étudier l'outil pour voir si ce changement est possible (et frustrera le client, si ce n'est pas).
En outre, vous avez plus de contrôle sur ce qui est fait et est moins susceptible d'avoir un comportement bizarre »causé par de mauvaises hypothèses. Il est plus facile d'écrire des tests aussi.
Enfin, c'est une toute nouvelle chose à apprendre, avec un risque que le temps passé ne vaut pas la peine (peut-être, mais je ne suis pas disposé à faire du risque d'apprendre quelque chose de trop spécifique que je pourrais ne pas utiliser) .
parce que
Point 6: L'effet VB6
Le meilleur outil de rad que je connais serait un accès MS!
Très bonne réponse. Je suis d'accord avec tous. Je commande probablement comme: 1, 6, 3, 2, 4, 5, 7. J'ajoute probablement probablement quelque chose lié à une abstraction fuite (type d'indirectement implicite par 2 et 6).
Aimez le dernier point, qualité, prix, temps. Choisis en deux.
Il n'y a pas de Bullet Silver .
Dans mon expérience, les outils radiens et les IDes Ides retirent une partie de la corvée du codage, mais faites peu pour accélérer un projet. Les principaux gains de productivité de la productivité arrivent bien plus tôt dans le cycle de développement de logiciels, en définissant spécifiquement la nature, la taille et la portée du problème, créant des estimations et la gestion des risques.
aucun outil rad peut corriger les erreurs réalisées tôt dans le SDLC . En fait, le contraire peut se produire: les développeurs utilisant ces outils peuvent rapidement changer de code contre une mauvaise spécification. Cela donne l'illusion qu'ils sont productifs, en réalité, le mauvais produit est en construction.
Lorsque vous décidez d'utiliser un outil RAD, vous acceptez certains sacrifices:
La connaissance intime du code / système est une chose très difficile à avoir lorsque vous avez généré une grande partie de votre code ou a permis à un outil RAD d'aider.
flexibilité peut être perdue; Certains outils annuleront des modifications apportées par l'homme et régénéreront le code comme ils savent comment. Personnellement, je pense que ces outils devraient pouvoir identifier lorsque des modifications ont été apportées par une personne et à la moindre refuse de courir - les changements humains doivent toujours prendre un précédent.
Souvent, ces outils peuvent aider au développement de Greenfield, mais laissez une quantité monstrueuse de code derrière pour entretenir. Les revendications de 10x à 20 fois les gains de productivité sont probablement mesurées par des lignes de code plutôt que par des fonctionnalités finies réelles.
Si on a déjà une équipe utilisée pour certains IDES, quel est le coût de la modification de cela? Je veux dire si je passe de Visual Studio 2008 à Clarion ou WinDev, mon employeur est-il prêt à gérer les coûts que ma décollage sur ce sera-t-elle? Il y a aussi la question à laquelle j'ai eu la question de savoir combien ces outils coûtent-ils et quels types de garanties que celles-ci peuvent être indiquées qu'ils le feront aussi bien que réclamés.
Vous ne pouvez pas faire confiance à un outil RAD pour écrire un code propre et maintenu. Voyez-vous simplement pour vous-même, utilisez le concepteur Visual Studio, faites glisser une connexion DataGrid et une connexion de base de données, puis vérifiez le code désordonné qu'il générera, si vous devez personnaliser quelque chose qui n'était pas prévu par les développeurs de l'assistant que vous trouverez à un beaucoup de problèmes. Maintenant, comment allez-vous maintenir le code? Tout est si désordonné et étroitement couplé.
Je ne considérerais pas Visual Studio Designer un outil Rad, même s'ils le commercialisent comme ça.
Il n'y a pas de balle d'argent, et les revendications de 20x, etc. valent un grain de sel.
Cependant, une grande partie est la perception mentionnée dans les autres réponses dans ce fil. Ils varient de la simple ("ne peut pas être vrai") au générique ("difficile à personnaliser") au général ("génère un code désordonné"). Afin de réellement vous comparer, vous devez comparer un environnement 3GL spécifique avec un environnement de 4GL spécifique. Les deux auront des forces et des faiblesses. Les deux vous permettront probablement de créer de bons ou de mauvais programmes.
La plus grande limite est le facteur de compétence. Pour obtenir le meilleur de tout outil prend du temps et des efforts. Il n'est pas surprenant que les utilisateurs de 4GL sont souvent les plus gros partisans de celui-ci, donc clairement que quelque chose à leur sujet fonctionne pour beaucoup de gens. Mais ils coûtent généralement plus cher (acheter), ont leurs propres idiosyncrasies et leurs propres forces et faiblesses. Obtenir des programmeurs à convertir d'un environnement à un autre est difficile.
Dans les grandes organisations, il y a aussi beaucoup de code existant pour répondre aux besoins. Si vous avez des équipes de développeurs, il est difficile de créer une affaire pour changer toute une équipe de programmeurs d'un outil à un autre. Même si vous l'avez fait, sans utilisateur expérimenté existant dans l'équipe, le processus d'apprentissage sera lent et dur. Encore une fois, cela est vrai, quelle que soit la langue ou l'environnement.
L'économie joue également une grande partie. Entreprises comme la sécurité d'être dans le flux principal. Même si cela coûte plus cher. Ils aiment l'idée que des escadrons des programmeurs sont disponibles pour écrire du code dans la langue "actuelle". Les programmeurs sont une marchandise qui devraient aller et venir et peut être remplacée en cas de besoin. Le monde est plein de programmeurs C, Java, C #, etc. Choisir une "petite" langue, bien que des résultats politiques infinies, des décisions doivent être justifiées et ainsi de suite. C'est l'ancien "personne n'a été tiré pour acheter IBM" Syndrome. À la fin de la journée, si l'argent n'est pas un objet, il y a d'autres considérations qui (politiquement) sont plus importantes.
Il n'est pas surprenant que la plupart des utilisateurs de produits tels que Clarion et Windev sont des programmeurs indépendants ou des membres de très petites entreprises. Dans ces situations, l'économie quotidienne compte plus que d'utiliser le dernier outil ou le rembourrage d'un CV. Imaginez un monde où vous êtes payé que lorsque le programme est expédié. Soudainement, la productivité crue importe et la chose la plus importante consiste à faire le travail afin que vous puissiez manger.
Comme il y a beaucoup plus de personnes travaillant comme employé que de travailler pour eux-mêmes, il n'est pas surprenant que la plupart des programmeurs n'ont pas besoin de s'inquiéter directement de se faire payer. Si vous obtenez votre salaire, peu importe ce que vous utilisez, vous pourriez aussi bien aller avec le flux. Il y a beaucoup plus d'emplois là-bas si celui-ci réussit. De sorte que les outils traditionnels restent grand public, et tout le reste est ignoré.
Le fait que nombre des idées préconçues mentionnées dans d'autres réponses ici sont fausses ne comptent pas vraiment. La perception est tout et dans un monde binaire de droite et tort, quelle que soit la langue que vous utilisez maintenant est la "droite", et le reste est "faux".
Vous pouvez utiliser le même argument pour répondre à la raison pour laquelle les gens utilisent Java ou PHP au lieu de Python. La réalité est que AI n'existe pas et ces outils ne sont que sucer. Ces "programmeurs indépendants" ne sont pas des programmeurs du tout. Lorsque vous devez livrer un produit de qualité, allez-vous compter dans le code généré par un outil? J'ai utilisé des rads pendant 3 ans et que je me dise: je préférerais même C.
Je crois que les outils rad ne vous donnent pas une main flexible sur le code. Toutefois, si un outil RAD spécifique économise 60 à 70% du temps de développement, il vaut la peine d'investir du temps. Les développeurs qualifiés d'aujourd'hui - une journée sont à la demande maximale. Cela conduit à augmenter dans les ratios d'attrition. Les développeurs fiables démissionnent pour 5/10% de la hausse des paiblies. Cela impacte beaucoup les sociétés de développement. Celui qui a fait la majeure partie du développement, part soudainement. Cela frappe sévèrement l'horaire d'achèvement du projet. Les outils Rad rend l'organisation moins dépendante des développeurs qualifiés. Plus important encore, la plupart des clients sont les moins dérangés de la technologie que vous utilisez pour le développement. Ils sont heureux si leurs exigences fonctionnelles sont remplies.
Tout a dit et fait, RAD Tools aura une demande croissante dans le scénario actuel, où l'attrition est élevée. La plupart des projets sont traînés du calendrier juste à cause de cette dépendance. Les lecteurs peuvent différer.
Utilisez un cadre et une orèse. La génération de code n'est pas flexible et conduit à un logiciel de mauvaise qualité. Si vous respectez les normes (rails, django ou même printemps), tout développeur peut comprendre et étendre votre code
Parce que ce type de silhouette est presque certainement une revendication très excitée? Parce que les gens ne croient pas le marketing BS?
Totalement d'accord, je ne crois pas que ce marketing BS, BTW ... Je suis en discussions avec des gens souvent qui réclament ces choses aussi ... je voudrais leur prouver tort ... je crois que des langues comme Java, C #, PHP et beaucoup d'autres sont beaucoup plus puissants que ces deux exemples.
Et aussi vite, si vous savez ce que vous faites ...
Je n'avais pas réalisé que ces clunkers étaient toujours là. H.p. Lovecraft avait raison.