Un IDE entièrement graphique pour Delphi : est-ce réellement utilisable ?

Les pros sont sceptiques

Le 2013-02-01 04:44:13, par SNatoon, Membre du Club

Un IDE entièrement graphique pour Delphi
Est-ce réellement utilisable ?

Un IDE entièrement graphique, conçu comme un assistant complet de création de classes et de code, est-ce l'IDE parfait ? Ou une impasse ?

Voyez sur cette vidéo :

Le site de l'éditeur du freeware en question : http://softconstructors.com/en/appli...ons/stroycode/

Et vous ?
Que pensez-vous de ce genre d'environnement de développement ?

Discussion forum

35 commentaires

Paul TOTH
Expert éminent sénior

c'est joli, mais à mon avis loin d'être pratique.

à la rigueur lire un source Pascal pour afficher graphiquement les objets comme ça permettrait peut-être d'en facilité la lecture, de documenter etc...mais pour créer les classes je préfère la complétion de code.

le 01/02/2013 à 6:09
SergioMaster
Rédacteur/Modérateur

Bonjour,
c'est une très jolie interface , bien que je pense que ce n'est qu'une couche de plus tel l'évolution des traitements de texte . Ce que j'entends par là est que l'évolution est certes au rendez-vous mais au dépend de la productivité comme les traitements de texte simple au départ ce n'étaient que des machines à écrire , maintenant on y passe plus de temps a mettre en forme qu'a taper le texte idem on passera plus de temps sur cet outil a faire des clics, drag drops etc qu'a concevoir les Objets et écrire le texte produit au Final .

pour finir pourquoi ai-je l'impression d'avoir affaire a une publicité déguisée ? enfreignant les règles

le 15/06/2013 à 8:25
e-ric
Membre expert

Salut à tous

J'ajoute ma contrib'. Encore un gadget de marketing destiné au DSI...
Je me demande si les personnes qui ont développé ce machin s'en serviraient pour le maintenir...

C'est le genre de fausse bonne idée qui démontre la faible connaissance du métier de développeur de la part de cette société. Un éditeur de source qui ressemble à un éditeur UML, quel progrès... On prend parfois (sic!) les développeurs pour des demeurés. Pour de l'UML, la fonction communication avec des non-informaticiens a du sens mais pour l'édition de code source, j'ai encore du mal de voir l'intérêt, je suis sans doute un peu dépassé. Si vous avez déjà vu un "fonctionnel" lire du code, vous m'appelez.

Au final, je trouve que cela n'apporte pas grand chose, rien ne remplacera un bon éditeur de texte et la capacité du développeur à lire un source et le comprendre. D'un point de vue pratique, cette représentation graphique consomme plus de place à l'écran que l'affichage "traditionnel". Enfin, cela complique encore les environnements de développement en les rendant pus fragiles.

@+

le 17/06/2013 à 13:03
Paul TOTH
Expert éminent sénior

Envoyé par SNatoon

>> j'aimerai voir la tête de cet IDE avec 200
classes

(photo de 15 classes)

encore 185 et le compte y sera

un truc comme le poster des premiers Delphi (ceux qui étaient vendus en carton)

ou comme QT

le 05/02/2013 à 4:56
Charly910
Membre expert

Bonjour,

Tout cela pour éviter de taper ou de recopier quelques lignes de code. Je préfère l'IDE actuel, qui à mon avis a toujours été le meilleur devant les IDE des autres langages.

Est ce que cela fonctionne dans les 2 sens : si on modifie directement le code ?

A+

Charly

le 01/02/2013 à 8:33
ShaiLeTroll
Expert éminent sénior

Envoyé par Caribensila

quitte à utiliser des "objets", autant le faire franco et les manipuler dans l'IDE, plutôt que d'en faire de longues descriptions littéraires à la Balzac

Faut-il en faire !
C'est juste que la modélisation de classe n'a rien de nouveau !
Cela existe même dans Delphi : Diagrammes UML et Delphi

Synchronisation entre le code source et les modèles UML
[ame="http://www.youtube.com/watch?v=LTpAAz3WkZk"]UML Visualize With RAD Studio 2010[/ame]

Envoyé par Caribensila

Je suis sûr qu'on y gagnera en clarté et en efficacité car cela synthétisera, rationisera et uniformisera la conception ET l'écriture du code.

Perso, j'ai déjà ma propre couche objet métier persistant, quand tu as créé plus de 200 classes (en 2 ans), c'est vrai, on oubli un peu ce que l'on a fait !
J'ai prévu de faire un Doxygen, j'utilise déjà ce format de notation dans le code par habitude, faudra que je mouline un coup !

Envoyé par Caribensila

c'est la dimension "temps" dans la structure des applications qui devront être pensées parallèles.

C'est pour cela que l'on est censé faire des Diagramme de Séquence, des MOT, MCT... je n'en fais plus, disons que c'est fait au feeling et par habitude de jouer avec TThread, TThreadList, TMREWS, TCS, TEvent, ...
Je fais des applis proche d'un temps réel en intéraction avec notre matériel, il y a toute une partie de programmation basique proche de l'informatique de gestion, là un seul proc suffit pour afficher une pauvre IHM avec des DBEdit ... et des parties serveur bien plus costauds subissant des milliers de notifications à la seconde !

La parallèlisation de traitement inter-dépendant ce n'est pas évident, semble que le programmeur qui je remplace avait de grosse lacune à ce sujet ainsi un gros manque d'abstraction aussi !

Envoyé par Caribensila

Et encore, ce n'était pas explicite. Toujours est-il que cette démo illustre très bien comment on devra systématiquement tirer parti des architectures multicoeurs dans un avenir très proche.

Oui le but étant plutôt de contourner les limites de bande passante pour un téléchargement.
La sollicitation processeur est minime pour ce cas !

Envoyé par SNatoon

disent-ils, le compilateur sera au programme. pas besoin de savoir pascal

Le compilateur ???
Si leur programme génère du code, il suffit d'avoir celui d'Embarcadero ou même celui de Lazarus !
tu pourrais citer tes sources, je n'ai pas vu cela sur leur site

Si l'outil est en plus destiné à des "non programmeurs" qui ne connaissent pas le Pascal\Delphi, cela signifie que l'ensemble des traitements seront décrit par des graphiques, c'est utile dans un processus de développement très normé, je pense en SSII\Outsourcing avec un fort turn-over et donc facilite la reprise du code grace à la modélisation

Je trouve que Delphi est déjà trop utilisé comme un Clicodrome !
Combien ont des difficultés à faire un Create ou affecter un gestionnaire d'évènement par code parce que l'IDE les a aliénés !

Envoyé par Ph. B.

ils ont réinventé ModelMaker !

C'est vrai, je l'avais regardé, il y a un paquet d'année
Je crois qu'il ne fourni pas le support pour C++Builder ! si ?

le 01/02/2013 à 16:58
Paul TOTH
Expert éminent sénior

SNatoon, quelle est ta relation avec ce produit ? tu en fais manifestement la publicité, as-tu un intérêt personnel pour le faire ? en es-tu l'auteur ?

le 12/02/2013 à 5:16
ShaiLeTroll
Expert éminent sénior

Des outils comme Rational Rose le font déjà pour générer les tables et même du code
Tu as plein d'outil de conception UML qui propose une conversion vers Java ou C#

On peut penser que les outils DB de Embarcadero pourrait amener à ce genre
de chose avec une ré-apparition d'une bibliothèque façon BOLD

La bonne chose c'est que c'est orienté objet mais en tant que pro, je peux témoigner qu'au travers les 6 (petites) sociétés que j'ai traversé, la POO est peu maitrisé, souvent ce n'est que TQuery, TForm, TDataModule ou des compos persos héritant de TCustomEdit\TCustomPanel mais pas une vrai programmation architecturé !
Les Design Patterns c'est encore moins connu, alors que la POO sans Pattern, c'est la foire à l'andouille !

Je n'ai que très peu vu des objets métiers !
En une grosse décénnie :
UML, jamais vu !
Diagramme de Classe (DelphiToDoc les génère à partir du code pourquoi les faire avant )
GANTT, 1 fourni par un client et 1 que j'ai fait !
PERT, Aucun
MOT et Diagramme de Séquence, j'en faisais des tout pourris sous Excel ou Visio quand j'étais apprenti en alternance, j'ai totalement oublié comment on en fait depuis !

le 01/02/2013 à 11:58

ShaiLeTroll

Expert éminent sénior

Peu importe si c'est une publicité déguisée, plusieurs points font qu'elle dissuade l'utilisation de StroyCode

1- Beaucoup de Clic !
Comme tout le monde professionnel le sait, alterner entre le clavier et la souris est une opération lente
C'est pour cela que pour une application de saisie en masse, on va privilégier les raccourcis clavier pour réduire l'utilisation de la souris

Au final, un développeur qui a une bonne idée générale des deux classes qu'il va produire, ne devrait pas mettre plus de temps à taper le code que d'utiliser StroyCode !

D'ailleurs, pour la property, gros défaut de devoir créer séparément la variable privé et la property
Un assistant digne de ce nom devrait permettre de créer la property (Nom + Classe) et de générer au clic droit le partie simpliste Get\Set\FMember sans devoir faire ces copier coller

Dommage, il y avait là de quoi optimiser la frappe ! démonstration ratée à ce sujet !
Au moins le refactoring sur le renommage de FUser lui fonctionne ! c'est le minimum !

2 - Modification du sources par un programme autre que StroyCode !
On nous montre la génération, c'est bien mais incomplet !

Pas de démonstration de réintégration de modification dans cette vidéo, dommage, même une modification mineure aurait été sympa à être ré-intégré au diagramme !
Je pense à une modification faite en Delphi mais surtout à l'utilisation d'un outil comme TortoiseSVN utilisé dans une équipe de professionnel pour synchroniser les sources (merge auto, merge conflict ...), il faut que StroyCode puisse le gérer pour être convaincant !

3- Ensuite, le code choisi n'est pas terrible !
Utiliser un gestionnaire d'évènement affecté durant le setter, hum, j'ai fait cette erreur, je ne le ferais plus ! Trop vicieux !

On ne peut plus librement affecté le gestionnaire, ainsi si un controller dans son IHM ou TUserManager avait affecté son propre gestionnaire à cet instance de TUser, il est donc perdu !

C'est un sacré piège ce code !
On est à la limite d'une anti-pattern Action à distance

Un développeur aussi doué que l'auteur de StroyCode (faut reconnaitre que c'est assez "chiadé" visuellement) n'aurait du faire ce genre d'erreur de conception !

Evidemment, on pourrait tomber dans un abus d'architecture et obtenir une anti-pattern Programmation spaghetti avec un gestion des événements complexes avec une liste de listener et un tralala d'interface pour gérer plusieurs gestionnaire simultanément mais cela ne serait pas raisonnable !

Il y a plusieurs possibilités pour gérer cela SANS gestionnaire !

Une property ReadOnly ou une méthode LockRigths\UnlockRigths, pour empêcher une modification de Rigths
une property ReadOnly basique : true\false pose un problème si l'on rétabli ReadOnly à true au changement de TUser, est-ce correct ?
Mémoriser la valeur précédente, bof, pas très fiable

il faudrait un compteur comme BeginUpdate\EndUpdate
Cela a l'avantage de généraliser cela à l'objet TUser et pas juste au TSystem, le mécanisme LockRigths\UnlockRigths est réutilisable !

Autre technique le clonage d'instance, on connait bien cela avec le TPicture\TBitmap

TUser hérite de TPersistent et redéfini Assign !

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
constructor TSystem.Create();
begin
  inherited Create();

  FAdministrator := TUser.Create();
end;

destructor TSystem.Destroy();
begin
  FreeAndNil(FAdministrator);

  inherited Destroy();
end;

procedure TSystem.SetAdministrator(AValue: TUser);
begin
  FAdministrator.Assign(AValue); // Copie ce qu'il faut ! 
end;

L'inconvénient, c'est que si l'on modifie l'autre TUser, le TSystem ne le saura pas, on en revient à devoir faire une notification des clones, une patten Observateur pourrait être ainsi mis en place

L'avantage, c'est un code bien plus simple !

le 17/06/2013 à 11:56

arkhamon
Membre éprouvé

Bonjour à tous,
je suis assez d'accord avec les précédents avis. En particulier avec ShaiLeTroll quand il pointe du doigt (pas sur la souris ) le fait de savoir ce qui se passera quand on aura modifié le code avec Delphi et qu'on reviendra dans cet outil ? J'ai eu le même soucis à l'époque ou j'ai voulu apprendre Java, et que j'ai utilise un plugin de Eclipse pour faire la création des IHM : j'ai fait l'erreur de vouloir modifier un peu le code généré (sans trop le savoir d'ailleurs), ça m'a pété à la figure.

Donc mon avis de super spécialiste dans tous les domaines (je suis omniscient si si, et de super spécialiste du Delphi (environ 3% de degré de maîtrise des nouveaux concepts) me fait dire que ce genre d'outil de super maquétage destiné aux super projets, ben il est difficilement utilisable dans les super projets...

Plus sérieusement (sur mon niveau de compétence en Delphi, mais pas que), c'est vrai que j'ai pas mal décroché depuis près de 10 ans sur Delphi, et que le retour est parfois douloureux : y a des concepts que je ne comprends pas, d'autres dont je ne vois pas l'utilité, d'autres que je n'arrive pas à mettre en oeuvre. Le problème, c'est que un peu partout (et surtout ici), je lis qu'ils sont super top... Mais je pense que la programmation, ça passe encore par une phase primordiale d'écriture de code au clavier, et que tous les AGL et autres concepteurs super graphiques de code ont un gros défaut : ils ne sont pas intelligents, et donc ne savent pas gérer les cas hyper particuliers. Le problème, c'est qu'en développement, quand on fait du standard... on prend un produit standard. On se refait pas le sien...

le 18/06/2013 à 11:55

Poster une réponse