Conventionele commits zullen je commit-berichten niet redden
Verkent waarom simpelweg conventionele commits volgen niet genoeg is om goede commit-berichten te schrijven, en introduceert belangrijke denkstrategieën om je ontwikkelingsproces te verbeteren en op natuurlijke wijze betekenisvolle commits te creëren.
YijunDeveloper
Stop met weken verspillen aan gebruikersauthenticatie
Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.
Een snelle zoekopdracht op internet onthult een overvloed aan artikelen die je leren hoe je commit-berichten schrijft. 90% van deze artikelen vertellen je om conventionele commits te gebruiken. Echter, een aanzienlijk aantal ontwikkelaars worstelt hier nog steeds mee. Ze weten dat ze deze conventies moeten volgen, maar ze vinden het moeilijk om ze in de praktijk toe te passen. Elke keer dat ze code committen, piekeren ze over of ze "refactor" of "chore" moeten schrijven. Ik heb zelfs projecten gezien waar de lijst met commit-berichten volledig bestond uit dezelfde boodschap: "feat: add page", omdat het schrijven van commit-berichten te uitdagend voor hen was en ze simpelweg opgaven.
Het is te vroeg om te praten over conventionele commits#
Ik zeg niet dat conventionele commits slecht zijn. Ze hebben veel bekende voordelen:
Ze bieden een uniform formaat, waardoor commit-berichten gestandaardiseerder worden
Ze zijn gemakkelijk te parsen voor geautomatiseerde tools, waardoor automatische changelog-generatie mogelijk is
Ze helpen teamleden de bedoeling en reikwijdte van codewijzigingen te begrijpen
Ze maken een snelle identificatie mogelijk van verschillende soorten codewijzigingen
Echter, wanneer een ontwikkelaar nog steeds worstelt om goede commit-berichten te schrijven, zelfs na het gebruik van conventionele commits, is het feitelijk zinloos om hen een artikel te geven over hoe conventionele commits te gebruiken, en hen te leren wat feat type betekent, wat fix type betekent. Het is als het geven van een geavanceerd kookboek aan iemand die niet weet hoe hij moet koken, zonder ze te leren hoe je basisingrediënten en keukengerei gebruikt. Toch zijn zulke artikelen overal op internet te vinden. Weinig mensen beseffen dat conventionele commits alleen echt effectief kunnen zijn wanneer ontwikkelaars helder denken en het vermogen hebben om taken nauwkeurig te verdelen.
Dus, conventionele commits zijn niet slecht, maar voordat we daar komen, moeten we de juiste ontwikkelingsmentaliteit vaststellen en wetenschappelijk ontwikkelaarsdenken gebruiken om dingen te doen.
Belangrijk denken voor het schrijven van goede commit-berichten#
In softwareontwikkeling is "één ding tegelijk doen" een belangrijk principe. Dit geldt niet alleen voor het schrijven van code, maar ook voor het committen van code. Wanneer we ons op één specifieke taak of wijziging tegelijk concentreren, wordt onze code duidelijker en onze bedoelingen explicieter. Deze methode verbetert niet alleen de leesbaarheid van de code, maar vereenvoudigt ook het codebeoordelingsproces aanzienlijk. Beoordelaars kunnen gemakkelijker de bedoeling en de juistheid van elke wijziging begrijpen en verifiëren.
Bovendien biedt deze methode gemak voor mogelijke code-terugdraaiingen. Als er problemen optreden, kunnen we gemakkelijker specifieke wijzigingen lokaliseren en terugdraaien zonder andere niet-gerelateerde delen te beïnvloeden. Het belangrijkste is dat wanneer elke wijziging slechts één ding doet, het commit-bericht dat deze wijziging beschrijft van nature preciezer en betekenisvoller wordt.
In de praktijk betekent dit dat we de taak die moet worden voltooid duidelijk moeten definiëren voordat we beginnen met coderen. Na voltooiing van een taak moeten we onmiddellijk de code committen, in plaats van te wachten tot meerdere taken zijn afgerond voordat we ze samen committen. Als we andere delen ontdekken die moeten worden aangepast terwijl we de huidige taak voltooien, is de beste aanpak om ze op te schrijven en ze afzonderlijk te behandelen nadat de huidige taak is voltooid. Bijvoorbeeld, wanneer je een functie implementeert en enkele bestaande bugs ontdekt, wat je dan moet doen, is niet direct die bug samen met je nieuwe functiecode repareren, maar eerder de functie implementeren en dan de bug die je hebt ontdekt in een andere commit oplossen, of eerst de bug oplossen en vervolgens de functie committen.
Commit-berichten bestaan eigenlijk vóór het schrijven van code#
Veel ontwikkelaars beginnen pas na voltooiing van de code na te denken over hoe ze commit-berichten moeten schrijven, maar in werkelijkheid zouden commit-berichten moeten bestaan voordat we beginnen met coderen. Dit komt omdat commit-berichten in wezen de stappen weerspiegelen die we nemen om een taak te voltooien. Met andere woorden, ze zijn onze todo-items.
Wanneer we aan een taak beginnen, moeten we eerst nadenken over welke specifieke stappen nodig zijn om deze taak te voltooien. Deze stappen zijn onze todo-lijst, en tegelijkertijd zijn het onze toekomstige commit-berichten. Met deze todo-lijst heeft elke van onze codewijzigingen een doel, waardoor we gefocust blijven tijdens het coderen en voorkomen dat we afdwalen van de taak.
Belangrijker nog, deze methode kan onze efficiëntie aanzienlijk verbeteren. Wanneer we een stap voltooien, is het bijbehorende commit-bericht al voorbereid en kunnen we het direct gebruiken, waardoor de tijd die wordt besteed aan nadenken over hoe de wijziging te beschrijven, wordt verminderd. Tegelijkertijd, omdat deze commit-berichten worden voltooid wanneer we een volledig begrip van de taak hebben, zijn ze meestal van hogere kwaliteit en informatiever.
Stel dat je een nieuwe gebruikersregistratiefunctie moet implementeren. Je zou je taakstappen als volgt kunnen plannen:
Refactor de bestaande formulierelement om deze generieker en herbruikbaarder te maken
Maak een gebruikersregistratieformulier
Implementeer API-integratie voor gebruikersregistratie
Voeg unit-tests toe voor de gebruikersregistratiefunctie
Werk documentatie bij voor de gebruikersregistratiefunctie
De commit-berichten die overeenkomen met deze taakstappen kunnen als volgt zijn:
refactor: verbeter bestaand formulierelement voor herbruikbaarheid
test: voeg unit-tests toe voor gebruikersregistratie
docs: werk documentatie bij voor gebruikersregistratiefunctie
Op deze manier heb je duidelijke taakstappen en bijbehorende beknopte commit-berichten voordat je begint met coderen. Deze commit-berichten zijn eigenlijk je todo-lijst, die je door het hele proces van het implementeren van de functie begeleidt.
Terwijl je elke stap voltooit, kun je het bijbehorende commit-bericht gebruiken om je code te committen. Dit helpt je niet alleen om taken beter te organiseren en uit te voeren, maar zorgt er ook voor dat elke commit zich richt op een specifieke stap, waardoor het hele ontwikkelingsproces duidelijker en beheersbaarder wordt. Als je het commit-bericht tijdens het daadwerkelijke coderen enigszins moet aanpassen, kun je dit met kleine wijzigingen doen om de daadwerkelijke wijzigingen nauwkeuriger te beschrijven.
Conventionele commits worden een natuurlijke keuze#
Wanneer we de juiste ontwikkelingsmentaliteit ontwikkelen, wordt het gebruik van conventionele commits natuurlijk. Op dit punt zul je merken dat het kiezen van het juiste type prefix (zoals feat, fix, refactor, enz.) moeiteloos wordt omdat je commit-berichten al duidelijk je taakstappen weerspiegelen.
Als je meer wilt leren over hoe conventionele commits te gebruiken, zijn er online veel uitstekende artikelen beschikbaar. Maar onthoud, deze standaarden kunnen alleen echt effectief zijn wanneer ze zijn gebouwd op de basis van de juiste ontwikkelingsmentaliteit.
Het schrijven van goede commit-berichten gaat niet alleen over het volgen van een bepaald formaat. Het vereist dat we helder blijven denken tijdens het ontwikkelingsproces, het doel van elke wijziging verduidelijken, en nadenken over hoe ons werk te beschrijven voordat we beginnen met coderen.
Conventionele commits is inderdaad een nuttig hulpmiddel, maar het kan alleen zijn maximale effect uitoefenen wanneer het wordt gecombineerd met de juiste ontwikkelingsmentaliteit. Door de twee principes "één ding tegelijk doen" en "denk vooraf na over commit-berichten" te oefenen, kunnen we niet alleen de kwaliteit van commit-berichten verbeteren, maar ook de algehele ontwikkelingsefficiëntie en codekwaliteit verhogen.
Ik hoop dat dit artikel je helpt je ontwikkelingsproces te heroverwegen en je aanmoedigt om deze methoden te proberen. Vergeet niet, goede ontwikkelingsgewoontes vergen tijd om te kweken, maar eenmaal gevormd zullen ze je werk efficiëntie en codekwaliteit aanzienlijk verbeteren.
