Forstå kilde- og pakkekomponent

Nuværende udviklingspraksis har allerede begrebet komponentisering – processen med at nedbryde et system i diskrete, håndterbare komponenter. Der er to primære tilgange til komponentisering, der almindeligvis bruges i softwareudvikling.

To tilgange til komponentisering

Komponentisering af kilde

Kildekomponentisering er fokuseret på at organisere kildekode. Det refererer til at opdele kildekoden i kodebasen i separate dele og organisere den omkring de identificerede komponenter.

Sådan fungerer det:

• Kode er organiseret i logiske moduler eller projekter i en løsning.
• Komponenter defineres af mappestruktur og projektgrænser.
• Teams arbejder på forskellige komponenter inden for det samme lager.

Hvornår skal kildekomponentisering bruges:

• Et enkelt team eller tæt koordinerede hold: Når alle udviklere arbejder i samme lager.
• Tæt koblede komponenter: Når komponenter ofte skifter sammen.
• Tidlig udvikling: Når komponentgrænser stadig defineres.
• Kun intern brug: Når kildekoden ikke deles uden for projektet.

Fordele:

• Forenklet udvikling: Al kode er samlet ét sted, hvilket gør det nemt at foretage ændringer på tværs af komponenter.
• Nemmere refactoring: Komponentgrænser kan justeres uden at ændre eksterne kontrakter.
• Samlede builds: Alt kompileres sammen, hvilket gør det nemmere at sikre kompatibilitet.

Begrænsninger:

• Fælles udfordringer: Når komponenter skal deles, kræver det distribution af kildekoden eller de producerede binære artefakter.
• Kompleksitet i versionskontrol: Store arkiver kan blive svære at administrere.
• Byggetider: Hele løsningen skal bygges selv ved små ændringer.
• Begrænset autonomi: Teams skal koordinere ændringer på tværs af komponenter.

Komponentisering af pakke

Pakkekomponentisering bruger pakker som en formel måde at pakke ind og håndtere komponenter på. Distribution af softwarekomponenter udføres ved at oprette og udgive pakker.

Sådan fungerer det:

• Komponenterne bygges og pakkes separat.
• Pakker publiceres til pakkefeeds (Azure Artifacts, NuGet.org, npm, Maven Central).
• Projekter forbruger komponenter ved at referere til pakkeversioner.
• Hver komponent har sin egen version og udgivelsescyklus.

Hvornår skal pakkekomponentisering bruges:

• Flere hold: Når forskellige teams vedligeholder forskellige komponenter.
• Løst koblede komponenter: Når komponenter kan udvikle sig uafhængigt.
• Ekstern deling: Når komponenter deles på tværs af organisationer eller offentligt.
• Modne komponenter: Når komponentgrænseflader er stabile.

Fordele:

• Uafhængig versionering: Hver komponent kan versioneres og frigives uafhængigt.
• Bedre afhængighedsstyring: Eksplicitte erklæringer om afhængigheder med versionsbegrænsninger.
• Forbedret styring: Kontrol over, hvilke versioner der forbruges.
• Team autonomi: Teams kan arbejde på komponenter uafhængigt.
• Genbrugelighed: Komponenter kan nemt deles på tværs af projekter og organisationer.

Egenskaber tilføjet af pakker:

• Versionering: Spor og administrer forskellige versioner af komponenter.
• Metadata: Medtag oplysninger om forfattere, licenser og afhængigheder.
• Distribution: Formel distributionskanal gennem pakkefeeds.
• Afhængighedsløsning: Automatisk løsning af transitive afhængigheder.

Valg af den rigtige tilgang

Valget mellem kilde- og pakkekomponentisering afhænger af dine specifikke behov:

Mange organisationer bruger en hybrid tilgang, der kombinerer begge metoder:

• Brug kildekomponentisering til kerneprogramkode.
• Brug pakkekomponentisering til delte biblioteker og strukturer.

Se også Samarbejd mere, og byg hurtigere med pakker.