Vers la fin des développeurs ?
LeChatNoir
Membre, Modérateur
Apple veut démocratiser la fabrication d'applications visiblement...
Z'en pensez quoi ?
http://www.appleinsider.com/articles/12/04/12/apple_wants_to_make_it_easy_for_non_programmers_to_build_ios_apps.html
Z'en pensez quoi ?
http://www.appleinsider.com/articles/12/04/12/apple_wants_to_make_it_easy_for_non_programmers_to_build_ios_apps.html
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Interface Builder a été créé à cette époque par Jean-Marie Hullot (un français) pour justement permettre à chacun de créer son application et de ne passer la main au développeur que lorsqu'il est nécessaire de customiser des comportement.
Les Storyboard sur iOS s'adresse exactement à cette problématique. Même principes pour Dashcode qui permet de créer les Widgets pour Mac, cet outil est même capable de générer un datasource pour une interface complexe avec bindings à partir d'un simple XML.
Est-ce pour autant la fin des développeurs ? Non, au pire la fin des mauvais développeurs, mais ce ne serait pas un mal.
On a dit la même chose quand Flash à sorti son outils d'export iOS, quand Windev a sorti un soft pour faire des applis en 3 clicks, pire avec des portails comme Kawet et compagnie où tu fabriques ton app (native) via un portail web.
Ce genre de chose s'adresse à des développements basique, utiles à un bloggeur, une petite app etc, mais pas au développement avancé.
Au pire ? On aura moins de projets mais plus gros et plus intéressant, moi, je signe de suite
J'ai du mal à voir en quoi cela pourrait être la fin des mauvais développeurs.
Par ce qu'ils sauterons sur HyperCard pour iOS et laisserons tomber l'Objective-C trop compliqué.
Combien tu en a qui viennent en forma avec une expérience type WinDEV et en se disant développeur... Ils partirons sur du clic clic au lieux de faire du dev Cocoa, ça me gène pas...
Je ne vois pas en quoi Windev n'est pas du développement. C'est du code, de code et encore du code associé à une interface style IB. C'est du RealBasic en plus moderne.
Pour avoir eu quelques gens ne faisant que du WinDEV & cie sous Windows je dois dire que non, je ne les classes pas dans la case développeur. Aucun connaissance en gestion mémoire, en orienté objet, en design pattern...
àŠtre développeur c'est pas juste pisser du code, il y a un travail de réflexion et de compréhension qui va autour et qui est totalement mis de coté par les gens qui utilisent ce genre d'outil...
Ce n'est pas l'outil qui est mauvais en soit, c'est juste qu'il est conçu pour une communauté de gens qui ne sont pas des développeurs, c'est tout. C'est fait pour le mec un peu plus geek que les autres qui veux aller plus loin qu'Access...
Mais ce n'est pas un mal en soit, il y a ce genre de besoin, et c'est même utile au business de développeur. Au moins les gens comprenne que notre boulot est complexe, ils se mettent un peu à notre place avec une voiture téléguidé et se rende compte que c'est pas si facile à diriger, comme ça ils braillent moins quand on leur annonce les prix pour le chauffeur de la vrai voiture... ^^
(Approche simpliste et trollesque, mais on est vendredi ^^)
Ha ok, alors si être développeur c'est gérer la mémoire à la mano... (réponse à l'approche trollesque
Je n'ai jamais aimé ni compris l'expression "pisser du code". Si cela consiste à faire du copier coller de bout de code, on peut alors également "pisser du code" en Cocoa/Objective-C.
Pour moi, cette polémique est de la même veine que celle qui opposait jadis ceux qui ne juraient que par VI et les adeptes de "clicodromes".
Quand j'officiais en SSII, il y a 25 ans, il y avait des vieux qui avaient encore le réflexe d'économiser la mémoire bit par bit. Ils connaissaient les arcanes de la machine comme leur poche. Mais au final, ils pondaient des logiciels certes économes mais impossible à entretenir (sauf par eux) et dont les fonctionnalités et l'ergonomie était systématiquement sacrifiée sur l'autel des performances et de l'économie de ressource.
Je vais oser un parallèle mais entre un Prost qui connaissait sa voiture dans ses moindres détails et un Senna qui connaissait tout juste le principe du moteur à explosion, qui est le meilleur pilote? je dirais même plus, Senna est-il un pilote?
On peut pisser du code dans tous les langages effectivement, c'est même l'étape de base pour apprendre un langage et le maitriser.
La critique que tu porte aux vieux qui faisaient de l'économie bit à bit, je ne la comprend pas. Beaucoup l'on aujourd'hui et certes ce n'est plus nécessaire de le faire mais pour autant il ne faut pas tomber dans l'excès inverse. Surtout aujourd'hui avec le développement d'application mobile où les performance et l'économie mémoire sont une priorité.
Une fois où je donnais une formation au développement iOS j'avais dans ma classe un développeur venu du monde Java, des SSII et tout le bordel, ton profil donc grosso modo. Quand j'ai abordé la phase de gestion mémoire et d'utilité que ça présente, sa réaction a été de me dire "Ah ouais, vu sous cet angle ça serait utile de voir sur nos langage à garbage collector comment l'optimiser et l'aider pour réduire la conso mémoire et améliorer le temps de réponse"...
Réponse édifiante s'il en est d'une école de développement formé autour d'outil trop loin de la machine et n'ayant plus en tête les problématique d'optimisation, et quand on voit la "performance" des appli métier pondu par les SSII il n'y a pas de quoi s'étonner...
Ton parallèle avec Prost et Senna est tout à fait intéressant, Je ne demande pas à un développeur de savoir comment est fait son langage ainsi que les arcanes du runtime (sauf si je cherche un expert), par contre je lui demande d'être capable de comprendre ses outils et de savoir cherche le moment venu quel outil choisir entre deux qui ont un fonctionnement à priori identique.
Je suis encore jeune, mais j'ai délibérément choisir un curus d'étude dans le passé qui m'a fait commencer par l'électronique, des robot, des micro contrôleurs et de l'assembleur. ça ne me sert à rien aujourd'hui sinon savoir comment marche une machine et ce que fait pour moi les outils intermédiaires, ça permet d'avoir une pensée cohérente, car il ne faut pas oublier que le travail d'un dev c'est aussi savoir penser ce que la machine va faire et s'adapter.
Et je dois dire que je suis plutôt conforté dans mon point de vue quand je vois assez souvent des demandes d'intervention pompier... La deadline est dans 15 jours, l'application fonctionne par contre c'est lent / il y a des bug graphique / ça consomme trop... Bref, au secourt il faut quelqu'un qui comprend ce qu'il écris pour optimiser tout ça par ce que c'est la merde.
A la lecture de tout ça, j'ai l'impression d'être un vieux d'un coup !
- j'utilise VI au quotidien au boulot
- je gère moi même la mémoire (en C forcément, mais aussi en objective C) et je repousse dédaigneusement ARC
- j'économise la mémoire. Peut être pas bit à bit car je ne suis pas de la génération de ceux qui devaient le faire, mais cela reste nécessaire aujourd'hui pour gérer proprement des centaines d'accès simultanés sur des applications.
Yoann j'ai des potes qui bossent en SSII et je pense savoir pourquoi ils ne soucient pas du tout de la gestion mémoire. Déjà ils sont passés d'un langage d'apprentissage bas niveau (le C dans mon école) à un langage type Java où direct les profs disent : bon bah c'est cool Garbage Collector on s'en branle maintenant de la gestion mémoire, la machine virtuelle fait tout toute seule. Déjà ça n'aide pas. Les écoles ont quand même un énorme défaut : l'ère du mobile elle l'ont loupé. Coder un projet de gestion d'équipe de foot (moi qui aime pas le foot en plus) sur machine desktop je trouve ça lamentable. Pourquoi ne pas le faire sur device ?? Je paie pas une fortune ma scolarité pour au final qu'on me dise "non mais faut acheter des tels et le prof ne sait pas faire". Je résume mais en gros c'est ça. Avec une approche mobile, je pense qu'on aurait pu mieux se soucier du management d'allocation et de ses conséquences sur les performances de l'application.
Bref ça c'est le premier point. Ensuite les SSII ... J'ai réellement voulu éviter ce genre de boites car la plupart d'entres-elles (tu sais, celles qui viennent te su*** au forum entreprise de ton école avec leur commercial type Jean Claude Convenant) sont de véritables usines à gaz. Mes potes me sortent qu'en gros, leurs SSII prévoit un contrat à 800 jours dev mais que pour être compétitif bah elles devisent à 300 jours. En 300 jours au lieu de 800, je vois pas ce que tu peux faire d'autre que pisser du code ... Ensuite bien entendu le client à une app bourrée de bugs et est pieds et points liés à la SSII pour les corrections de ceux-ci.
J'ai un petit projet iPhone pour un copain qui a monté une école de ski indépendante, c'est une pure application d'image pour son école. Il y a deux ou trois jours de dev en Objective C et il ne trouverait personne pour lui coder s'il devait payer.
Un outil comme celui ci lui permettrait de le faire tout seul...
Perso je passe au final pas tant de temps que ça à taper du code, même si évidemment ça reste indispensable. Je passe pas mal de temps à faire de l'archi, et quand je code je structure mon code. Ca peut sembler logique, mais crois moi il semble quand je vois certains codes d'autres personnes que c'est loin d'être le cas de tout le monde que de structurer son code. Et au final, quand on arrive à la phase de maintenance et d'évolution du produit, c'est une vraie horreur si tu t'es contenté de pisser du code.
Je ne demande pas aux gens de mon équipe de connaà®tre toutes les arcanes de Cocoa, ou du C, ni maà®triser parfaitement comment fonctionne un compilateur. Mais je leur demande de réfléchir un minimum et d'organiser leur code en modules, avec une architecture réfléchie et évolutive et compréhensible. (Les design patterns, c'est pas pour les chiens). Et c'est ce qui fait toute la différence à mon sens, côté technique.
Il y a également une partie ergo. Certes il y a des métiers pour cela, mais dans la pratique on se rend compte que même si nous développeurs on n'est pas des ergonomes, rares sont les ergonomes qui connaissent bien les plateformes mobiles et connaissent les habitudes des utilisateurs sur iPhone par exemple. Dans ce cas il y a aussi un travail de conseil pour indiquer que non, tel truc ça se fait pas comme ça, on peut le faire techniquement si vous voulez mais ça va choquer l'utilisateur.
Et aussi, je vois très (bien trop même) souvent des incohérences ou des cas d'usages non traités dans les specs, du genre "ah mais oui mais si y'a pas de réseau quand on appuie sur ce bouton, ou si la requête réseau a échoué, on fait quoi ?". Problématique qu'il y a bien plus souvent sur mobile que sur ordi de bureau, évidemment. Et ce genre de cas, un bon développeur doit y penser, et doit prévoir une organisation/architecture de son programme en conséquence, pour traiter les cas d'erreur, etc.
C'est pas des outils clés en main qui permettent de faire toutes ces étapes de travail d'analyse, d'organisation du code et d'application des design patterns. Certes les applis à la Hypercard sont très bien, et très pratique, pour faire un petit truc vite fait. Mais on ne joue forcément pas dans la même cour si on débarque dans le dev et qu'on n'a pas en tête toutes les problématiques évoquées plus haut (ou celles indiquées par yoann) et qu'on veut juste faire un truc vite fait, ou si on fait du dev professionnel et des produits finis. Quand je vois la qualité de certains softs (ou de certaines API/SDK) qui sont sensés être des outils et produits professionnels, mais qui au final explosent la mémoire, crash facilement, ou surtout n'ont pas gérés les cas problématiques classique (pas de réseau, appli qui passe en bkg, et j'en passe), ça me dépite.
Je suis d'accord avec ton analyse a ceci près que tu opposes développeur iOS avec développeur mainframe. Je ne vois pas pourquoi il faudrait mépriser le second, il n'a pas du tout les mêmes contraintes. Par ailleurs, je ne suis pas sûr qu'un développeur iOS pointu se sente à l'aise avec un langage de très haut niveau (ou un [url="http://fr.wikipedia.org/wiki/Développement_rapide_d'applications"]RAD[/url]).
Entre parenthèses, si les développeurs que tu cites viennent se former chez toi, c'est qu'ils ont conscience que développer sur mobile, nécessite l'acquisition de connaissances et de méthodes nouvelles. Il ne s'agit pas seulement d'apprendre un langage.
Je partage le point de vue d'Ali, un développeur doit avant tout avoir des qualités d'ergonome, il doit savoir se mettre à la place d'un utilisateur, travailler son interface et ensuite il organisera et optimisera sa technique. Evidemment, celle-ci doit suivre, une application ergonomiquement parfaite qui plante est sans intérêt. Cependant, le plus important et de loin, c'est que l'utilisateur appréhende facilement l'application, l'utilise sans se poser de question, sans avoir à lire la doc, sans devoir interpréter des messages d'erreur ésotériques, etc. Quitte a sacrifier quelques octets.
Autrement dit, mieux vaut quelques fuites mémoire qu'un plantage pour désallocation intempestive (je parle pour moi, la
J'ai toujours eu une grande admiration pour les gens qui réalisent de la microprogrammation. Pour le coup, leur technique doit être très pointue et sans faille mais ce ne sont pas des développeurs. Ces derniers doivent intégrer une autre dimension: l'utilisateur.
Une appli ergonomique mais avec des fuites mémoire et qui crash c'est poubelle pour moi.
Sinon autant faire du flash et vider ta batterie de smartphone ou déclencher les ventilateurs de ton ordi systématiquement.
Je ne méprise pas le second à la condition qu'il ait conscience de ce qu'il se passe autour de son code. Une fuite mémoire sur un mainframe c'est bien pire que sur un iOS. à‰tant admin sys également je discute avec mes confrères en grosses sociétés. Entendre que dans ces univers là des développeurs demandent à ce que les serveur soient périodiquement redémarré pour des soucis de stabilité ou fassent des demande d'instance avec 128 Go de mémoire vive... Je me dis qu'il y a un problème. L'approche n'est pas la bonne même si ça fonctionne.
Un code optimiser est nécessaire sur du mobile mais il est également sur un gros serveur, c'est pas par ce qu'on a de la ressource qu'on doit la gâcher...
Et pour ce qui est de l'ergonomie, nous sommes obliger d'en faire en tant que développeur par ce que les équipes sont généralement constitué sans personne dédié à ce poste, quand on à de la chance on à un designer sensible à ces questions mais la plupart du temps c'est le dev qui doit s'y coller. Pour autant ce n'est pas notre rôle. Notre job c'est de faire une application performante et stable tout en étant capable de dialoguer avec le reste des corps de métier. Mais ce n'est pas par ce qu'on est capable de discuter et soulever des problèmes d'ergonomie qu'on doit prendre également cette casquette.
^^
Allons, les vrai programmeurs utilisent l'effet papillon !!
Fred
La première version de VB date de 91.