Julien Carnelos Blog – Archives

Via VoxinaBlog, je viens de lire que le moteur n°1 de recherche (Google pour ceux qui suivent 😉 ) va effectuer quelques changements sur l’interprétation des URL.

• Le caratère « _ » devient un séparateur

Auparavant, une url de type http://www.example.com/lecteurs_dvd/ était interpreté avec le mot unique « lecteurs_dvd » et non « lecteurs » puis « dvd ».

• Les paramètres Query String sont traités comme faisant partie de l’URL.

http://www.example.com/lecteurs_mp3/ipod/ sera équivalent à http://www.example.com/voir.php?cat=lecteurs_mp3&pdt=ipod

• Le nombre de slash dans l’url n’indique pas la profondeur de l’article et donc du classement.

Intéressant pour les blogs par exemple.

• Les extensions n’influent pas sur l’url

Plus besoin d’avoir forcément une URL qui se termine par « .html ».

Les impacts de ces mesures sur les développements peuvent être conséquents. En effet, c’est aujourd’hui une demande constante de la part des clients d’avoir des URL « jolies » améliorant le référencement. Cela avait pour conséquence de devoir parfois jongler avec des règles d’URL Rewrite relativement complexes.

Exemple: (j’accepte les regexp de résolution en commentaire 🙂 )
http://www.example.com/index.php?cat=media&pdt=dvdrw&paginate=2
en
http://www.example.com/media/dvdrw/2.html
puis inversement.

Désormais, on pourra donc éviter une partie de ces traitements pour des raisons de référencement. Quand on sait que 80% des visites passent par Google, la nouvelle est d’importance.

En revanche, un autre aspect des URL Rewrite est l’aspect joli pour l’oeil humain (par opposition au robot référenceurt google). Dans ce cas, il pourra toujours être intéressant de rechercher à améliorer l’url, mais cela sera moins critique…

Si comme moi, vous pensez que la motivation est le critère numéro un de productivité des développeurs, vous devez alors vous poser la question de savoir comment entretenir cette motivation. L’auto-gratification est un de ces principes psychologiques.

Il s’agit d’adapter son style de développement en mode incrémental. L’idée est de développer bout par bout plutôt que de chercher à réaliser de « grosses » fonctions en one-shot.

Prenons l’exemple d’une fonction « Réaliser une interface de gestion d’utilisateurs avec création/suppression/consultation« .

On peut utiliser deux stratégies : Soit construire chacune des couches (interface, puis métier et enfin données) en mode horizontal, soit construire en vertical chaque sous fonction (d’abord faire toute la consultation, puis la création, etc.)

Et bien le principe de gratification voudrait que l’on utilise la stratégie verticale afin de découper la fonction en petits morceaux réalisables unitairement. Pour la bonne raison que pour chaque sous fonction réalisée, il sera possible de constater que notre bout de code donne un résultat. La voilà notre motivation : voir que notre code fonctionne !

C’est exactement ce que nous encourage à faire le développement orienté par les tests (TDD) : En effet, vous codez un test qui échoue, et vous écrivez le code suffisant qui fait passer le test. A chaque barre verte affichée (le signe que le test passe), c’est une satisfaction de constater que l’on « avance », que le programme se construit et qu’il fonctionne…

Sans vouloir refaire la célèbre maxime du bon développeur et du mauvais développeur, je cite souvent une étude du livre Peopleware qui explique que l’on retrouve un écart de productivté entre développeurs pouvant aller sur un ratio de 1:6.

En clair, un développeur efficace peut aller six fois plus vite qu’un autre. Plusieurs études ont prouvé la réalité de cet écart mais cela reste difficile à admettre et en particulier par les managers.

Hint: Si vous allez voir votre manager demain matin pour négocier une augmentation, ce n’est pas la peine de venir vous plaindre que lui montrer mon post n’a pas marché. 😉

Bref, l’idée est plutôt de savoir reconnaître les talents afin de profiter au mieux de leurs capacités et surtout de repérer les boulets en puissance…

Comment les reconnaitre ? « facile » grace à cette liste des 6 signes d’un bon développeur :

• Un bon développeur sait prendre le contrôle : C’est le fameux « ingénieur à la tâche ». Vous donnez une tâche à quelqu’un avec les moyens, il doit s’approprier la tâche et la réaliser. C’est une attitude active et pas attentive.
• Un bon développeur écrit du code avec moins de bug : De son expérience, il sait que le zéro défaut est impossible mais il applique des pratiques reconnues et saines dans le code.
• Un bon développeur écrit du code maintenable : La règle d’or : 1€ de développement = 2€ de maintenance. Il le sait et réfléchit en permanence en codant : « Est-ce que quelq’un qui lit ce code/commentaire comprendrait ? »
• Un bon développeur écrit moins de code : L’invention de la roue commence à dater… mais certains frameworks aussi ! Et pourtant tellement de développeurs partent bille en tête à implémenter une fonction qui existe déjà… 
• Un bon développeur sait rapporter : Il est capable de savoir où il en est, et surtout il est capable de délivrer cette information à son chef de projet. De ce fait, il sait remonter les difficultés rencontrées afin de trouver les solutions adéquates au plus tôt.
•  Un bon développeur s’adapte au niveau de ses collègues : Il est illusoire de croire qu’une équipe de développement sera composée uniquement de stars (sauf à travailler chez Google?). Le développeur doit donc s’adapter en ne montrant pas une attitude élitiste et négligeant les moins forts que lui. Au contraire, il doit être le catalyseur qui pousse l’équipe vers le haut. D’ailleurs lui aussi a été débutant un jour…

Inspiration :  http://haacked.com/archive/2007/06/25/understanding-productivity-differences-between-developers.aspx