anchor.diff:  | LOG	| Utiliser des loggers	| https://github.com/oliviercailloux/java-course/blob/master/Log/README.adoc[Log]	| −1
   | STREAMS	| Utiliser des streams pour plus de généralité quand approprié	| https://github.com/oliviercailloux/java-course/blob/master/Flows.adoc[Flows]	| −1
   | POM	| Respecter les conventions de nommage et autres bonnes pratiques Maven, simplifier le POM autant que possible	| https://github.com/oliviercailloux/java-course/tree/master/Maven[Maven]	| −1
  -| SEP	| Séparer les tâches | https://github.com/oliviercailloux/java-course/blob/master/Divers/Projets.adoc#SEP[Projets – SEP] | 
  +| SEP	| Séparer les tâches | https://github.com/oliviercailloux/java-course/blob/master/Divers/Projets.adoc#SEP[Projets – SEP], FOCUS | 
   | TRAV  | Test qualité Travis passe | https://github.com/oliviercailloux/java-course/blob/master/Divers/Projets.adoc#NICE[Projets – NICE]
   |===
   
  
positive.code: * Privilégiez les méthodes statiques aux constructeurs.
  * Si vous modifiez du code existant, vous êtes responsable d’améliorer raisonnablement le code qui l’entoure là où c’est facile, de corriger les bugs évidents. Ne vous dédouanez pas d’erreurs évidentes sous prétexte que ce n’est pas vous qui avez écrit telle ligne de code précisément.
  * Lorsque vous intégrez du code d’autrui, il faut indiquer que votre projet l’utilise. Cette mention doit être claire, pas être noyée dans un flot de texte où vous décrivez d’autres choses. Par exemple, mentionner dans le README de votre projet la provenance de votre template html. Ou, indiquer la provenance dans la javadoc d’une méthode copiée depuis StackOverflow. Cette règle ne s’applique pas si vous ne copiez qu’une ou deux lignes de codes triviales.
  * [[SEP]]Je dois voir vos changements facilement et les distinguer de code auto-généré ou importé sans changements de votre part. Si par exemple vous ajoutez un canevas HTML de 100 fichiers, faites-le dans une tâche dédiée, et créez une autre tâche pour vos modifications. (SEP)
  * Maintenez les conversations focalisées. Ce n’est pas une bonne idée, par exemple, d’indiquer dans un commentaire de la PR #37 que vous avez décidé d’abandonner la PR #22 pour telle et telle raison : quand j’évaluerai la PR #22 par la suite, il est peu probable que je me souvienne de vos explications se trouvant en PR #37.
  * Une mission importante du SM/PO est de s’assurer que le projet converge vers un ensemble cohérent de fonctionnalités exploitables dans la branche `master`. Tentez de terminer en priorité les tâches presque finies qui ne sont pas encore dans `master`, par exemple, avant de commencer de nouvelles choses.
  
  
negative.code: ** Si vos collègues dépendent de votre tâche, vous pouvez bien sûr (ou devriez) modifier directement sans attendre la prochaine livraison. Ce sera en particulier le cas si vous êtes le SM/PO et que votre tâche définit le plan à suivre pour cette livraison. Dans ce cas, effectuez des commits sur la branche de votre tâche, puis commentez en me https://github.blog/2011-03-23-mention-somebody-they-re-notified/[@mentionnant] (`@oliviercailloux`) quand vous êtes prêt pour une nouvelle review.
  ** [[FOLLOW-UP]] Une tâche est effectuée en une seule itération. Si votre tâche poursuit une tâche d’une livraison précédente, il s’agit quand-même d’une nouvelle tâche. Vous pouvez cependant poursuivre sur la même PR. Changez les affectés (une fois que vous avez reçu la note pour l’itération précédente !) et indiquez dans un commentaire de la PR « Itération X » avec X le numéro de la nouvelle itération, pour que je voie où commence chaque itération. (FOLLOW-UP)
  ** [[NICE]] Vous remettez un devoir, pas un brouillon mal torché. Soignez-le. Votre code doit être mis en forme systématique, suivre les https://github.com/oliviercailloux/java-course/tree/master/Best%20practices[bonnes pratiques], vous devez prendre en compte d’éventuelles indications d’erreurs de vos outils (Eclipse, GitHub, Travis, …), etc. Faites tout ça _avant_ de m’indiquer comme reviewer sur une PR. (Vous pouvez compléter une PR après sa création en ajoutant des commit dans la branche associée.) (NICE)
  ** [[SEP]]Je dois voir vos changements facilement et les distinguer de code auto-généré ou importé sans changements de votre part. Si par exemple vous ajoutez un canevas HTML de 100 fichiers, faites-le dans une tâche dédiée, et créez une autre tâche pour vos modifications. (SEP) Les changements visiblent dans une PR doivent être en rapport avec votre tâche, elle-même focalisée sur un sujet bien défini. (FOCUS)
  * Si vous ne respectez pas une des instructions notées ici, j’indiquerai simplement INSTR SVP, car je n’ai pas le temps de rappeler les instructions à chacun en détail. Dans ce cas, _votre livraison n’est pas acceptée_. J’attends une correction pour respect des instructions. (Suivez les instructions de modification sur une même branche, ci-dessus.) En attendant, votre délai de retard cours, si la date de livraison est dépassée. (Seule cette abréviation INSTR indique que votre livraison n’est pas acceptée. Si j’utilise d’autres abréviations, elles se réfèrent généralement à la table ci-dessous, et font partie de mon évaluation normale de votre tâche.)
  
  Lors de la dernière itération, vous ajouterez dans votre README de projet une ligne indiquant, pour chacun d’entre vous, la diversité des tâches auxquelles vous avez participé (exemple : GUI dans tâche Truc, test unitaire dans tâche Bidule, parsing XML dans tâche Machin), et éventuellement un commentaire bref indiquant les difficultés particulières auxquelles vous avez été confronté dans votre projet ou dans vos tâches en particulier, pour attirer mon attention lors de l’évaluation finale.
  