PERL n'est plus au goût du jour pour grand monde...
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
PERL n'est plus au goût du jour pour grand monde...
c'est le problème de la PERL rare ?Envoyé par pussin
Bonjour,
je me classerais dans les perfectionnistes, au grand malheur de mes patrons mais au très grand bonheur des utilisateurs finaux et des collègues qui doivent reprendre le code quand une évolution est demandée.
Pour moi, un vrai programme doit répondre à 3 critères :
- Il doit être efficace (donc tenir compte de tous les cas, et pour en être certain, il doit être dynamiquement configurable)
- Il doit être beau dehors (que le développeur qui n'est pas aussi infographiste reste sur sa VT100 dans un musée), mais attention cependant, les goûts et les couleurs ...
- Il doit être beau dedans et élégant (du style 10 instructions en une seule ligne magique, à condition que tous soit bien expliqué en commentaires. Un code sans commentaires n'est pas du code, juste de la bouillie). Sans cela, autant se contenter de générateurs automatiques comme le RAD WinDev.
Mais le plus important, ce n'est pas le programme lui même, qui n'est qu'un résultat, mais l'analyse ! Une bonne analyse fait gagner énormément de temps ensuite et permet de répondre aux 3 critères (2 surtout !)
En conclusion, je dirais qu'un développeur doit être un analyste, un peu infographiste, passionné par son métier, et en constante évolution. (On n'en sait jamais assez, et tout va tellement vite dans notre domaine !!!)
Perso, je trouve l'analyse de Depite pertinente et je me retrouve assez bien dans son approche...
Bonjour pussin, pour les développeurs PERL. Regarder sur les forums et salons des linuxiens (GNU/linux ou BSD/GUN) et aussi du côté mac. Beaucoup d'utilisateur développe en autodidacte et peuvent avoir appris à développer en PERL. Je n'ai rien promis, c'est juste une suggestion. Bonne continuation.
Beaucoup de mal à relier cette intervention avec le reste du fil
Franchement, 10 instructions sur une seul ligne, je trouve pas ça "élégant".
Tu y gagnes quoi ? Une économie de 10 lignes ?
Déjà que les conditions ternaires c'est imbuvable, alors j'imagine même pas ce que cela donne avec 10 instructions !
En ce qui concerne les commentaires, on m'a déjà dit qu'un code doit pouvoir être compris sans commentaires. Mais pour cela, cela passe par :
- Un code lisible et claire
- Des noms de variables et de fonctions qui veulent dire quelque chose.
Les commentaires servent juste à préciser des choses ou expliquer un bout de code relativement compliqué, selon moi.
Après, en tant que développeur, je préfère me concentrer sur le code et les fonctionnalités du programmes que sur le design. Autant déléguer cette tâche à une personne qui est dans ce domaine.
hum ...
cette categorization c'est quand meme carrement moisit quand meme.
bon cela dit ya un truc qui m'a fait chiffonne.
Je trouve que les programmes sont de plus en plus lourds, il faut des machines de plus en plus puissantes pour faire tourner des programmes qui au fond ne devrait pas l'etre, ca bouffe de plus en plus de memoire etc...
ya quand meme un probleme avec ca. je me demande si on pourrait pas faire une evaluation d'un bon programme comme en etant peu consomateur de ressource materiel, du genre vous etes un bon programmeur car grace a vos programme pas besoins de changer de materiel, on les appeleraient les GREEN PROGRAMMEUR , hehe
bref, ecrire un programme de maniere lourde (consommatrice) ca a quand meme des concequences social, he oui il faut le fabriquer les ordinateurs , et qui les fabrique ? dans quel conditions ? alors franchement l'elegance, la clartee, la propretee, l'evolutivitee, la rapiditee etc ... franchement ca devrait pas etre notre premier souci ..
desole pour mes fautes d'orthographes... (je deteste ces mecs qui se prennent pour des dieux et qui ont la veritee infusent et qui croit que le monde tourne autour d'eux. dailleur je deteste se moyen d'expression : les blogs, genre "j'ai envie de parler de moi sur internet" ... )
bon j'arrette , je part en couilles ...
Je dirai même plus, pourquoi 4 ? Pourquoi 2 ou 6 ?
C'est peut-être aussi les 2, et même les 3 ou 4 en même temps.
Donc la 1ère, c'est les soumis, et la 2ème, c'est ceux qui ont aussi une vie à côté ^^
Ecrire des programmes optimisés pose pas mal de problèmes :
- cela demande du temps, et on devient facilement hors délai
- cela rend le programme parfois difficilement évolutif
- même avec un code suffisamment documenté et commenté, beaucoup de programmeurs ne comprennent pas les optimisations réalisées (et comme on veut de plus en plus de programmeurs impersonnels et échangeables, cela n'aide pas)
- l'utilisateur final ne comprend pas l'intérêt (donc l'optimisation est quelque chose qu'on peut difficilement lui faire payer)
Face à un code optimisé mais à peine trop obscur pour le développeur moyen, la réaction typique c'est : "bon, ça marche, on ne sais pas comment, alors on va essayer de toucher le moins possible".
Concernant la montée en puissance, je ne suis pas forcément d'accord non plus :
Parfois, une optimisation consiste justement à utiliser plus de mémoire (ex: caching) et/ou de données (ex: dénormalisation de bases de données) pour diminuer la consommation de ressources CPU.
Et pour ce qui est d'éviter de changer de matériel, j'ai plusieurs PC pas si vieux que ça qui ne valent même plus la peine d'être allumés. Pourquoi ? Parce que n'importe quel PC bas de gamme à base de processeur Intel Atom a un bien meilleur rendement énergétique.
Dans le même ordre d'idée, les processeurs modernes sont de véritables monstres de puissance lorsque poussés à pleine capacité (pour faire face à la montée en charge), mais au repos ils ne consomment pas tant que ça. Certains sont permettent même de désactiver la carte graphique du PC au repos pour utiliser le processeur graphique intégré au CPU (Switchable Graphics).
Donc le changement de matériel pour une informatique plus "green" n'est pas forcément une mauvaise chose.
Slt pcaboche,
A t'entendre, tu pestes l'optimisation. On pourrait croire que tu es de ceux qui ont participé au dev de vista. On connait bien la réussite financière de ce projet!
J'imagine qu'il en ai rien et que tes demandes actuelles ne permettent pas d'assurer cette contrainte.
Sur mes 15 ans d'expériences, j'ai participé a différent type de projet avec différent besoin.
Quand tu manages une équipe de prod, tu comprends mieux les contraintes de qualité et de temps en fonction du besoin.
Nous pouvons débattre ce que c'est du bon code, mais le bon dév ne doit pas ce faire uniquement sur le contenue de son code.
ni sur la qualité, sur le respect des délais et des performances.
Voici ce qui me semble caractériser un bon développeur.
C'est une personne qui creuse, autodidacte et ce remet toujours en cause sur son travail.
Plus concrètement, qu'il soit capable de juger ou doit se trouver le curseur entre ces différents aspects en fonction du besoin.
Le besoin qui se définit en fonction :
- de son risque financier (+/- qualité)
- sur la taille du projet (+/- analysé/architecturé/structuré/organisé)
- sur la volumétrie/fréquence (+/- optimisation/performance) exemple import/webService
- sur la maintenance/évolutive (+/- qualité de coding)
Et surtout... ce qui définie tout le reste (malheureusement mal prix en compte au niveau de formation (scolaire)!)
- sur les délais du projet (+/- qualité/analysé/optimisation/qualité de coding)
Et oui... cela ne sert a rien de faire du super dev qui ne peut tourner que sur un mega serveur à 20000€. Voir même de le livré quand le client n'en a plus besoin!
Inutile aussi de chercher l'optimisation a outrance pour un traitement de 5min une fois pas an! Idem pour l'architecture. Pas de méthode avec 1000 lignes de codes pour une usine a gaz, mais pas non plus avec une architecture avec 100 class de 100 ligne de code pour un script qui ne va tournée qu'une seul fois (c'est fini l'école!)
Pas la peine de perdre du temps pour commenter chaque ligne de code.
Normalement le code doit rester claire.
Donc le commentaire est utile pour expliquer une règle métier, une architecture ou une méthodo pour l'optimisation.
Pas pour réé
Dernière chose, un code optimisé ne veut pas dire plus d'utilisation mémoire, ou moins gourmand en CPU.
Juste qu'il est adapté aux ressources (Fx autres process/CPU/Ram/IO disque et réseau) en fonction des contraintes du besoin (volume/fréquence).
Ex : plus rapide en volume en apportant juste une approche différentes (ex, raisonnement de masse au lieu de séquentiel).
Mieux vaut un trn qui consomme 10fois plus sur 100 fois moins de temps!
Et c'est plus green!
Pour finir et pour apprendre à devenir un bon développeur, il suffit de mener ses propres projets perso.
Ce qui permet d'apprendre à mieux mesurer les contraintes!
Après, il faut accepter qu'il y a dans ce monde des génies et que tout le monde n'est pas de même niveau.
Parmi les génies, il y a même des artistes!
Je rêve qu'un jour, les métiers de l'informatique soient aussi bien cloisonné que les métiers du bâtiment!
Il y a plusieurs types de développeur comme il y a plusieurs métiers de bâtisseurs.
Dev PHP sur sympony // Charpentier spécialiste pour les églises
- Est-ce qu'on demande à un charpentier d'être capable de monter une église?
Chef de projet // Contremaitre
- Vous avez déjà vue un contremaitre qui ne va jamais sur un chantier?
Architecte//Architecte
- tien... le même nom! pourtant on en trouve pas beaucoup dans les boites!
Il y a même de la phylo dans l'info!
En quoi le fait d'être autodidacte préjuge d'être un bon développeur ? Les écoles d'informatique ne serviraient donc à rien et seraient inutile ?
Et c'est un autodidacte qui te pose la question
J'ai pas tout compris de ce que tu voulais exprimer, là, mais la qualité du produit, l'analyse, la qualité du code (pour la maintenance et l'évolutivité) devraient toujours être exigées à leur plus haut niveau, sans compromis et quelque soit le projet.Le besoin qui se définit en fonction :
- de son risque financier (+/- qualité)
- sur la taille du projet (+/- analysé/architecturé/structuré/organisé)
- sur la volumétrie/fréquence (+/- optimisation/performance) exemple import/webService
- sur la maintenance/évolutive (+/- qualité de coding)
Et surtout... ce qui définie tout le reste (malheureusement mal prix en compte au niveau de formation (scolaire)!)
- sur les délais du projet (+/- qualité/analysé/optimisation/qualité de coding)
Les génies sont très rares, dans ce métier comme dans tous. Il ne se lève pas un Steve Jobs tous les jours (même si son coté génie n'est pas forcément reconnu par tous). Beaucoup de ceux désignés rapidement comme des génies sont plus des opportunistes qu'autre chose.Après, il faut accepter qu'il y a dans ce monde des génies et que tout le monde n'est pas de même niveau.
Parmi les génies, il y a même des artistes!
Perso, la construction d'une église, je l'a confierais plus à un maçon qu'à un charpentier.Dev PHP sur sympony // Charpentier spécialiste pour les églises
- Est-ce qu'on demande à un charpentier d'être capable de monter une église?
Chef de projet // Contremaitre
- Vous avez déjà vue un contremaitre qui ne va jamais sur un chantier?
Architecte//Architecte
- tien... le même nom! pourtant on en trouve pas beaucoup dans les boites!
Et je te confirme qu'il y a des contremaitres qui ne vont jamais, ou trop rarement sur les chantiers (seulement pour le lancement et la recette par exemple)
Et si je peut me permettre une remarque, je sais pas si tu es bon développeur, mais niveau orthographe, il y a encore des progrès possibles
J'ai envie de dire: oui si on te paie pour ça. Il est vrai qu'il faut toujours s'efforcer à bosser dans les règles de l'art, mais seulement il faut parfois se limiter à la qualité possible dans le temps imparti.
En cas de retard, il est souvent préférable pour le client d'avoir les fonctionnalités même s'il y a quelques "loups" techniques que de rien avoir du tout. Si on exige systématiquement de toi la qualité la plus haute, forcément on devra aussi t'accorder les délais les plus longs.
Mener un projet c'est un peu une négociation permanente entre le temps (comprenez le *coût*) et le résultat. Après suivant nos compétences on arrive à faire osciller la barre plutôt du côté vert que du côté rouge.
Combien de fois j'aurai souhaité réécrire de façon plus intelligente un code qui me semblait mal pensé. Pourtant il fallait y renoncer car le coût généré en ressources (qui inclut le temps développeur mais aussi la validation et les tests) était trop important. Donc j'accepte l'imperfection dans la mesure où les contraintes sont ce qu'elles sont.
Pour ma part je viole plus ou moins souvent les grands concepts théoriques de développement (3 tiers, design pattern, héritage) et j'estime que lorsque les délais sont tenus et que l'application répond au besoin en restant raisonnablement maintenable, j'ai pas trop mal bossé.
J'ai un vu un tas de projet rencontrer des soucis parce qu'au nom de l'évolutivité et de la maintenabilité on partait dans des designs très ouverts (surabstraction du système de stockage, domain model full OO, design paterns et interfaces à tout va) pour au final se retrouver avec une complexité totalement dingue qui finit par poser les problèmes qu'elle est censée résoudre.
N'a-t-il donc personne pour travailler correctement ?
Et il n'y a pas une catégorie pour les râleurs ne respectant pas les délais, fournissant un code dégueulasse et non fonctionnel?
Pole-emploi ?Et il n'y a pas une catégorie pour les râleurs ne respectant pas les délais, fournissant un code dégueulasse et non fonctionnel?
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.
Répondre avec citation
Partager