Contributies aan ord

Voorgestelde Stappen

  1. Vind een probleem waar je aan wilt werken.
  2. Bepaal wat een goede eerste stap zou zijn om het probleem op te lossen. Dit kan in de vorm van code, onderzoek, een voorstel, of het voorstellen om het probleem te sluiten als het verouderd of niet goed is in de eerste plaats.
  3. Plaats een reactie op het probleem met een overzicht van je voorgestelde eerste stap en vraag om feedback. Natuurlijk kun je ook meteen beginnen met het schrijven van code of tests, maar dit voorkomt mogelijk verspilde inspanningen als het probleem verouderd is, niet duidelijk is gespecificeerd, geblokkeerd is door iets anders, of om een andere reden niet klaar is voor implementatie.
  4. Als het probleem een codewijziging of bugfix vereist, open dan een concept-PR met tests en vraag om feedback. Dit zorgt ervoor dat iedereen op dezelfde lijn zit over wat er moet gebeuren of wat de eerste stap in het oplossen van het probleem zou moeten zijn. Aangezien tests vereist zijn, maakt het schrijven van de tests eerst het gemakkelijk om te bevestigen dat de wijziging eenvoudig te testen is.
  5. Random op de toetsenbord slaan totdat de tests slagen, en refactoren totdat de code klaar is om in te dienen.
  6. Mark de PR als klaar voor beoordeling.
  7. Herzie de PR indien nodig.
  8. En tot slot, versmelten!

Begin klein

Kleine veranderingen stellen je in staat om snel impact te maken, en als je de verkeerde richting inslaat, heb je niet veel tijd verspild.

Ideeën voor kleine uitgaves:

  • Voeg een nieuwe test of testcase toe die de testdekking vergroot
  • Voeg documentatie toe of verbeter het
  • Zoek een issue dat meer onderzoek nodig heeft, doe dat onderzoek en vat het samen in een commentaar
  • Zoek een verouderd issue en geef in een commentaar aan dat het kan worden gesloten
  • Zoek een issue dat niet uitgevoerd zou moeten worden en geef constructieve feedback waarin je uitlegt waarom je dat denkt

Merge vroeg en vaak

Verdeel grote taken in meerdere kleinere stappen die afzonderlijk vooruitgang boeken. Als er een bug is, kun je een PR openen die een falende, genegeerde test toevoegt. Dit kan worden samengevoegd, en de volgende stap kan zijn om de bug te verhelpen en de test niet langer te negeren. Doe onderzoek of testwerk, en rapporteer je resultaten. Verdeel een functie in kleine subfuncties en implementeer ze één voor één.

Uitzoeken hoe je een grotere PR kunt opsplitsen in kleinere PR's, waarbij elke PR kan worden samengevoegd, is een kunstvorm die het waard is om te oefenen. Het moeilijke is dat elke PR op zichzelf een verbetering moet zijn.

Ik streef er zelf naar om dit advies op te volgen, en ik ben altijd beter af wanneer ik dat doe.

Kleine wijzigingen zijn snel te schrijven, te beoordelen en te mergen, wat veel leuker is dan het ploeteren over een enkele grote PR die een eeuwigheid duurt om te schrijven, beoordelen en mergen. Kleine wijzigingen nemen niet veel tijd in beslag, dus als je moet stoppen met werken aan een kleine wijziging, heb je niet veel tijd verspild in vergelijking met een grotere wijziging die vele uren werk vertegenwoordigt. Het snel indienen van een PR verbetert het project onmiddellijk een beetje, in plaats van te wachten op een grotere verbetering. Kleine wijzigingen zijn minder waarschijnlijk om mergeconflicten op te lopen. Zoals de Atheners zeiden: De snelle committen wat ze willen, de langzame mergen wat ze moeten.

Vraag om hulp

Als je meer dan 15 minuten vastzit, vraag dan om hulp, bijvoorbeeld in een Rust Discord, Stack Exchange, of in een projectissue of discussie.

Oefen hypothesegestuurd debuggen

Stel een hypothese op over wat het probleem veroorzaakt. Bedenk hoe je die hypothese kunt testen. Voer de tests uit. Als het werkt, geweldig, je hebt het probleem opgelost of weet nu hoe je het probleem kunt oplossen. Als dat niet het geval is, herhaal dan met een nieuwe hypothese.

Let op foutmeldingen

Lees alle foutmeldingen en tolereer geen waarschuwingen.