Forum Programmation.autre Rôle du développeur et son "cœur de métier"

Posté par GG (site web personnel) le 31 octobre 2013 à 08:50. Licence CC By‑SA.

Étiquettes : aucune

oct.

2013

Bonjour,

j'ai un ami qui est développeur. Il a suivi des formations, et a quelques années d'expériences.

Lorsque je lui parle d'adapter un logiciel à un besoin, il dit que c'est de la bidouille, que ce n'est pas propre.
Il préfère tout coder "from scratch" pour coller au plus près des besoins du client et de son métier (celui du client).

Quand je lui parle de logiciels libres, dont on peut lire le code pour voir quelles ont été les problèmes auxquels les auteurs ont du faire face (on peut parfois le lire dans les commentaires accompagnant le code), il dit que lire le code de quelqu'un d'autre c'est chiant, et que jamais il n'a entendu ça dans ses formations et son entourage. Pour lui, personne ne relit le code.

Il précise en outre que son "cœur de métier", celui de développeur, c'est de penser à l'architecture, puis de coder. Au grand jamais d'adapter ou d'adapter un logiciel "tout fait".

Qu'en pensez-vous?
Qu'est ce que vous auriez comme arguments pour contrer ça?

Dans mon entourage, c'est tout l'inverse, mais c'est une question de culture. On apprends beaucoup à lire du code source, rien qu'avec les commentaires.

Merci
G

# la différence entre les vrais et les faux

Posté par mouvda le 31 octobre 2013 à 09:25. Évalué à 4.

Bonjour,

Je préfère prévenir : mes propos ci-après n'engagent personne sauf moi.

J'ai rencontré pas mal ce genre de caricatures de "développeurs" du temps béni ou j’étais programmeur. Caricatures car un développeur dit observer, analyser, concevoir et enfin développer.
Il est vrai que développer "from scratch" est plus sympa et moins exigeant intellectuellement
Les SSII font de la maintenance ou de l’évolution d'applications et une refonte complète du code demanderait pas mal de temps et de moyens. D'où des contraintes techniques.
Si le développeur ne veut ou ne peut s'y adapter, alors il devrait changer de job.

PS: J'ai arrêté la prog devant le fout*ge de tête des clients et des utilisateurs finaux : la rentabilité est normale, le travail bâclé et/ou la surfacturation est insupportable.

tant va la cruche à l'eau qu'à la fin elle t'explose en pleine tête
- [^] # Re: la différence entre les vrais et les faux
  
  Posté par Anonyme le 31 octobre 2013 à 15:51. Évalué à 1.
  
  a propos de surfacturation, compilé/porter 2 lib sous win 7, exemple précis et vécu : zlib et libssl ca peut couter 10k€ ?
  
  merci de vos remarque
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 31 octobre 2013 à 22:25. Évalué à 2.
    
    Ce commentaire a été supprimé par l’équipe de modération.
# analogie foireuse

Posté par Adrien le 31 octobre 2013 à 09:31. Évalué à 5.

Lorsque je lui parle d'adapter un logiciel à un besoin, il dit que c'est de la bidouille, que ce n'est pas propre.

recoder 10 fois la même chose c'est propre ? Mieux vaux faire sa propre implémentation nouvelle (et forcément buggée) que d'utiliser des briques stables, bien testées ?

Il précise en outre que son "cœur de métier", celui de développeur, c'est de penser à l'architecture, puis de coder. Au grand jamais d'adapter ou d'adapter un logiciel "tout fait".

Et le cœur de métier d'un maçon c'est de faire des maisons neuves, pas de faire de la restauration/adaptation ??

Attention, je ne suis pas développeur.
- [^] # Re: analogie foireuse
  
  Posté par mouvda le 31 octobre 2013 à 09:50. Évalué à 0.
  
  Affirmatif :
  
  pourquoi ont été créé les langages orientés objets…
  
  tant va la cruche à l'eau qu'à la fin elle t'explose en pleine tête
# Bug confirmé

Posté par Nerdiland de Fesseps le 31 octobre 2013 à 09:57. Évalué à 6.

D'après ce portrait j'ai l'impression que ton ami est plutôt arrogant, du style de développeur gourou auto-proclamé dont on voit passer le code sur des sites comme thedailywtf. Je pense que c'est nocif pour lui, pour ceux avec qui il travaille, et pour ses clients.

Il a l'air d'être un puriste qui aime le code bien fait, c'est une qualité. Sauf quand c'est poussé à l'extrême et que l'on n'accepte que son propre code qui suit sa propre définition de beau code (et qui n'est pas forcément la définition qu'ont les autres).

A mon sens personne ne sait tout mieux que tout le monde et il y a toujours à apprendre de ses pairs, surtout dans un champ qui évolue rapidement comme la programmation. S'appuyer et s'inspirer du travail des autres, c'est à la fois gagner du temps et progresser personnellement. Et c'est valable dans tous les domaines.

J'ai du mal à croire que quelqu'un puisse maîtriser parfaitement tous les aspects d'une application complexe au point de pouvoir tout écrire from scratch de manière tellement robuste qu'elle ne contienne aucun des bugs et failles corrigés par les projets existants au cours de leur histoire.

Coder from scratch se rapproche pour moi plus de la bidouille et de l'exercice que du métier de développeur. Forcément le métier de développeur comporte des contraintes, il demande à faire des compromis, à travailler avec du code pas toujours conforme à ses standards d'élégance, à coder avec d'autres développeurs qui n'ont pas la même vision des choses, à lire et relire du code, à respecter des délais et des budgets.

Comme dans tous les autres domaines la pureté n'existe pas, mais je pense que le meilleur moyen de pousser les choses vers l'avant est de créer et partager du code de qualité qui peut être réutilisé facilement. Et qu'il n'est pas possible de produire du code de qualité sans lire, s'inspirer et réutiliser le code des autres. Il serait dommage de ne pas accepter les inévitables contraintes au nom d'une vision personnelle et puriste.
# ça dépend

Posté par Krunch (site web personnel) le 31 octobre 2013 à 10:36. Évalué à 4.

Je connais des gens très bien qui ont cette approche et dans certains cas ça a du sens. Si tu dois concevoir un système « entier » relativement monolithique qui n'a pas vraiment à s'intégrer avec autre chose, ça me semble pas une mauvaise idée de tout faire from scratch. Cependant, dès que tu dois avoir un minimum de compatibilité ou intégration, il est souvent préférable de repartir de quelque chose d'existant.

Il semble effectivement que beaucoup de développeurs préfèrent écrire du nouveau code plutôt que de maintenir/modifier du code existant mais je pense que c'est généralement parce que la vaste majorité du code existant est passablement pourri. Du coup, écrire encore plus de code pourri n'aide pas vraiment non plus.

Je pense que lire du code tiers est assez important pour se faire une idée de ce qu'est du code {in,}{maintenable,compréhensible} et apprendre des {erreurs,succès} des autres. Mais effectivement, c'est souvent plus difficile que d'écrire un truc from scratch.

Voire aussi : http://en.wikipedia.org/wiki/Code_smell

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# probleme de temps/argent

Posté par NeoX le 31 octobre 2013 à 10:50. Évalué à 2.
combien de temps va passer ton ami à chercher ou il doit modifier l'outil et tester qu'il na pas introduit un peu plus loin quelques part dans un process
par rapport à combien de temps il va passer à recoder de lui meme l'outil en entier.

sur certains outils un peu complexe, la question peut se poser.
ici on a eu un outil avec un framework maison, recuperer d'un vieux projet, etc
bah reprendre le code est une vraie plaie,

pour tout dire, c'est du php, qui genere des pages html et qui plutot que de faire un "simple"
```
echo "<table><tr><td>...</td></tr></table>";
```
va faire un
```
open_table(1line,2col);
create_line(xxxx);
create_col(yyy);
create_col(zzz);
end_line();
end_table();
```
idem evidemment pour creer un formulaire, etc

du coup rependre le code ou refaire de zero, quand on a du refaire un site faisant un truc similaire,
on s'est bien posé la question
# des fois la taille ça compte…

Posté par matthieu bollot (site web personnel, Mastodon) le 31 octobre 2013 à 10:58. Évalué à 3.
```
il dit que lire le code de quelqu'un d'autre c'est chiant, et que jamais il n'a entendu ça dans ses formations et son entourage. Pour lui, personne ne relit le code.
```
Oui c'est chiant, mais beaucoup de personnes le font. Déjà il y a des personnes qui lisent plus ou moins chaque patch pour voir si il n'y a pas eu une régression fonctionnelle grossière ou une faille potentielle de créée, mais aussi pour les "bonnes pratiques" qui permettent de progresser (quand on se prend une remarque deux/trois fois ça commence à rentrer) Pour ces cas je pensais plus à des logiciels libre, mais même au travail, quand on a des stagiaires on fait de la relecture de code une fois par semaine avec eux, ça dure 1h mais c'est bien pour tout le monde.

Après, pour savoir si c'est mieux d'adapter ou de tout recréer… ça dépend de la distance entre le code existant et le nouveau code. En général plus le projet est petit et mieux c'est de tout recréer.

Bref, pour des petits projets de merde tout seul : on fait ce qu'on aime et donc on recrée un maximum de choses, pour tout le reste on reprend du code existant.
# troll

Posté par kna le 31 octobre 2013 à 19:55. Évalué à 1.

Si c'est codé en perl, il vaut mieux recommencer from scratch
Si c'est codé en python, il vaut mieux adapter le code existant

Je ne suis plus là -->[]
- [^] # Re: troll
  
  Posté par Framasky (site web personnel) le 01 novembre 2013 à 16:39. Évalué à 4.
  
  Si c'est codé en perl, il vaut mieux recommencer from scratch
  
  Toi aussi tu reportes le trolldi à la veille quand vendredi est férié ?
  
  Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# Tout dépend de ce que l'on appelle "from scratch"

Posté par totof2000 le 31 octobre 2013 à 21:49. Évalué à 3.

Pour certains, "from scratch", c'est juste prendre un framework, et dériver quelques classes déjà toutes faites pour répondre au besoin métier. De plus il est très rare que le code et les commentaires te donnent une idée précise de l'architecture logicielle. Donc dans certains cas, tout recoder peut se justifier.

Maintenant, comme dit plus haut, tout dépend de ou on part et des outils que l'on a. Et si le "développeur" n'a appris dans sa formation qu'à utiliser un framework, dans ce cas je comprends sa réponse.
# Commentaire supprimé

Posté par Anonyme le 31 octobre 2013 à 22:58. Évalué à 5.

Ce commentaire a été supprimé par l’équipe de modération.
# architecte et développeur

Posté par Sébastien Maccagnoni (site web personnel) le 02 novembre 2013 à 12:34. Évalué à 2.

Il précise en outre que son "cœur de métier", celui de développeur, c'est de penser à l'architecture, puis de coder. Au grand jamais d'adapter ou d'adapter un logiciel "tout fait".

Celui qui pense à l'architecture, c'est l'architecte.
Celui qui code, c'est le développeur.

Et ça dépend ce qu'il appelle "adapter" un logiciel tout fait. Enfin bon, les cas où on choisit entre développer quelque chose de nouveau ou réutiliser quelque chose d'existant, ça a assez été détaillé ci-dessus :)

J'espère juste qu'il ne fait pas du "from scratch" à 100% : il y a des milliers de bibliothèques qui répondent à des milliers de problématiques, il faut au maximum utiliser ces bibliothèques.
- [^] # Re: architecte et développeur
  
  Posté par Framasky (site web personnel) le 03 novembre 2013 à 20:04. Évalué à 4.
  
  J'espère juste qu'il ne fait pas du "from scratch" à 100% : il y a des milliers de bibliothèques qui répondent à des milliers de problématiques, il faut au maximum utiliser ces bibliothèques.
  
  Ouais, parce que recoder un parseur XML sous prétexte qu'il préfère tout maîtriser plutôt que d'utiliser libxml, bon, hein :)
  
  Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
  - [^] # Re: architecte et développeur
    
    Posté par claudex le 03 novembre 2013 à 20:59. Évalué à 4.
    
    Tu oublie le recodage du compilateur.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.