it-swarm-fr.com

Les programmeurs d'interface graphique ont-ils un avantage excessif sur les autres?

Il est facile pour les gestionnaires et les clients d'apprécier ce qu'ils peuvent voir.

J'ai vu de nombreux développeurs d'interface graphique qui sont des programmeurs moyens ayant une connaissance minimale des principes de conception ou d'autres idiomes de programmation. Cependant, ces lacunes vont souvent inaperçues, spécialement par la direction et les clients, si le programmeur peut créer une interface utilisateur impressionnante. Tellement de sorte que de nombreux développeurs d'interface graphique, je connais des heures passées à embellir l'interface graphique au détriment de la rédaction de Code mauvais, non immobile.

D'autre part, les programmeurs de niveau centraux qui développent des API ou des fonctionnalités d'entreprise ou un code de base de données (SQLS, etc.) sont désavantagés car il n'y a rien de tangible à présenter. Peut-être qu'un critique de code ou un architecte peut apprécier l'élégance, une bonne conception, une évolutivité, etc. du code, mais cela ne signifie rien dans le monde extérieur. Votre code peut courir pendant des années sans rupture, peut être très facile à maintenir et à avoir de bonnes performances, mais elle n'excite jamais le "WOW" qu'une gui graphique à la recherche de slick.

À mon avis, un corollaire à ceci est (et je vais être très évité pour cela, je sais) qu'il y a moins de motivation pour un programmeur d'interface graphique pour écrire un bon code de nettoyage.

ÉDITER : Je dois expliquer ici que par programmeur GUI, je ne veux pas dire un concepteur Web/interface graphique à part entière, mais un programmeur front-end, par exemple, un Programmeur Java-Swing.

Le reste de la communauté est-il d'accord?

23
Rahul

Je pense que je vois ton point, mais je soupçonne qu'il y a aussi une question opposée à considérer.

Essentiellement, je pense que vous suggère que, parce que l'interface utilisateur est l'élément de l'application "au visage" des utilisateurs finaux, les développeurs d'interface utilisateur bénéficient d'une visibilité plus élevée que les membres de l'équipe travaillant dans des couches plus profondes de l'application.

Je conviens certainement qu'il peut y avoir une visibilité plus élevée. Par exemple, les développeurs travaillant sur les éléments de l'UI peuvent permettre d'interagir avec les utilisateurs finaux plus souvent (sans doute, pour de bonnes raisons, car ils se concentrent sur l'aspect interaction humain/informatique).

Pourtant, je pense que la visibilité plus élevée entre en jeu, même dans les cas où il y a un problème. Par exemple, les utilisateurs finaux sont très susceptibles de signaler des problèmes comme "problèmes d'interface graphique", même lorsqu'ils ne le sont pas.

Il peut s'allumer à la perception et une organisation mature devrait pouvoir reconnaître les valeurs, les vertus et les faiblesses des différents membres de l'équipe de manière indépendante de quelle couche de l'application utilisée. Une organisation mature peut également avoir dépassé les distinctions telles que "UI Developer" et "Développeur de la couche d'entreprise", reconnaissant que ce sont tous les membres de l'équipe, avec une expertise différente, mais essaie toujours de nous éduquer sur ces domaines d'expertise.

21
FOR

Pour une personne qui ne traite aucun des programmeurs, je peux dire avec confiance qu'ils croiaient ce genre de choses. Ils ne connaissent pas la quantité de travail qui va en arrière-plan, tout ce qu'ils voient est une bande de boutons/textuelles/menus/[insert graphique] et la vitesse nécessaire pour accomplir ce que le bouton a commencé. Donc d'abord, les gens de l'interface graphique sont plus appréciés.

Si la personne fait traiter avec les programmeurs, alors son un peu différent. Comme vous l'avez dit, ils remarquaient que si vous l'avez réussi, vous avez plus facile à maintenir, réécrivez un algorithme de sorte qu'il ait plus de sens, ou toute autre tâche de type de maintenance. Ce type de personne examinerait tous les programmeurs de manière égale.

Au milieu, cela dépend de ce que vous faites. La vitesse devient alors le facteur important ici. Si vous pouvez montrer avant et après les enregistrements de la durée de la durée pour qu'un formulaire soit traité et stocké et qu'il y a une amélioration, vous êtes égal. Si vous pouvez afficher l'application sous charge à partir de 100 clients et leur montrer le serveur fondant, puis leur montrer votre version où tout va bien, votre égal. Etc.


En bref, cela dépend de la personne et de ce que vous faites.

10
TheLQ

Je déteste le développement de l'interface graphique pour deux raisons,

  1. Je suis plus logique que graphiquement artistique et mon UI souffre toujours de conséquence.
  2. Comme l'interface utilisateur n'est pas basée sur la logique, les tests unitaires sont presque impossibles à écrire avec aucun sens

À la fin de la journée, cependant, je pense que mon code sera mieux apprécié par l'utilisateur final (par opposition, peut-être à un sponsor de projet), que celui d'un développeur médiocre qui est un whiz à l'interface utilisateur. .

5
johnc

Pour (peut-être) développer un peu la réponse de @ Thelq, je pense que cela dépend également du "spectateur".

J'ai eu une certaine expérience avec quelques gestionnaires/superviseurs de niveau supérieur qui n'ont pas de fond de programmation. Certains apprécier qu'ils ne programme pas, mais comprennent que chrome et hubcaps sont tout aussi importants que le moteur et le châssis.

Et j'ai eu de l'expérience avec certains gestionnaires/superviseurs de niveau supérieur qui ne se soucient de métriques autres que les métriques autres que le grésillement de l'UI. Même en déclarant que plus de développeurs axés sur l'interface utilisateur sont importants.

IMHO, nous savons tous que vous ne pouvez pas polir une turd et une application rapide, fiable et laid, beaucoup pire qu'une application qui semble bonne et fonctionne bien. Tout est dans l'oeil de spectateur et dans une certaine mesure, vous avez le pouvoir (peu importe ce que vous faites) à voir dans la lumière que vous souhaitez, en travaillant pour ceux qui apprécient les mêmes qualités que vous.

EDIT: J'ajouterais peut-être une personne qui se sent plus à l'aise de travailler sur des objets de niveau inférieur, j'ai été bloqué lorsque vous travaillez également aussi dur que l'équipe de l'interface utilisateur et c'est le polonais qui est loué dans la démo et non le fait que le système " vient de travailler ". Mais comme je l'ai dit, je sais que mon superviseur savait que le travail est nécessaire dans tous les domaines.

4
DevSolo

Il semble souvent y avoir l'idée qu'un programmeur d'interface graphique est au bas de la chaîne des programmeurs. À quel point peut-il être difficile à faire glisser et déposer un bouton dans VS sur un formulaire? Quoi, ce sera une semaine pour programmer cela? Il dessine des barres. Donc, je ne suis pas surpris de voir l'idée que les programmeurs d'interface graphique, étant les draggers de boutons tels qu'ils le sont, doivent écrire un code horrible aussi.

La programmation de l'interface graphique a des défis uniques. Multithreading pour garder l'interface graphique active pendant que les données sont chargées. Cela conduit à un fil de protection et de code approprié. La performance est très importante. Noone aime attendre deux minutes jusqu'à ce qu'ils obtiennent à nouveau le contrôle de l'application. La ré-utilisabilité devient également un gros problème. Si vous devez écrire dix écrans similaires, vous feriez mieux de structurer votre code. Cela conduit à un meilleur code. Et bien sûr, créer une bonne interface graphique est un défi en soi.

Mais à certaines personnes, il va simplement faire glisser un bouton sur votre application. Tout comme pour certaines personnes, la logique commerciale n'est rien de plus que "d'analyser un message et de la mettre dans la DB".

3
Carra

Je pense qu'il existe une présomption générale que les développeurs de l'interface utilisateur sont les développeurs "junior". Je ne peux penser qu'un cas que j'ai couru dans où un gars d'UI était considéré comme supérieur.

Cela dit, je pense que l'interface utilisateur est beaucoup plus difficile que toute autre partie de nos applications. Et je ne parle pas du design UX, je parle du codage. Combien d'autres domaines indiquons-nous où nous devons rendre compte des dizaines, voire des centaines, ou des scénarios possibles? Il suffit de redimensionner un écran peut parfois devenir une douleur royale lorsque vous devez déterminer ce qui doit se produire avec deux douzaines d'éléments. Cela apparaît principalement lorsque vous avez des directives qui disent "nous devons supporter 800x600", puis les concepteurs UX qui n'utilisent jamais autre chose que les résolutions HD.

Donc, s'ils obtiennent plus de bonté en raison d'une plus grande exposition, ils le méritent probablement. Habituellement, ils sont sur la mauvaise fin de la réception plus souvent que la bonne extrémité de réception.

3
MIA

Je pense que c'est évident qu'ils font. Peut-être que les maisons de devis de dessus sont exemptées, mais la plupart des autres ne sont pas.

Lorsque votre responsable vous demande ce que vous avez fait au cours du mois dernier, il est facile de montrer une interface graphique cool. Il est difficile de montrer une API cool. Très dur. La fraîcheur de l'API n'est apparente que par une utilisation réelle - elle ne peut pas être appréciée en un coup d'œil.

2
enverpex

Tester des parties de l'UI de l'application est un cauchemar.

Chaque personne qui se sente compétente pour donner un conseil ou définir une demande de la manière dont vous devriez le faire.

Une fois que le système fonctionne bien, plus tard, même si quelqu'un se souvient accidentellement qui hésiète la vertu, personne ne se souviendra de qui a fait quoi.

Mais si une erreur sera vue (1 Toujours se produire), le premier homme à condamner sera le programmeur de l'interface graphique, l'utilisateur n'a jamais vu les autres!

1
Gangnus

Vous pouvez vous éloigner de toutes sortes de hacks et de raccourcis dans les systèmes internes. Lorsque vous traitez avec l'interface graphique, vous n'avez pas cette liberté. Votre API interne peut avoir une incohérence et vous vous attendez à ce que les codeurs traitent de cela parce que c'est trop difficile à réparer. Vous ne pouvez pas essayer et rendre vos clients faire la même chose. Donc, dans certains sens, les personnes qui doivent traiter avec les composants visibles par l'utilisateur doivent suivre une norme plus élevée.

1
Winston Ewert

Je vais dire oui, pour une simple raison simple: l'iPhone. Tout le monde j'ai déjà parlé de penser que c'est fantastique à cause de l'interface slick, mais je ne peux que imaginer le travail en dessous pour rendre cela possible.

1
Steven Evers

Cela dépend du public. Je travaille avec beaucoup d'analystes financiers et leur idée d'une bonne conception de l'interface graphique est celle qui a autant de champs que vous pouvez éventuellement bourrer sur une forme. Sérieusement, je parle de 75 - 100. Ce sont des junkies de données qui veulent toujours plus. J'ai récemment amélioré les performances sur quelques procédures stockées pouvant prendre 45 secondes pour charger (calculer les moyennes pondérées depuis le début des temps). L'a eu jusqu'à 30 secondes; Je pense que wow, coupez un tiers du temps; Cela devrait être un élément de ligne sur mon CV. Personne même remarqué. Continué à travailler dessus et l'a eu à 15-20. Changement notable. Tout le monde était très heureux. Je pense toujours que l'interface graphique est une abomination et si nous avons sorti cette merde inutile, elle chargerait en 2 secondes, mais lorsqu'il y a 15 zones de texte multiligne différentes (vous connaissez celles qui ont toutes les capacités de formation avec les paramètres de caractères maximaux .), C'est sans espoir.

Donc, si vous voulez que les utilisateurs vous aiment vraiment, rappelez-vous que la meilleure interface utilisateur n'est pas une interface du tout (souhaite que je me souvienne de savoir qui l'a dit). Après avoir voulu voir toutes ces données, mes analystes se sont rendus compte qu'ils sont ceux de faire toute la saisie de données - l'horreur.

1
JeffO