Étiquette : code

Publié le

Snippet #24 ~ PHP: Allégez vos classes avec des get/set automatiques | IdleBlog – Liens en vrac de sebsauvage => OUPAH

Astuce php pour éviter d’avoir à se palucher plein de getters/setters pour des classes de stockage.

via Snippet #24 ~ PHP: Allégez vos classes avec des get/set automatiques | IdleBlog – Liens en vrac de sebsauvage.
Ou alors revenir à la raison dans certains cas et ne pas appliquer les concepts de la POO façon recette de cuisine vaseuse sans prendre de recul. Par exemple pour des DTO ça ne sert strictement à rien selon moi de persister à utiliser des getters / setters. Mais alors à rien du tout ! Pire c’est contre productif à tous les niveaux.
Les DTO sont des objets destinés uniquement à stocker de la donnée. Aucune intelligence dedans. Pire, quand on fait du getter / setter dans un DTO on apporte même pas d’API et de stabilité dans les évolutions puisque les getters / setters sont nommés en fonction des données associées et donc le nom de ces méthodes est largement aussi peu stable que les attributs associés… Sans compter les cas ou les valeurs derrière ne sont même pas protégées puisqu’il y a des passages par référence des objets (cas pas assez souvent abordé en java selon moi).
Pire encore en terme de performance ! Utiliser du getter / setter à tarbasse dans certains cas (ici le DTO) est juste une immondice de performance. Ne pas oublier que quand vous concevez une méthode et l’utilisez l’interpréteur / la machine effectue un branchement / débranchement de l’exécution pour faire l’appel (sauf dans certains cas ou des optimisations sont possibles par le compilateur). Or c’est un processus qui prend du temps par rapport a une exécution séquentielle… Imaginez ça multiplié par le nombre de champs et d’enregistrements…
Et das certains cas (dans ce lien) on se retrouve a écrire des systèmes dégeu de génération dynamique des getters / setters, ce qui est largement aussi moche et prend du temps tout ça pour éviter une flemme d’écriture de code.
Bref, ne pas appliquer les recettes de cuisine brutos et prendre du recul est salvateur. Par exemple, dans le cas d’une DTO, arrêtez de continuer avec vos attributs privés et des getters / setters de merde. Passez simplement vos attributs en public ! Vous gagnez en temps d’exécution (accès mémoire only), vous gagnez en lisibilité et maintenance du code (attributs only) et vous ne perdez rien au passage…
Si vous ne me croyez pas je vous cite un bout de doc officielle de la javadoc (mais je pense que c’est applicable d’une manière générale).
http://www.oracle.com/technetwork/java/transferobject-139757.html

Typically, the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods.

Bon après j’ai longtemps fait des getters / setters sur des DTO avant de penser ainsi.
Attention je parle bien de tout cela dans le cadre des objets de données purs, ne pas mélanger mes propos avec des classes définissant une API ou une intelligence métier.

Publié le

Dégage, sale programmeur ! | Codingly

Et ouais, être développeur lorsqu’on a plus de 30 ans en France, c’est pire que d’être caissier à 40 ans. La plupart des gens qui passent 90% de leur temps à programmer vont donc s’arranger pour qu’on les voit comme des ingénieurs d’études, des experts techniques, des chefs de projets, des architectes solution, des consultants, etc. Le top, quand on est un pauvre prestataire d’une SSII en mission pour une banque, et que l’on passe ses journées à coder, c’est de raconter à tout le monde qu’on est INGENIEUR DANS LA FINANCE. Oui oui.

via Dégage, sale programmeur ! | Codingly.
Un autre billet faisant suite à ce billet. Je trouve d’ailleurs que la comparaison avec le « caissier » est assez judicieuse. Je suis cependant agréablement surpris qu’on soit, nous français les principaux idiots capable de penser de telles sottises.
Avec le temps j’en fini par penser que cela peut même expliquer l’échec (même léger) de certains projets informatiques dans les entreprises (petites ou grandes).
En effet, on cantonne le dev aux « débutants » qui sont donc par définitions les moins aptes. Ensuite on veut faire de « développeurs » des chefs de projets ce qu’ils ne sont fondamentalement pas puisque c’est un autre métier.
Pour poursuivre, on ne valorise pas le dev et encore moins le « senior » ce qui aura tendance a le démotiver.
Pour terminer, on ne raisonne binaire avec « dev débutant » et « chef de projet » pour staffer un projet alors qu’il faudrait généralement au moins un lead dev (dev senior ++) voire même un architecte…
Le top c’est quand le CP doit faire office de lead dev (ou comment faire les 2 moins bien). Malheureusement, c’est une chose qui parfois est difficilement évitable compte tenu des collaborateurs disponibles à un instant T et que le client l’attend pour avant hier 🙂
Source.

Publié le

Blog Gauthier Delamarre: Chef de projet, aboutissement de la carrière d'un développeur ?

Quelle aberration ! De ce que j’ai lu dans les commentaires, il semblerait que l’on fourre cette idée saugrenue dans la tête des futurs développeurs dès leur apprentissage… ceci expliquerait cela.

via Blog Gauthier Delamarre: Chef de projet, aboutissement de la carrière d’un développeur ?.
Mais 1 000 fois oui !! Avec l’expérience qui commence à s’accumuler je pense avoir un pu constater ce travers dans l’entreprise où je travaille. Les esprits changent doucement mais il n’empêche que l’évolution salariale est surtout vue comme étant vers le management dont le chef de projet serait la première étape. Force est de constater que ce n’est pas une évolution logique. Pire, on néglige du même coup le concept de lead dev et d’architecte qui sont pour moi fondamentaux.
Source.