Dans une bonne équipe, une file de tâches de développement doit vous être affectée dans un suivi des problèmes .
De cette façon, pendant que vous attendez un relecteur, vous pouvez ( devriez ) travailler sur la prochaine tâche en attente dans cette file d'attente. Une fois que vous vous êtes habitué à travailler de cette manière, vous aurez l’occasion de revoir vos modifications par «lots», ce qui réduira les délais.
- Si vous ne disposez pas d'une telle "file d'attente", discutez-en avec votre responsable ou, mieux encore, avec votre relecteur. Si votre équipe ne dispose pas d'un système de suivi des problèmes raisonnablement pratique pour ce genre de choses, envisagez d'étudier les offres d'emploi ou les offres d'emploi internes à l'entreprise pour trouver une meilleure équipe (vous pouvez également en discuter avec le responsable / réviseur, mais ne vous attendez pas à ce que cela vous aide - manque suivi d’un problème est souvent le symptôme d’une défaillance grave dans une équipe).
Je veux être libre lors du codage. Comment pourrais-je gagner la confiance pour la liberté de développement?
Pour le savoir, vous devez d'abord comprendre le but des révisions de code. Vous avez parlé de confiance - c'est une bonne "approximation", mais pas tout à fait exacte.
- Par exemple, dans l'un de mes projets récents, le développement a été réalisé par une mini-équipe composée de moi-même et de mon collègue. Nous nous respectons mutuellement et nous nous respectons mutuellement. Malgré cela, nous avons examiné 100% du code. Nous le faisions parce que cela nous permettait de trouver et de corriger rapidement certains bugs et, ce qui est également très important, car les critiques ne prenaient pas beaucoup de temps et ne bloquaient pas notre travail.
Vous voyez, il serait plus juste de penser à la révision de code en termes d’ efforts déployés pour prévenir certains risques . Dans une bonne équipe, vous pouvez vous attendre à une sorte de compréhension partagée de la manière de "bien équilibrer" cela. Notez qu'il n'existe pas d'équilibre unique, il dépend fortement du projet. Les risques et les impacts des bogues d'un logiciel essentiel à la mission diffèrent naturellement de ceux d'une application non critique.
En utilisant votre exemple, vous pouvez vous attendre à "bloquer les révisions" tant que les efforts investis par votre relecteur sont justifiés par la recherche de bogues et l'amélioration des améliorations à corriger avant de valider votre code.
Ils s'attendent probablement à ce qu'avec la pratique et les conseils reçus lors des examens, vous amélioriez votre codage, de sorte qu'ils trouveront de moins en moins de problèmes qu'il vaut la peine de résoudre avant de les engager. Dès qu'ils découvrent que votre code est "suffisamment sûr" pour permettre des "mesures de prévention des risques" moins lourdes, vous pouvez vous attendre à ce que le processus change, par exemple en révisions après validation .
En fonction du projet, votre code peut même être considéré comme suffisamment sûr pour ignorer les révisions, laissant la découverte des bogues aux testeurs (mais cela ne se produira pas nécessairement, voir mon exemple ci-dessus).