Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: STARR 4

...

Tijdens het coderen van de verlof aanvragen kwam ik erachter dat de gegevens die de backend nodig heeft anders zijn dan de gegevens uit de wireframes. Hierdoor is het nodig om een van de implemtaties aan te passen. Na overleg is besloten om de backend aan te passen zodat het overeenkomt met de gegevens uit de wireframes. Om te voorkomen dat er zulke misverstanden zich voordoen ben ik een voorbeeld API documentatie gaan uitwerken. Zodat er vooraf afspraken worden vastgelegd over de nodige data om misverstanden te voorkomen en dus tijd te besparen. Na het toelichten van de documentatie waren de groepsgenoten het ermee eens om het op deze manier aan te pakken. Dit heeft gewerkt omdat er nu voor alle endpoints documentatie beschikbaar is en er misverstanden zijn voorkomen. Ik ga bij volgende projecten waarin een API nodig is ook deze documentatie opstellen met ook de reden dat er zo overzicht blijft en er geen misverstanden ontstaan.

werken met Pull requests

Uitkomst eerste retrospective dat het de bedoeling is om gehele functionaliteit aan te leveren in een pull request, hieruit begreep ik dus dat het de bedoeling was om de gehele functionaliteit op te leveren van een use case. Wat ik vanaf toen heb gedaan is het werk committen naar de bijhorende branche en na het afronden van een use case er een pull request van maken. Hierdoor had ik dus maar één pull request. Tijdens de tweede retrospective kreeg ik de vraag hoe het komt dat ik maar een pull request heb, en heb toen het bovenstaande toegelicht. De situatie die hierdoor is onstaan is dat groepsgenoten wachten op functionaliteit die al af is, maar niet in de develop branche staat. Daardoor moesten andere groepsgenoten mijn werk over zetten van mijn branche naar hun branches. Nadat er is verhelderd waar het probleem ligt ben ik gaan werken met pull requests in plaats van commits naar de branche. Het is dus zo dat als er een bepaald onderdeel klaar is dat, ik een pull request maak in plaats van alleen een losse commit. Na dit twee weken te hebben geprobeerd, heb ik de feedback gekregen dat mijn code nu toegankelijker is voor de groepsgenoten en dat het beoordelen van de onderdelen nu makkelijker gaat, omdat er nu losse delen worden toegevoegd in plaats van hele uitwerkingen. Wat ik hiervan heb geleerd is dat branches per feature nodig zijn, en niet complete use cases hoeven te bevatten. Daarnaast merk ik dat er minder code conflicten zijn bij het opleveren van kleine functionaliteit ten opzien van complete use cases. Voor de rest van mijn loopbaan weet ik nu het belang van pull request maken.



Wat was de situatie?

Wat was je taak?

...