5 tips voor het kiezen van de juiste open source code

Studies uitgevoerd door Google tonen aan dat voor veel ontwikkelaars het vinden van code online een groot deel van de dag in beslag neemt. Het vinden van een eenvoudige functie, een bibliotheek, een handig pakket, een herbruikbaar onderdeel of een handige "how to" blog-tutorial is niet altijd eenvoudig. Weten of je de gevonden code kunt vertrouwen en gebruiken, kan nog lastiger zijn.

Het vinden van de juiste code betekent meestal dat je je wendt tot de goden van Google of andere zoekmachines, een zoekopdracht invoert en vingers kruist voor een snelle overwinning. Eenvoudige functionele zoekopdrachten zoals "Javascript heeft een eigen eigenschap" zullen waarschijnlijk leiden tot verschillende forums en blogposts, terwijl beschrijvingen op een hoger niveau ("Reageer component x") u vaak in GitHub of NPM zullen brengen.

Maar zelfs na het vinden van de juiste code, is het vertrouwen en gebruiken ervan een heel ander probleem. Om te helpen begrijpen welke code u daadwerkelijk kunt gebruiken, heb ik 5 parameters verzameld die nuttig kunnen zijn om te overwegen. Het nemen van de juiste beslissing moet rekening houden met deze parameters (onder andere), evenals met de aard van de taak zelf. Dit zijn de 5 sleutels die u kunt overwegen om de juiste code te kiezen.

#1. Is de code leesbaar?

Leesbare code betekent veel meer dan alleen goede opmerkingen en documentatie. Het betekent dat de code zelf voor u leesbaar moet zijn. Verschillende parameters voor leesbaarheid kunnen goede naamgevingsconventies zijn voor identifiers, goede spatiëring, duidelijk leesbare logica, goed begrepen scopes en meer. Waar het op neerkomt, is dat de code leesbaar moet zijn voor jou . Als je een stukje code kiest, zelfs een die werkt, maar je begrijpt niet helemaal hoe het werkt, dan breng je in feite een tijdbom voor onderhoud in je codebasis.

Het debuggen, wijzigen, bijwerken en onderhouden van code die u niet kunt lezen, is iets dat u ten zeerste moet vermijden. De beste manier om het te vermijden, is door het, indien mogelijk, nooit toe te laten.

#2. Wordt de code actief onderhouden?

We willen dat de code die we kiezen "levend" is. Dit betekent dat we willen weten dat bugs, problemen en updates worden afgehandeld en dat deze code actief wordt onderhouden door de ontwikkelaars die deze hebben geschreven. Een mooi voorbeeld voor een activiteitsindicator zijn de openstaande problemen van GitHub, de pull-requests en de Pulse-indicator. Pakketbeheerders bieden informatie die relevant is voor onderhoud, zoals het aantal afhankelijkheden en afhankelijke projecten, maar hebben nog steeds moeite om een ​​betrouwbare metriek op dit gebied te presenteren.

Maar als een groot populair project afhankelijk is van een ander pakket, kunnen we ervan uitgaan dat de kans groot is dat problemen worden opgelost (we herinneren ons echter allemaal de linkerpad). Wanneer u echter code kopieert van stackoverflow (wat op zich al een probleem is), weet u niet of u erop kunt vertrouwen dat deze code behouden blijft, behalve dat u deze zelf bijwerkt wanneer dat nodig is (en waar u deze ook hebt gekopieerd).

Kleine kernfunctionaliteiten veranderen simpelweg niet zo veel. In deze geest vertrouwen herbruikbare componenten die uit Bit worden geïmporteerd, op een eenvoudige incrementele versiebeheer die de versie van de component met 1 verhoogt elke keer dat de auteur iets heeft gewijzigd. Door uw componenten in een "laatst bijgewerkte" versie te houden, betekent dat, na goede tests, uw code actief kan worden onderhouden door de beheerder, terwijl zelfs kleine functies of componenten in uw code worden bijgewerkt zonder iets te breken.

#3. Is de code goed getest?

Het kiezen van code die werkt is waarschijnlijk onze eerste prioriteit. Tests zijn een geweldige manier om te weten of de code die ik gebruik, echt doet wat het moet doen. De testbeschrijving bevat ook verschillende use-cases en edge-cases die ons helpen te weten hoe deze code zich in verschillende situaties zal gedragen. Het gebruik van geteste componenten zorgt voor meer onderhoudbare software als geheel, wat tijd en moeite bespaart bij het proberen om dingen te veranderen voordat ze naar productie gaan.

Fragmenten die van internet zijn gekopieerd, worden meestal niet geleverd met tests. Zelden of helemaal niet bevatten functies die zijn gekopieerd van forums of blogposts unit-tests. Pakketten en bibliotheken kunnen heel goed worden getest, het probleem ligt in het snel kunnen achterhalen. Bij het verkennen van een bibliotheek op GitHub kunnen verschillende badges of bestanden in de repository aangeven hoe goed en hoeveel van deze code is getest. We zullen nog steeds indicatoren van externe tools moeten gebruiken om erachter te komen of de tests zijn geslaagd of niet. Bij het zoeken naar een pakket is er niet echt een betrouwbare manier om te weten welk pakket is getest en of de tests nuttig zijn geslaagd. Dit is een groot probleem als het gaat om de vindbaarheid van pakketten. Herbruikbaar

Bij het zoeken naar een pakket is er niet echt een betrouwbare manier om te weten welk pakket is getest en of de tests nuttig zijn doorstaan. Dit is een groot probleem als het gaat om de vindbaarheid van pakketten. Herbruikbare Bit-componenten kunnen worden getest als dergelijke tests door de ontwikkelaar worden toegevoegd. De Bit Scope voert de test uit zodat de groene indicatoren en de testbeschrijving online kunnen worden weergegeven voordat een onderdeel wordt gekozen uit de Bit-communityhub (of via de CLI bij gebruik op uw lokale computer op een gedistribueerde manier).

#4. Wordt de code door anderen gebruikt?

Populariteit is iets waar we evolutionair op vertrouwen. De publieke opinie is goed voor het nemen van beslissingen die ons helpen te overleven. Als we iedereen een bepaald fruit van een boom zien eten, weten we dat het ons waarschijnlijk niet zal doden. Als we iedereen uit de struiken zien rennen, kan er snel een hongerige tijger volgen. Tot op zekere hoogte geldt hetzelfde voor het kiezen van code in 2017.

Op programmeerforums kunnen we verschillende indicaties gebruiken, zoals een "V" die de juiste antwoorden markeert, het aantal stemmen met stemmen en vocale meningen van gebruikers. Dit zijn uitstekende en geruststellende functies om de kans te vergroten dat de code goed werkt. Als het op GitHub aankomt, kunnen we vertrouwen op sterren, medewerkers en andere sociale statistieken om een ​​betrouwbaar gevoel te krijgen. Bij het zoeken naar pakketten zou een goede indicator het aantal downloads voor dit pakket zijn.

Bitcomponenten die te vinden zijn op de Bit-communityhub tonen het aantal downloads, bijdragers (op scopeniveau), eenvoudige "likes" en meer (zoals weergegeven in deze React Scope van componenten). Houd er hoe dan ook rekening mee dat sociale statistieken een goede indicatie zijn, maar een absolute waarheid met betrekking tot de kwaliteit van de code. Mensen hebben het vaak bij het verkeerde eind en de publieke opinie kan sneller veranderen dan we denken.

#5. Is de code goed gedocumenteerd?

Documentatie maakt code veel gemakkelijker te begrijpen, te gebruiken en aan te passen. Het is ook een goede indicatie voor de gedachte en zorgvuldigheid die de ontwikkelaar die de code heeft geschreven erin heeft gestopt. De documentatie voor code gevonden op Stack Overflow of verschillende blogposts kan zowel bestaan ​​uit de opmerkingen in de code zelf als uit het daadwerkelijke antwoord of blog waarin het is gevonden. Wanneer een forumantwoord een nuttige uitwerking bevat van de code die het bevat, is dit zou heel goed een documentatie kunnen zijn die het waard is om toe te voegen, zelfs als je de code zelf kopieert (opnieuw, gelieve de code niet te kopiëren en plakken).

Voor GitHub-repository's en -pakketten is het een beetje lastiger. Gewoonlijk geven de readme- en docs-bestanden op GitHub of NPM een algemene indicatie van de kwaliteit van de documentatie. Documentatie voor Bit-componenten wordt geparseerd vanuit de code zelf en toont dus de daadwerkelijke beschrijving voor de atomaire component, en kan ook gebruiksvoorbeelden en een gespecificeerde handtekening bevatten, inclusief argumenten en resultaten voor verschillende functies en gedrag voor React-componenten en andere. Hoe dan ook, het kiezen van gedocumenteerde code is waar mogelijk een goede beslissing.

Voor GitHub-repository's en -pakketten is het een beetje lastiger. Gewoonlijk geven de readme- en docs-bestanden op GitHub of NPM een algemene indicatie van de kwaliteit van de documentatie. Documentatie voor Bit-componenten wordt geparseerd vanuit de code zelf en toont dus de feitelijke beschrijving voor de atomaire component, en kan ook gebruiksvoorbeelden en een gespecificeerde handtekening bevatten, inclusief argumenten en resultaten voor verschillende functies en gedrag voor React-componenten en andere. Hoe dan ook, het kiezen van gedocumenteerde code is waar mogelijk een goede beslissing.

Beslissing nemen

Uiteindelijk is het menselijk geheugen beperkt en heeft het weinig zin om telkens het wiel opnieuw uit te vinden. Bij het vinden en gebruiken van een stuk open source-code kunnen de bovenstaande indicatoren er echter voor zorgen dat uw applicatie veilig, onderhoudbaar, werkend en in goede gezondheid blijft.

Verschillende gebruiksscenario's betekenen dat er een ander gewicht wordt toegekend aan de verschillende parameters. Bij het kiezen van een pakket zal het moeilijk zijn om te weten hoe getest, leesbaar, gedocumenteerd en actief onderhouden het is. Bij het kopiëren van code van een online forum, geven we mogelijk prioriteit aan populariteit boven tests, onderhoud enzovoort. Bitcomponenten combineren informatie die relevant is voor het importeren en hergebruiken van componenten en atomaire functionaliteiten zoals beschrijving, voorbeelden, downloads, afhankelijkheden, testbeschrijving, testresultaten en meer. Door deze verschillende parameters zorgvuldig te overwegen, kunnen we een weloverwogen beslissing nemen en het doolhof van het vinden en kiezen van de juiste code voor de klus doorkruisen.