Tout d'abord merci pour ce journal, je trouve vraiment intéressant de prendre du recul comme ça. De plus le développement de projet au forfait n'est vraiment pas un métier facile.
Les API bien faite c'est vraiment le Graal, ce qui rende le produit évolutif et perso je pense qu'il faut au contraire pouvoir les casser pour arriver petit à petit à la bonne convergence. Seule règle que je trouve intéressante : les API de haut niveau devrait parler en langage métier (utiliser les mots / les concepts) c'est ce qui bougera le moins. Bien sur on a souvent besoin d'aller dans plus de détails technique (par exemple on a pas seulement des utilisateurs mais on doit se connecter à une BDD ou un LDAP...) doivent la encore refléter le mots de cet univers technique et si possible être dé-corrélées.
Concernant les tests, j'ai déjà essayé de faire des tests qui produisaient en sorti un scénario : je suis tel utilisateur, je fais ça puis ça, il se passe ça, etc... j'ai vu que malheureusement, comme j'ai dit dans un commentaire précédent, les clients n'ont souvent pas la volonté de vérifier tout ça ou pas la compétence d'en vérifier la cohérence. Le dialogue de personne à personne, l'écoute et l'intuition du besoin et du métier, la capacité de raisonnement et de créativité restent souvent les meilleurs facteurs de succès.
Le découpage en responsabilité et composants est également important et là encore très difficile à juger du premier coup. Par exemple je pourrais souvent, au début, mettre utilisateurs, groupes et permissions ensemble, mais si ça se complexifié ça devient un poids. De plus il faut éviter les dépendances croisées (A dépend de B qui dépend de A) qui sont une plaie pour les évolutions (il faut un A' qui dépend de A et B et éventuellement un B' qui dépend aussi de A et B) mais c'est très difficile de prendre la décision de refactorer au bon moment. Car sinon on va être dans l'over-engineering. Mais en pratique on se rend souvent compte trop tard, qu'à force d'entorses, on aurait dû séparer en plusieurs responsabilités. C'est de la dette technique et peu de client acceptent de payer pour ça (ou il faut vraiment une relation de confiance).
Tout cela sans compter que dans mon expérience sur une équipe de dév il y aura souvent 60% des gens qui n'auront pas une grande attention à ces discours, les trouverons obscurs ou superflus, ou simplement auront une petit flemme de bien faire et ne suivront donc que partiellement ces consignes...
Bref, je ne pense pas qu'il y ai de silver bullet. Par contre effectivement avoir une personne qui, dans l'équipe, tient l'œil sur ces points, mener des réflexions ensemble là dessus, est toujours intéressant et peut porter à un mieux.
# Découpages, responsabilités et API
Posté par Alex G. . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 1.
Tout d'abord merci pour ce journal, je trouve vraiment intéressant de prendre du recul comme ça. De plus le développement de projet au forfait n'est vraiment pas un métier facile.
Les API bien faite c'est vraiment le Graal, ce qui rende le produit évolutif et perso je pense qu'il faut au contraire pouvoir les casser pour arriver petit à petit à la bonne convergence. Seule règle que je trouve intéressante : les API de haut niveau devrait parler en langage métier (utiliser les mots / les concepts) c'est ce qui bougera le moins. Bien sur on a souvent besoin d'aller dans plus de détails technique (par exemple on a pas seulement des utilisateurs mais on doit se connecter à une BDD ou un LDAP...) doivent la encore refléter le mots de cet univers technique et si possible être dé-corrélées.
Concernant les tests, j'ai déjà essayé de faire des tests qui produisaient en sorti un scénario : je suis tel utilisateur, je fais ça puis ça, il se passe ça, etc... j'ai vu que malheureusement, comme j'ai dit dans un commentaire précédent, les clients n'ont souvent pas la volonté de vérifier tout ça ou pas la compétence d'en vérifier la cohérence. Le dialogue de personne à personne, l'écoute et l'intuition du besoin et du métier, la capacité de raisonnement et de créativité restent souvent les meilleurs facteurs de succès.
Le découpage en responsabilité et composants est également important et là encore très difficile à juger du premier coup. Par exemple je pourrais souvent, au début, mettre utilisateurs, groupes et permissions ensemble, mais si ça se complexifié ça devient un poids. De plus il faut éviter les dépendances croisées (A dépend de B qui dépend de A) qui sont une plaie pour les évolutions (il faut un A' qui dépend de A et B et éventuellement un B' qui dépend aussi de A et B) mais c'est très difficile de prendre la décision de refactorer au bon moment. Car sinon on va être dans l'over-engineering. Mais en pratique on se rend souvent compte trop tard, qu'à force d'entorses, on aurait dû séparer en plusieurs responsabilités. C'est de la dette technique et peu de client acceptent de payer pour ça (ou il faut vraiment une relation de confiance).
Tout cela sans compter que dans mon expérience sur une équipe de dév il y aura souvent 60% des gens qui n'auront pas une grande attention à ces discours, les trouverons obscurs ou superflus, ou simplement auront une petit flemme de bien faire et ne suivront donc que partiellement ces consignes...
Bref, je ne pense pas qu'il y ai de silver bullet. Par contre effectivement avoir une personne qui, dans l'équipe, tient l'œil sur ces points, mener des réflexions ensemble là dessus, est toujours intéressant et peut porter à un mieux.