Optimaal code reviewen van een privéproject

Pagina: 1
Acties:

Vraag


Acties:
  • +1 Henk 'm!

  • MichielPH
  • Registratie: Februari 2005
  • Laatst online: 14-07-2024
Binnen een project met meerdere ontwikkelaars is het haast verplicht om code te laten te reviewen voordat je het merged. Wat is de beste aanpak als je geen collega's hebt, of geen mede-ontwikkelaars die in dezelfde taal ontwikkelen?

Binnenkort ben ik van plan alleen een app te ontwikkelen. Hierbij ligt mijn expertise bij het ontwikkelen zelf, maar neem ik ook UI/UX, het bedenken van een verdienmodel, het aan de man brengen ed. voor mijn rekening. Ik wil hierbij een MVP op papier zetten en dit opdelen in kleinere deeltaken. Hierbij is het doel van de deeltaken het minimaliseren van de overhead en de totale bestede tijd. Voor de niet-ontwikkelaartaken zal ik het vooral spelenderwijs aanpakken.

Ik ben freelancer, dus dit project heeft eigenlijk twee doelen: het opleveren van m'n eigen app en mijn basiskennis qua software architectuur verbreden/verdiepen. Ik gun mezelf dus ook de tijd om van m'n fouten te leren en desnoods stukken te herschrijven.

Nu is de hoofdvraag, wat is de beste werkwijze wat betreft code reviewen? Ik zat zelf te denken aan alsnog PR's maken en die zelf na een bepaalde tijd te reviewen. Heeft iemand hier al ervaring mee?

Alle reacties


Acties:
  • 0 Henk 'm!

  • farlane
  • Registratie: Maart 2000
  • Laatst online: 27-09 13:03
Zelf reviewen doe je tijdens ontwikkelen toch al? Ik denk dat het voordeel van reviews juist ligt in het feit dat er iemand anders naar kijkt, tunnelvisie voorkomen en zo.
Als ik mijn eigen code bekijk wil ik het altijd anders doen dan ik het heb gedaan op een of andere manier.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.


Acties:
  • 0 Henk 'm!

  • MichielPH
  • Registratie: Februari 2005
  • Laatst online: 14-07-2024
farlane schreef op zondag 19 mei 2019 @ 15:42:
Zelf reviewen doe je tijdens ontwikkelen toch al? Ik denk dat het voordeel van reviews juist ligt in het feit dat er iemand anders naar kijkt, tunnelvisie voorkomen en zo.
Deels, maar omdat dat niet genoeg blijkt, laat je het ook door een ander bekijken. Mijn 'probleem' is dan ook bij dit soloproject, dat ik die ander niet heb.
Als ik mijn eigen code bekijk wil ik het altijd anders doen dan ik het heb gedaan op een of andere manier.
Ook dit ervaar ik zelf wel vaak, dus vroeg ik me af of mensen tips/ervaring hebben met soloprojecten wat dit betreft!

Acties:
  • 0 Henk 'm!

  • mcDavid
  • Registratie: April 2008
  • Laatst online: 02-10 08:45
https://lonelypullrequests.com/ dit is een leuk initiatief voor als het open-source code betreft, alleen volgens mij komt het nog niet heel erg van de grond.

Acties:
  • 0 Henk 'm!

  • Kalentum
  • Registratie: Juni 2004
  • Laatst online: 21:38
Wat mij betreft zijn er twee doelen van code review: iets leren van andere developers (bv dat een bepaald stukje code efficiënter / leesbaarder kan) en extra ogen / sanity check. Als je alleen aan een project werkt dan heb heb je die voordelen niet. Dus dan is het een kwestie van: doe jij wat jij prettig vind.

Of je nu alleen werkt of in een team, elke commit is eigenlijk je eigen code review: check je diff, kijk of alles duidelijk en commit. Het hielp mij om daarbij te denken aan de hypothetische developer die je opvolgt of je code base erft. Als je een serie van commits wil mergen dan kan het inderdaad helpen om een PR aan te maken, een tijdje wat anders te gaan doen en dan nog een keer de boel bekijken.

Maar een groot nadeel van alleen werken is dat je geen feedback van andere developers kan krijgen en daarmee is de waarde van een code review als aparte stap al wat beperkt.

Acties:
  • 0 Henk 'm!

  • sanderr
  • Registratie: Februari 2001
  • Laatst online: 20:31

sanderr

duh!

Het is sowieso wel goed om oude code nog eens door te gaan. Als je langer aan een project werkt, doe je veel kennis op en die kennis had je aan het begin van het project nog niet.

Je hebt goed gewerkt als je een half jaar later je oude code nog begrijpt.
Pagina: 1