Les outils de conception dégradent-ils l'expérience de programmation? [fermé]

J'ai récemment regardé autour de moi, en particulier certains des outils MS disponibles, et je remarque une grande concentration sur les outils de conception et les assistants. Pas seulement pour le développement de l'interface utilisateur, mais pour tout.

• Entity Framework a le modélisateur
• RIA Services possède le ou les assistants DomainService
• Workflow a tout le concepteur de workflow ... (je ne sais pas, je ne l'ai pas vraiment utilisé)

Il y a plus, mais je pense que vous avez compris. Il y a beaucoup d'outils de conception. En utilisant certains d'entre eux, je trouve que:

Ils compliquent les choses au-delà des cas d'utilisation prescrits

(c'est-à-dire toutes les vidéos de démonstration techniques)

J'ai évalué certaines de ces technologies récemment, et en essayant de travailler avec elles, je dois finir par disséquer exactement ce que les concepteurs, les modélisateurs et les assistants font pour moi ... sinon je suis perdu quand je dois vraiment essayer de le faire quelque chose avec tout ce qui a été créé.

Cela finit par être un cas où je dois combattre l'outil, ou lutter contre sa sortie suffisamment pour que j'aurais pu tout faire moi-même sans lui - et avoir une compréhension beaucoup plus forte de ce qui se passe. Je trouve cela particulièrement exaspérant avec le concepteur Silverlight et l'assistant de service de domaine des services RIA.

Je me demande "A quoi sert cet outil si je dois comprendre son fonctionnement interne ou réécrire la moitié de sa sortie afin de l'utiliser?"

Ils ne sont pas aussi rapides

Le point de vente de ces outils est d'augmenter la productivité et ce point peut changer au fil du temps en utilisant l'outil, et ne s'applique pas nécessairement aux concepteurs d'interface utilisateur (bien que, dans certains cas, il le fasse toujours -> je vous regarde designer silverlight) . Je trouve que je peux pirater du code beaucoup plus rapidement que je ne peux faire glisser-déposer, redimensionner, déplacer, quoi que ce soit dans un concepteur.

L'interface utilisateur gêne le modèle

C'est peut-être juste moi, mais quand j'utilise quelque chose qui rappelle un outil de conception UML, je finis par passer plus de temps à tout exposer pour que mes lignes ne se croisent pas et pour que je puisse tout voir à l'écran plutôt que de modéliser ce que je essaye de réaliser.

Ils ne sont pas amusants

La moitié de la raison pour laquelle je code pour vivre est que je l'apprécie. Cliquer sur des cases à cocher et sélectionner des combobox puis réparer tout ce qui sort n'est pas amusant.

Je ne semble pas être seul

La communauté ne semble pas non plus vouloir ces outils. Le meilleur exemple auquel je peux penser en ce moment est Entity Framework Code-First.

Alors je demande:

1. Les outils de conception améliorent-ils réellement la productivité?
2. Sont-ils des tueurs de plaisir?
3. Est « la communauté » fait demander plus de outils de conception, ou sont en train de penser les fournisseurs que nous sommes?

Je suppose que de bons outils de conception améliorent la productivité et ne vous éloignent pas du "plaisir". Cependant, ce n'est qu'une supposition car je n'ai pas encore trouvé un bon outil de conception.

Personnellement, je n'ai pas demandé d'outils de conception.

1. Je pense que cela dépend probablement. Si vous êtes un développeur assez inexpérimenté, l'utilisation des outils de conception est probablement plus productive que la saisie. Je suis assez certain que j'étais plus productif dans mes premiers jours VB6 en utilisant le concepteur que je ne l'aurais fait à la main. L'autre chose à considérer est de savoir comment la technologie (au moins comment l'IDE la présente) se prête à l'édition manuelle. VB6 et .NET WinForms ne le font certainement pas (ou plutôt vous ne voulez probablement pas éditer manuellement le fichier de code "généré" (ou une partie de). Avec WPF et ASP.NET, je pense qu'un développeur assez inexpérimenté commencera par le concepteur, mais passe rapidement à l'édition directe de XAML / ASP. Une fois que vous savez ce que vous faites, il est certainement plus rapide d'éditer directement le balisage. En repensant à EF v1.0,

2. Cela dépend si le balisage est amusant à travailler. WPF et ASP (.NET) peuvent être amusants. VB6 / WinForms - non ne veut pas éditer les sections de code générées plus que nécessaire.

3. Je ne pense pas que la communauté le fasse explicitement. Bien que, lors de l'apprentissage de quelque chose de nouveau, le concepteur puisse faciliter l'ingestion de morceaux d'apprentissage.

comme d'habitude, cela dépend

Lorsque j'ai étudié les services Web pour la première fois, Java avait un didacticiel de 50 pages et .NET avait un assistant. Devinez lequel s'est habitué?

Même chose ici, pas d'outil de conception.

Je conçois la base de données ERD sur papier et j'écris un déployeur qui émet les instructions "create table", de cette façon je peux effacer et reconstruire à volonté. Aide également au contrôle de version de la base de données.

Je trouve que le papier 11x17 (A3) peut être un excellent endroit pour concevoir des systèmes très compelex. Obtenez une bonne gomme et des crayons (je préfère Staedtler ).

Du point de vue des fournisseurs, tous ces outils de conception sophistiqués semblent servir un objectif similaire aux licences étudiants à prix réduits / gratuites. L'idée est de vous permettre de créer quelque chose avec un minimum d'efforts et de coûts. Une fois que vous êtes investi, ils parient que vous apprendrez à développer vos compétences avec leurs outils plutôt que d'aller apprendre ceux de quelqu'un d'autre.

Cela ne veut pas dire que les outils n'ont pas d'utilisations productives légitimes. Il devrait être utile d'examiner le code généré et d'en tirer des leçons. Malheureusement, comme Ken Henderson l'a noté, le code est souvent illisible et n'est pas quelque chose que vous souhaitez utiliser comme modèle pour de futurs travaux. Je me souviens de plusieurs sections de la programmation des services WCF , où l'auteur explique comment écrire du code manuellement ou le faire générer par Visual Studio. Inévitablement, l'option générée nécessite une section de suivi pour la suppression du code superflu.

Les outils de conception améliorent-ils réellement la productivité?

Ils peuvent aussi longtemps que votre projet est simple et pas trop complexe pour eux. D'après mon expérience, vous frappez le mur dès que vous essayez de mettre en œuvre / résoudre un problème du monde réel.

Sont-ils des tueurs de plaisir?

WF (Workflow) & WPF où amusant mais aussi tueur quand le VS 2008 s'est écrasé toutes les 30min.

«La communauté» demande-t-elle plus d'outils de conception ou les vendeurs pensent-ils que nous le sommes?

Beaucoup d'outils publiés récemment par MS semblent être des tentatives désespérées de garder les développeurs. La bataille se poursuit actuellement sur le marché des téléphones intelligents. Qui gagnera le cœur des développeurs, MS, Google ou Apple?

Cela a toujours été le cas, même à l'époque où nous faisions la distinction entre les développeurs qui ne savaient que cliquer sur les assistants et les développeurs qui savaient quel code les assistants généraient et pouvaient le modifier pour les cas limites.

Le fait que vous ayez encore plus d'outils, d'assistants et de concepteurs qui font tous des trucs sous les couvertures pour vous empêcher de vous couper sur les morceaux tranchants est un avantage pour les développeurs qui ne veulent pas savoir ou qui n'ont pas l'étendue d'expérience ou de compétence pour comprendre le code généré. J'imagine qu'il y a un compromis entre ce que vous voulez que l'ordinateur fasse pour vous et ce que vous devez faire vous-même car l'alternative est de programmer des langages entièrement basés sur le glisser-déposer de blocs sur un formulaire. (J'avais l'habitude de travailler sur une telle chose, un environnement spécifique au domaine, je ne voudrais pas l'utiliser!)