Supposons que j'ai un objet PHP, disons: companyObj.
class companyObj
{
private company_name;
private company_address;
public function print_contact()
{
//logic
}
}
C'est l'objet que j'ai écrit et partagé avec les coéquipiers. Maintenant, je voudrais le rendre plus puissant, comme ceci:
class companyObj
{
private company_name;
private company_address;
private company_contact_person;
public function print_contact()
{
//logic updated
}
}
Maintenant, comment puis-je informer mes coéquipiers que mon objet a plus d'attributs qu'ils peuvent définir?
Au lieu d'envoyer un e-mail à tous les membres de l'équipe de développement, comment faire savoir à l'équipe ce qui se passe, quand je ne veux pas que mes coéquipiers perdent leur temps à regarder ce qui est modifié au niveau du code source?
Réponses:
Cela dépend beaucoup de la situation concrète. Supposons que la nouvelle propriété que vous avez ajoutée soit obligatoire, c'est-à-dire qu'elle doit toujours être définie. Ensuite, vous devez rechercher le code vous-même et le mettre à jour partout où un
companyObjest créé, pour vous assurer qu'il est construit correctement (y compris en définissant la nouvelle propriété). Je suppose que PHP a des constructeurs, auquel cas il vous suffit d'ajouter un nouveau paramètre constructeur et le compilateur marquera automatiquement chaque appel constructeur sans le paramètre supplémentaire comme une erreur de compilation. Cela permettra également aux coéquipiers de se renseigner sur la nouvelle propriété dès qu'ils utilisent acompanyObj.Si la nouvelle propriété est facultative, cependant, les choses sont moins claires. Vous pouvez ou non avoir une valeur par défaut appropriée pour cela. Dans ce dernier cas, je vous suggère toujours de mettre à jour toutes les créations d'instance pour définir la nouvelle propriété chaque fois que cela est approprié. Il s'agit de garantir que le code est maintenu dans un état cohérent à tout moment .
Communiquer le changement à vos coéquipiers est une autre étape lointaine ici. Les équipes agiles préfèrent la communication face à face et, à mon humble avis pour une bonne raison. S'appuyer sur des documents est un moyen très lent et inefficace de diffuser des informations au sein d' une équipe. Un wiki est un peu mieux, mais tout de même, documenter chaque attribut de classe est une surpuissance à mon humble avis. Cela ne fera que devenir un énorme fardeau pour l'équipe et deviendra vite peu fiable et inutile de toute façon, car nous sommes des humains, nous sommes donc tenus d'oublier la mise à jour parfois, de plus je parie que peu de membres de l'équipe vont régulièrement consultez la documentation (que ce soit sous quelque forme que ce soit) pour être informé des dernières modifications du code.
Ce dernier est également vrai pour la documentation générée automatiquement via par exemple Javadoc ou Doxygen. Bien qu'ils puissent être configurés en une génération automatique pour maintenir la documentation générée à jour à tout moment, je n'ai jamais vu une équipe de développement avec des membres parcourant régulièrement la documentation pour être informé des dernières modifications de code. Et si vous utilisez un système de contrôle de source, le premier endroit pour remarquer les changements est quand vous mettez à jour votre copie locale du code de toute façon - alors vous pouvez vérifier les changements dans les classes familières et voir précisément ce qui a changé et comment (avec un brève explication et / ou référence à un ID de tâche, si votre équipe est habituée à ajouter des commentaires de consignation significatifs - qui seront absents des documents générés automatiquement).
La communication est l'une des principales raisons pour lesquelles les équipes de programmation extrême font de la programmation en binôme. Si vous apportez les modifications avec un coéquipier, vous êtes immédiatement tous deux au courant de chaque changement et la prochaine fois, chacun de vous va se jumeler avec quelqu'un d'autre, donc les informations utiles se propagent assez rapidement. Elle n'est cependant pas toujours applicable, pour diverses raisons. Sauf cela, vous pouvez simplement parler à vos voisins du changement à un moment approprié (par exemple pendant le déjeuner, si vous déjeunez ensemble), ou envoyer un courrier s'il s'agit d'un changement plus important, plus important ou plus compliqué.
Dans ce dernier cas, il peut y avoir une bonne raison de le documenter correctement. Les documents de conception à mon humble avis sont meilleurs lorsqu'ils offrent une vue d'ensemble de haut niveau à gros grain, tandis que les détails de mise en œuvre sont dans le code (en respectant le principe DRY ).
la source
Avez-vous envisagé de simplement leur parler ? Planifiez une courte réunion: "hé, j'ai apporté quelques modifications à l'objet X, je veux vous montrer ce qui a changé et pourquoi". Ou, parlez simplement à chaque personne individuellement si une réunion semble trop formelle ou perturbatrice.
la source
Si vous avez une équipe, vous avez probablement aussi un document de conception. Si non. commencer. Et utilisez un outil UML pour cartographier vos conceptions.
la source
Vous pouvez utiliser un outil comme doxygen dans votre code. Créez maintenant un script qui générerait la documentation doxygen et l'exécuterait régulièrement, peut-être dans le cadre de votre build nocturne (vous faites un build nocturne, non?).
Je pense que vous pouvez attribuer un attribut personnalisé dans doxygen à votre ajout pour le mettre en évidence comme étant nouveau.
Si vos coéquipiers sont bons, ils passeront par la nouvelle documentation.
la source
Eh bien, vous ne devriez pas informer vos coéquipiers de chaque petite chose que vous faites. Sinon, vous devrez envoyer de nombreux e-mails. Si c'est une grande chose, vous pouvez faire une petite réunion et leur faire savoir ce que vous avez fait (si vous faites de la mêlée, alors pas besoin de fixer une réunion séparée).
Si vous utilisez un IDE qui prend en charge la saisie semi-automatique, vos coéquipiers devraient remarquer votre changement. J'espère juste que vous commenterez votre code.
la source