Si on ne connait pas les besoins réels du projet, je pense qu'une bonne réponse est déjà de concevoir son architecture applicative de façon modulaire afin de pouvoir retarder les choix de composants externes le plus longtemps possible, voire éternellement.
Bob Martin a une anecdote intéressante à ce sujet : un projet où on a pu se permettre de ne pas trancher la décision d'opter pour tel ou tel SGBD relationnel pendant des mois et des mois, pour finalement se rendre compte qu'il n'y avait pas besoin de SGBD relationnel pour le type d'application développée.
Une fois l'architecture posée, pour moi il y a deux grandes catégories de composants externes :
- Les "must have", briques essentielles d'un système. Ce sont souvent de gros frameworks liés au mécanisme d'acheminement de l'application (web, desktop, mobile...), à la persistance (ORM, SGBD), à la circulation d'information (bus de données). On peut reporter leur choix pendant un temps mais il faut quand même rapidement trancher si on veut livrer une application fonctionnelle.
Critères de choix : Maturité et perennité du framework. Base d'utilisateurs, communauté active, support. Se greffe-t-il bien sur notre architecture ou doit-on la tordre dans tous les sens pour faire "rentrer" le framework ?
- Les "extras" qui vont apporter des gains de productivité ou le petite cerise sur le gâteau avec à la clé un avantage compétitif pour notre produit. Généralement il vaut mieux faire abstraction de toute tentation induite par un effet mode et se demander si on a réellement besoin du dernier framework dont tout le monde parle. Une bonne technique peut être d'attendre de ressentir 2 ou 3 fois la "douleur" de ne pas disposer de tel ou tel composant tierce partie avant de se décider à l'intégrer.
Critères de choix : ai-je réellement besoin de ce composant/librairie ? Le cas échéant, en quoi va-t-il satisfaire les utilisateurs de l'application et nous procurer un avantage compétitif ? (travail d'enquête utilisateurs, etc.)
Au final, je pense qu'il faut toujours garder en premier à l'esprit ceux pour qui on conçoit l'application : les utilisateurs. Le choix de tel ou tel framework et l'éventuel empilement de composants externes ne doit être qu'un moyen pour aboutir à une fin : une application que les utilisateurs comprennent, apprécient et qui les rend plus productifs.
Un autre problème, pas souvent abordé, est l'analyse de la pérénité des outils :
- Une bibliothèque apparement très bonne peut réceler des bugs (ah les vilaines bêtes) et si elle n'est pas maintenue .....
- Une application peut vivre longtemps et devoir subir des migrations, quid de la bibliothèque non maintenue ? Je me rappelle de migrations depuis java1.1 de programmes utilisant des bibliothèques (non portées, incompatibles ...), il a fallu re-développer la moitié de l'appli.
Il faut se poser toutes ces questions avant de choisir une bibliothèque ou framework ou outil.
Bonjour a tous,
moi je vais me contenter de faire 3 constats et de poser une question. Mes constats :
- pour piloter un airbus A330, ue compagnie aérienne embauche un pilote de ligne diplôme en aviation civile, et pas un jardinier, aussi doué soit-il avec son avion radio commandé...
- Pour faire de la chirurgie cardiaque, un hôpital embauche un chirurgien cardiaque diplômé en chirurgie et spécialisé en cardiologie et pas un plombier, aussi doué soit-il avec des tuyaux...
- pour construire un immeuble, on prend un architecte diplômé, avec une spécialisation en IGH, et pas un môme de 8 ans, aussi doué soit-il avec ses légos...
Ma super question de la mort qui tue :
Alors pourquoi par tous les saints du ciel continue-t-on à prendre n'importe qui (et pas des informaticiens diplômés et spécialisés) pour faire de l'informatique ?????????????????
Il fut un temps où le développement d'application était confié à des analystes-programmeurs (et pas à un chef de projet ingénieur spécialisation 3ème année en finance internationale), car de façon étrange et amusante... C'EST LEUR METIER !!!!!
Il fut un temps où on apprenait aux programmeurs une règle simple : "Un ordinateur c'est comme les chiottes, on est prié de le laisser en sortant dans le même état qu'on les a trouvés en entrant". Ca va paraître vieux jeu, mais ça met à l'abri des "fuites mémoires".
Maintenant, n'importe quel guignol qui sort d'une pseudo école d'ingénieur en informatique (mais avec option Finance en 3ème année) voire d'une sup de co et qui a pondu 3 lignes de code en C++, un petit serveur en PHP et 2 requêtes SQL sur un pseudo projet se retrouve bombardé "Développeur". Le mieux, c'est qu'au bout d'un an, on le nomme très officiellement "Sénior" sur son périmètre.
Après les DSI s'interrogent sur la source des "incidents de production" et lancent des grands chantiers de "stabilisation de la production".
Georges Clemenceau avait si mes souvenirs sont bons déclaré : "La guerre est une chose trop sérieuse pour qu'on la confie à des militaires".
Je vous en propose une autre : "L'informatique est une chose sufisamment sérieuse pour qu'on la confie à des informaticiens." Celle là est de moi.
Un vieux dinosaure... de 45 ans...
Salut!
Oui et non, selon les cas. S'il s'agit d'un projet purement informatique, tu as certainement raison. En revanche, ayant travaillé de nombreuses années dans l'industrie, j'ai constaté que lorsqu'on devait faire du calcul numérique (par exemple calculer la répartition du champ magnétique dans un four d'électrolyse pour la production d'aluminium), les purs informaticiens étaient inutilisable parce qu'ils ne connaissaient rien d'autre que l'informatique."L'informatique est une chose suffisamment sérieuse pour qu'on la confie à des informaticiens."
Je ne nie donc pas l'importance des purs informaticiens, mais je crois qu'on doit parallèlement former des ingénieurs généralistes qui doivent connaître à fond
- les mathématiques,
- le calcul numérique,
- la physique,
- la programmation.
Un encore plus vieux dinosaure... de 71 ans...
Houla respect !
D'où la création de tout un pan de métiers que l'on appelle MOA (Maîtrise d'ouvrage), censée faire la transformation de connaissances "Client" en connaissances "Maitrise d'oeuvre".
Je pense plutôt qu'il faut former des vrais ingénieurs (dans le sens génie pour "création") et laisser les choses trop spécialisées aux spécialistes (mathématiciens et physiciens entre autres).
Ces fameux ingénieurs généralistes sont pour moi la MOA, qui doit être TOTALEMENT distincte de la MOE afin d'éviter tout conflit d'intérêt. Par ailleurs, il n'est pas besoin que ces personnes connaissent la programmation, qui est du resort d'une partie de la MOE (programmeurs puis dactylocodeurs pour reprendre les termes du siècle dernier) mais qu'ils sachent faire la liaison. C'est la raison pour laquelle le métier de MOA est si précieux et si difficile : il faut garder u oeil sur le fonctionnel et un autre sur le technique. D'où certains maux de crâne...
Encore une fois, modéliser un principe de calcul ou de fonctionnement, c'est de la connaissance technique et de l'intelligence. Programmer en langage informatique c'est de la "traduction". Entre les deux, il y a l'analyse, qui va conceptualiser via un MCD et un MCT ce qui aboutira à un algorithme (analyse) qui sera lui même traduit en code (programmation). Ce qui fait qu'on n'a pas besoin d'un ingénieur pour pondre du code (ce qu'un enfant de 15 ans sait parfaitement faire puisqu'à 15 ans je programmais ma TI57, puis 59, puis un Logabax en turbo Pascal, et je ne suis pas poru autant Le génie de la Création...) mais d'un simple BEP ce qui est amplement suffisant.
Eh oui, malheureusement tout le monde ne peut pas être ingénieur, il faut aussi des petites mains (sans aucune connotation péjorative) pour faire le travail. Comme ça les ingénieurs peuvent se consacrer à leur travail : la conception. Et comme ça, tout le monde a un travail au niveau de ses capacités et qui lui convient. Mais bon comme maintenant il faut 90% de bacheliers, et tout le monde en fac ou en école d'ingénieurs... Statistiquement l'intelligence d'une population comme la France doit fatalement suivre une Gaussienne, avec quelques "boulet", quelques "khadors" et le reste (90%) de moyen (moyes-, moyens moyens et moyens +). J'y peux rien, c'est la nature...
Parcequ'on ne sait pas encore correctement former et/ou detecter des informaticiens.
Je n'ai pas de diplôme d'informatique. Sans être le meilleur(je n'arrive pas à la cheville de mon beau-frère, et de quelques autres que j'ai croisé au cours de ma carrière), je suis largement supérieur à bien des "informaticiens diplômés et spécialisés" que j'ai croisés. C'est sans doute prétentieux, mais vu les commentaires de certains sur les qualités de certains diplômés, ça parait probable, non?
Il fut un temps ou la programmation était laissée soit à des ingénieurs un peu aventureux, soit à des secrétaires qui avaient envie de progresser. Dans les deux catégories, on a trouvé des gens très capables, et un gros paquet d'incapables. A peu près autant qu'il en sort des écoles d'informatique modernes.
La programmation est un métier créatif, jeune, et on ne sait pas former des informaticiens. On ne sait que donner des outils qu peuvent servir. Charge au diplomé de trouver comment s'en servir. Ce n'est pas de la résistance des matériaux, pour laquelle il suffit de savoir faire le calcul qui va bien. Non, nous devons en permanence intuiter de nouvelles solutions.
Quand à selectionner les gens : la discrimination sur l'intelligence ne marche pas. Sur les mathématiques non plus. Sur l'algo non plus. Parceque des génies, super-matheux, experts ès-algo, et infoutus de lire du code, nous en avons tous croisé(et c'est une croix très lourde à porter que de les croiser). Sur la créativité, on trouve des potentiels, mais qui souvent manquent de la rigueur nécéssaire.
Après, pour ce qui est de la "stabilisation de la production", bien d'accord : on applique des méthodes de l'ingéniérie de production(répétitifs, par exemple une fabrication de stylo) à ce qui est une ingéniérie de conception(le code étant un document de conception, au même titre que la gamme de fabrication d'un stylo). Ca ne peut pas marcher.
Moi je perciste a dire qu'on doit s'avoir reinventer la roue (meme si on le fait pas) et c'est tout.
si on forcait l'etude plus pousse de l'architecture des ordinateurs, approfondisait l'etude des syteme d'exploitation au etudiant avec meme TD creation de kernel vous verez que le nombre d'inscrit en informatique avoisinerai celui de la fac me physique quantique.
on va me dire :Oui mais on a pas besoin de savoir comment marche la voiture pour la conduite.
ma reponse est simple l'utilisateur facebook c'est celui qui conduit sa voiture(ordinateur)
le programmeur lui ne l'est pas.
on va me dire :Oui mais les frameworks c'est surtout pour la productivite, en entreprise tu na pas le temps de ...
et je reponds voila pourquoi le monde va mal, tout est fait pour l'entreprise, tout est fait pour aller plus vite et encore plus vite,
Je pense que parfois il faut s'arreter et se demander juste une chose. Pourquoi je suis presser? pourquoi je prends pas le temps de vivre? j'ai telement de chose a voir en route pourquoi toujours chercher des racourcis?
En tout cas moi je me bas pour reduire mon rythme de vie, et chaque fois que je peux je prends tout mon temps pour faire ce que je dois faire.
Réponse évidente.
Répondre à court terme à une "pénurie" de développeur. Je n'hésiterai pas à ajouter qu'il s'agit surtout de faire pression sur les développeurs déjà sur le marché.
Quant à la suite concernant l'intelligence de l'ingénieur auquel serait réserver la partie conception et celle du technicien moins bien lotis qui devrait se contenter de serrer un boulon dans la chaine de montage qu'est un projet informatique c'est une vision des choses simpliste facile à démonter.
Mais je ne le ferai pas ici pour ne pas faire de hors sujet.
Tout à fait d'accord avec une nuance peut être : forme-t-on encore de vrais informaticiens ? De vrais analystes ? de vrais programmeurs ? Je pense que la pénurie est surtout due au fait que tout le monde veut faire des études supérieures, et ça nous prive de toute une frange de population pourtant utile...
Je vais quand même faire une petite précision : dans une société génétiquement non-modifiée, la population se répartit naturellement suivant une vourve de Gauss sur beaucoup de paramètres. Et les métiers aussi : on a besoin de quelques créateurs, et de beaucoup de personnes qui font la réalisation. Regardez un film : 1 réalisateur, 2 producteurs, 10 acteurs, 200 figurants et 3000 techniciens derrière. J'ai autant de respect pour les techniciens que pour l'acteur (peut être même plus d'ailleurs), mais il n'empêche qu'on ne voit JAMAIS un film avec 3000 acteurs et 10 techniciens.
Il faudrait que chacun se rende compte que de toute façons, qunad nous sortirons 80% d'ingénieurs sur ue classe d'âge, ben faudra quand même quelqu'un pour tenir le balais. Et franchement, 5 ans d'études pour ça...
On se retrouve avec de personnes aigries parce que "tu comprends j'ai aps fait 5 ans d'études après le bac pour pisser du code". Ben justemetn fallait pas. Fallait faire u bon bac pro par exemple. Ah ben non on peut plus, l'éducation nationale veut que tout le monde aie un bac + un DUT + une maîtrise + un doctorat...
Je ne vais pas me faire que des amis en disant cela mais c'est d'avantage lié au système.
Il faut composer avec ceux qui font ce métier que pour manger et des clients tout puissant. La parole d'expert ne pèse pas grand quand il suffit de frapper à la porte d’à coté entendre ce dont on a envie. Il ne faut pas raisonner en terme de qualité mais en terme de rentabilité.
Tout le monde veut faire des études parce tels sont les exigences des clients/employeurs et sans boulot tu ne manges pas.
Ce qui me désole c'est que l'on assiste à ce changement de paradigme, notamment pour les études universitaires. Il ne s'agit plus de transmettre et d'élaborer le savoir dans tel domaine mais d'y avoir une formation qualifiante pour utiliser tel framework ou telle techno.
Il y a beaucoup à perdre dans cette transition...
Niveau éthique, ce qu'il faut comprendre c'est que quelqu'un qui est payé pour poser son cul sur une chaise et réfléchir aura forcément plus d'idées que quelqu'un payé pour transporter des sacs.
C'est une question de bon sens et d'humilité.
L'intelligence est une chose trop complexe pour être représenté par une simple courbe. Par exemple en IA, on apprend qu'un réseau avec beaucoup de neurone retient plus de choses mais réseau avec moins de neurone synthétisera mieux (je simplifie outrageusement).
Je préfère raisonner en terme d'efficience par type de tache sans relation directe avec les capacités en calcul mental.
Je préfère avoir dans un équipe un développeur bon en calcul mental et un autre développeur bon en géométrie dans l'espace que deux développeurs bon en calcul mental au sommet d'une Gaussienne statistique.
Je n'ai rien à priori contre un développeur avec un cv balayeur parce que je ne préjuge pas de ce que son expérience peu m'apporter. Il passera le même examen que tout les autres et si il n'est pas pris mais qu'il s'avère passionné je l'encouragerai à persévérer dans sa voie.
La passion est le moteur essentiel. De ce moteur découle la volonté de s'améliorer.
Sinon d'accord qu'il faut conservé une structure globalement pyramidale dans toute organisation. L'erreur est de croire que celui qui est en haut est plus malin que ceux à la base. Celui du haut administre ceux à la base exécutent. Ce n'est pas le même métier.
De mon point de vue un administrateur qui ne consulte pas régulièrement sa base ne peut être un bon administrateur. Question de gestion active...
Ca t'en fait déjà un : moi
Exact et désolant !
Pas forcément. Celui qui transporte les sacs sait comment ça se fait et est souvent bien placé pour penser à des améliorations. Mais comme il n'est que "Transporteur de sacs..."
D'accord, quand la personne en question a une certaine expérience, pas un jeunot frais émoulu d'une SUP de CO. Ou alors avec un "examen" masi là on passe poru un fasciste...
Effectivement tu vas pas te faire que des amis...
Houla je viens de me relire et je me suis pas compris de suite ...
Par administrateur je pensais gestionnaire en ressources humaine (le 'chef' quoi) et par base je pensais exécutant (les devs, mais aussi les admins).
Mots mal choisis, déformation professionnel je suppose.
je viens de lire cet article ce matin et ce surtout sa conclusion:et je vais la paraphraser pour les developpeurs en disant:
Code : Sélectionner tout - Visualiser dans une fenêtre à part on ne profite vraiment du numérique que quand on a formé son esprit sans lui.
ainsi sachant vraiment ce que ca coute d'en faire, on prend plus de plaisir et surout on comprend mieux quand et comment les utiliser.
Code : Sélectionner tout - Visualiser dans une fenêtre à part on ne profite vraiment des libs que quand on a formé son esprit sans elles.
L'article est effectivement fabuleux, et dénote chez ce professeur un grand sens de l'humour, et surtout un amour sans limite de son métier : professer. Que de noblesse.
Internet semble être partout. Autrefois, je puisais dans les livres et à la bibliothèque. Maintenant on fait du copier-coller. Toute une époque...
Je me dois de nuancer. Pour moi, le copier-coller numérique est à peine pire que le recopiage d'un passage dans un livre, ou de la dissertation d'un(e) ami(e).
Pire, c'est vrai. Car d'une part, l'effort de recopiage manuel impose une plus grande mémorisation. Car aussi, l'accès aux livres est plus limité, les bibliothèques (contrairement à Internet) ne proposent pas des exemplaires illimités que tout le monde peut consulter en même temps, le recopiage devient donc plus aisé avec le numérique.
Mais à peine pire, car la mémorisation de quelque chose recopié à la va-vite pour satisfaire le professeur et l'école, ne sera pas une mémorisation durable. Si on n'arrive pas à intéresser l'élève, de toute façons la cause est perdue.
Surtout, je pense que l'auteur de l'article a negligé une conclusion pourtant importante: en piègeant ses élèves, il leur a enseigné une précieuse leçon d'esprit critique. Sans doute aurait-t-il pu faire de même sans Internet, mais cela lui a facilité la tâche.
De plus, je suis pas sûr qu'il ait raison de mettre le numérique ainsi à part. Lire en diagonale, recopier les passages qui semblent vaguement pertinent, c'est une méthodologie moisie qui, me semble-t-il, peut s'appliquer à n'importe quel texte.
Je ne partage donc pas vraiment sa conclusion, mais je salue son initiative. D'autres profs devraient faire comme lui!
P.S. concernant la conclusion de Lilington par contre, je suis d'accord. Avant de réutiliser le travail d'autrui, il faut le comprendre.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager