JavaScript moduļu validācija: koda kvalitātes nodrošināšanas uzlabošana globālai izstrādei

Mūsdienu programmatūras izstrādes dinamiskajā vidē spēja veidot robustas, uzturamas un mērogojamas lietojumprogrammas ir vissvarīgākā. Globālām izstrādes komandām, kas strādā dažādās ģeogrāfiskās vietās un ar dažādām tehnoloģijām, konsekventas koda kvalitātes nodrošināšana ir nozīmīgs uzdevums. Šo centienu pamatā ir JavaScript moduļu validācija – kritiska koda kvalitātes nodrošināšanas prakse, kas stiprina mūsu lietojumprogrammu uzticamību un integritāti.

JavaScript ar savu visuresošo klātbūtni tīmekļa izstrādē un paplašināto sasniedzamību serveru puses vidēs, izmantojot Node.js, ir kļuvis par de facto valodu daudziem starptautiskiem projektiem. JavaScript modulārā daba, vai nu izmantojot cienījamo CommonJS modeli, vai modernākos ECMAScript moduļus (ESM), ļauj izstrādātājiem sadalīt sarežģītas lietojumprogrammas mazākos, pārvaldāmos un atkārtoti lietojamos gabalos. Tomēr šī modularitāte rada arī jaunus izaicinājumus, īpaši nodrošinot, ka šie moduļi pareizi mijiedarbojas, atbilst iepriekš definētiem standartiem un pozitīvi ietekmē kopējo kodu bāzi.

Šī visaptverošā rokasgrāmata iedziļinās JavaScript moduļu validācijas sarežģītībā, izpētot tās nozīmi, dažādas izmantotās metodes, rīkus, kas atvieglo procesu, un praktiskus ieskatus, kā ieviest efektīvas koda kvalitātes nodrošināšanas stratēģijas jūsu globālajām izstrādes komandām.

Kāpēc JavaScript moduļu validācija ir izšķiroša?

Pirms mēs iedziļināmies “kā”, nostiprināsim “kāpēc”. Moduļu validācija nav tikai birokrātisks solis; tas ir profesionālas programmatūras inženierijas pamatpīlārs. Globālai auditorijai, kur sadarbība notiek asinhroni un dažādās laika joslās, skaidrība un standartu ievērošana kļūst vēl kritiskāka.

1. Koda uzturamības un lasāmības uzlabošana

Labi validēti moduļi ir vieglāk saprotami, modificējami un atkļūdojami. Kad moduļi ievēro noteiktus modeļus un piedāvā skaidras saskarnes, izstrādātāji no dažādām kultūras vidēm un ar dažādu pieredzes līmeni var ar lielāku pārliecību dot savu ieguldījumu kodu bāzē. Tas ievērojami samazina kognitīvo slodzi, uzņemot jaunus komandas locekļus vai nododot uzdevumus starp reģioniem.

2. Izpildlaika kļūdu un defektu novēršana

Nepareizi strukturēti vai nepareizi eksportēti moduļi var novest pie smalkām un kaitinošām izpildlaika kļūdām. Moduļu validācija darbojas kā proaktīva aizsardzība, atklājot šīs problēmas agrīnā izstrādes ciklā, bieži vien pirms kods pat nonāk testēšanas vidēs. Tas ir īpaši svarīgi sadalītām komandām, kur kļūdu labošanas izmaksas eksponenciāli pieaug ar katru izvietošanas posmu.

3. Atkārtotas lietojamības un konsekvences veicināšana

Modulārā dizaina būtība ir atkārtota lietojamība. Validācija nodrošina, ka moduļi ir izstrādāti kā autonomi, ar labi definētām atkarībām un izvadiem. Šī konsekvence starp moduļiem veicina atkārtoti lietojamu komponentu veidošanas kultūru, kas noved pie ātrākiem izstrādes cikliem un saskaņotākas lietojumprogrammas arhitektūras, neatkarīgi no tā, kur notiek izstrāde.

4. Sadarbības un komunikācijas uzlabošana

Kad moduļi tiek validēti atbilstoši saskaņotiem noteikumiem un konvencijām, tie kalpo kā kopīga valoda izstrādes komandai. Šī kopīgā izpratne samazina pārpratumus un veicina vienmērīgāku sadarbību, īpaši attālinātos apstākļos, kur tiešā komunikācija ir ierobežota. Izstrādātāji var paļauties uz validācijas procesu, lai ieviestu standartus, minimizējot debates par stilistiskām preferencēm vai strukturālām pieejām.

5. Drošības stiprināšana

Lai gan tas nav galvenais mērķis, moduļu validācija var netieši veicināt drošību, nodrošinot, ka moduļi neatklāj neparedzētas funkcionalitātes vai atkarības, kuras varētu tikt izmantotas. Pareizi definēti un validēti moduļi ir mazāk pakļauti ievainojamību ieviešanai.

Izpratne par JavaScript moduļu sistēmām

Lai efektīvi validētu JavaScript moduļus, ir svarīgi izprast dominējošās moduļu sistēmas. Katrai sistēmai ir savas nianses, kuras validācijas rīkiem un praksēm ir jāņem vērā.

1. CommonJS

De facto standarts serveru puses JavaScript, īpaši Node.js vidēs. CommonJS izmanto sinhronu, uz `require()` balstītu sintaksi moduļu importēšanai un `module.exports` vai `exports` to eksportēšanai.

Piemērs:

            // math.js
const add = (a, b) => a + b;
module.exports = { add };

// app.js
const math = require('./math');
console.log(math.add(5, 3)); // Output: 8
            

              
                Copy
              
            
          

Validācija CommonJS bieži koncentrējas uz to, lai nodrošinātu, ka `require()` ceļi ir pareizi, ka eksportētie objekti ir strukturēti kā paredzēts un ka nav apļveida atkarību, kas rada problēmas.

2. ECMAScript moduļi (ESM)

Oficiālais JavaScript moduļu standarts, ieviests ar ES6 (ECMAScript 2015). ESM izmanto deklaratīvu, asinhronu `import` un `export` sintaksi. Tas kļūst arvien izplatītāks gan front-end (izmantojot tādus rīkus kā Webpack, Rollup), gan back-end (Node.js atbalsts kļūst nobriedušāks) izstrādē.

Piemērs:

            // utils.js
export const multiply = (a, b) => a * b;

// main.js
import { multiply } from './utils';
console.log(multiply(4, 6)); // Output: 24
            

              
                Copy
              
            
          

Validācija ESM parasti ietver importa/eksporta priekšrakstu pārbaudi, nodrošinot, ka nosauktie eksporti atbilst to deklarācijām, un moduļu asinhronās ielādes apstrādi.

3. AMD (Asinhronā moduļu definīcija)

Lai gan jaunākos projektos retāk sastopams, AMD bija populārs front-end izstrādē, īpaši ar tādām bibliotēkām kā RequireJS. Tas izmanto asinhronu definīcijas sintaksi.

Piemērs:

            // calculator.js
define(['dependency1', 'dependency2'], function(dep1, dep2) {
  return {
    subtract: function(a, b) {
      return a - b;
    }
  };
});

// main.js
require(['calculator'], function(calc) {
  console.log(calc.subtract(10, 4)); // Output: 6
});
            

              
                Copy
              
            
          

Validācija AMD varētu koncentrēties uz pareizu `define` funkcijas struktūru, atkarību masīviem un atzvanīšanas parametriem.

JavaScript moduļu validācijas pamatmetodes

Efektīva moduļu validācija ir daudzpusīga pieeja, kas apvieno statisko analīzi, automatizēto testēšanu un labāko prakšu ievērošanu. Globālām komandām galvenais ir izveidot konsekventu procesu visos izstrādes centros.

1. Lintēšana

Lintēšana ir process, kurā statiski analizē kodu, lai identificētu stilistiskas kļūdas, potenciālas programmēšanas kļūdas un aizdomīgas konstrukcijas. Lintēšanas rīki var ieviest noteikumus, kas saistīti ar moduļu importēšanu, eksportēšanu un kopējo koda struktūru.

Populāri lintēšanas rīki:

• ESLint: Visplašāk izmantotais un ļoti konfigurējamais JavaScript lintēšanas rīks. ESLint var konfigurēt ar specifiskiem noteikumiem, lai ieviestu moduļu konvencijas, piemēram, aizliedzot aizstājējzīmju importus, nodrošinot konsekventus eksporta stilus vai atzīmējot neizmantotos mainīgos moduļos. Tā spraudņu arhitektūra ļauj izveidot pielāgotus noteikumus, kas pielāgoti konkrētām projekta vajadzībām vai komandas vienošanās. Globālām komandām kopīga ESLint konfigurācija nodrošina vienotu kodēšanas standartu visiem dalībniekiem.
• JSHint/JSLint: Vecāki, bet joprojām funkcionāli lintēšanas rīki, kas ievieš stingrāku kodēšanas noteikumu kopumu. Lai gan tie ir mazāk elastīgi nekā ESLint, tie joprojām var atklāt pamata strukturālās problēmas.

Kā lintēšana palīdz moduļu validācijā:

• Importa/eksporta sintakses pārbaudes: Nodrošina, ka `import` un `require` priekšraksti ir pareizi formatēti un ka moduļi tiek eksportēti kā paredzēts.
• No-Unused-Vars/No-Unused-Modules: Identificē eksportus, kas netiek importēti, vai mainīgos modulī, kas nekad netiek izmantoti, veicinot tīrāku un efektīvāku kodu.
• Moduļu robežu ieviešana: Var iestatīt noteikumus, lai novērstu tiešu DOM manipulāciju Node.js moduļos vai lai ieviestu konkrētus veidus, kā importēt trešo pušu bibliotēkas.
• Atkarību pārvaldība: Daži ESLint spraudņi var palīdzēt identificēt potenciālas problēmas ar moduļu atkarībām.

Globālas ieviešanas padoms:

Uzturiet centralizētu `.eslintrc.js` (vai līdzvērtīgu) failu savā repozitorijā un nodrošiniet, ka visi izstrādātāji to izmanto. Integrējiet ESLint savās integrētajās izstrādes vidēs (IDE) un savos nepārtrauktās integrācijas/nepārtrauktās piegādes (CI/CD) konveijeros. Tas garantē, ka lintēšanas pārbaudes tiek veiktas konsekventi katrai izmaiņai, neatkarīgi no izstrādātāja atrašanās vietas.

2. Statiskā tipu pārbaude

Lai gan JavaScript ir dinamiski tipizēts, statiskie tipu pārbaudītāji var ievērojami uzlabot koda kvalitāti un samazināt kļūdas, pārbaudot tipu konsekvenci pāri moduļu robežām pirms izpildlaika.

Populāri statiskie tipu pārbaudītāji:

• TypeScript: JavaScript virs-kopa, kas pievieno statisko tipizēšanu. TypeScript kompilatori pārbauda tipu kļūdas būvēšanas procesa laikā. Tas ļauj definēt saskarnes jūsu moduļiem, norādot datu tipus, ko tie sagaida kā ievadi, un datu tipus, ko tie atgriež. Tas ir nenovērtējami lielām, sadalītām komandām, kas strādā pie sarežģītām kodu bāzēm.
• Flow: Facebook izstrādāts, Flow ir vēl viens statiskais tipu pārbaudītājs JavaScript, ko var pieņemt pakāpeniski.

Kā statiskā tipu pārbaude palīdz moduļu validācijā:

• Saskarnes ieviešana: Nodrošina, ka funkcijas un klases moduļos atbilst to definētajām signatūrām, novēršot tipu neatbilstības, kad moduļi mijiedarbojas.
• Datu integritāte: Garantē, ka dati, kas tiek nodoti starp moduļiem, atbilst gaidītajiem formātiem, samazinot datu bojājumu problēmas.
• Uzlabota automātiskā pabeigšana un refaktorēšana: Tipu informācija uzlabo izstrādātāju rīkus, padarot vieglāku koda izpratni un refaktorēšanu, kas ir īpaši noderīgi attālinātām komandām, kas strādā ar lielām kodu bāzēm.
• Agrīna kļūdu atklāšana: Atklāj ar tipiem saistītas kļūdas kompilēšanas laikā, kas ir daudz agrāks un lētāks punkts izstrādes dzīves ciklā nekā izpildlaiks.

Globālas ieviešanas padoms:

Pieņemiet TypeScript vai Flow kā projekta mēroga standartu. Nodrošiniet skaidru dokumentāciju par to, kā definēt moduļu saskarnes, un integrējiet tipu pārbaudi būvēšanas procesā un CI/CD konveijeros. Regulāras apmācības sesijas var palīdzēt izstrādātājiem visā pasaulē apgūt statiskās tipizēšanas prakses.

3. Vienību un integrācijas testēšana

Kamēr statiskā analīze atklāj problēmas pirms izpildlaika, testēšana pārbauda moduļu faktisko uzvedību. Gan vienību testi (testējot atsevišķus moduļus izolēti), gan integrācijas testi (testējot, kā moduļi mijiedarbojas) ir izšķiroši.

Populāri testēšanas ietvari:

• Jest: Populārs JavaScript testēšanas ietvars, kas pazīstams ar savu lietošanas vienkāršību, iebūvēto apgalvojumu bibliotēku un imitēšanas (mocking) iespējām. Jest momentuzņēmumu testēšanas un koda pārklājuma funkcijas ir īpaši noderīgas moduļu validācijai.
• Mocha: Elastīgs un funkcijām bagāts JavaScript testēšanas ietvars, ko var izmantot ar dažādām apgalvojumu bibliotēkām (piem., Chai) un imitēšanas rīkiem.
• Cypress: Galvenokārt "end-to-end" testēšanas ietvars, bet to var izmantot arī moduļu mijiedarbības integrācijas testēšanai pārlūkprogrammas vidē.

Kā testēšana palīdz moduļu validācijā:

• Uzvedības pārbaude: Nodrošina, ka moduļi darbojas kā paredzēts saskaņā ar to specifikācijām, ieskaitot robežgadījumus un kļūdu nosacījumus.
• Līguma testēšana: Integrācijas testi darbojas kā līguma testēšanas forma starp moduļiem, pārbaudot, ka to saskarnes paliek saderīgas.
• Regresijas novēršana: Testi kalpo kā drošības tīkls, nodrošinot, ka izmaiņas vienā modulī nejauši nesabojā atkarīgos moduļus.
• Pārliecība par refaktorēšanu: Visaptverošs testu komplekts dod izstrādātājiem pārliecību refaktorēt moduļus, zinot, ka testi ātri atklās jebkādas ieviestās regresijas.

Globālas ieviešanas padoms:

Izveidojiet skaidru testēšanas stratēģiju un veiciniet uz testiem balstītu izstrādi (TDD) vai uz uzvedību balstītu izstrādi (BDD). Nodrošiniet, ka testu komplekti ir viegli palaižami lokāli un ka tie tiek izpildīti automātiski kā daļa no CI/CD konveijera. Dokumentējiet gaidāmos testu pārklājuma līmeņus. Apsveriet iespēju izmantot rīkus, kas atvieglo starppārlūku vai starpvides testēšanu front-end moduļiem.

4. Moduļu apvienotāji un to validācijas spējas

Moduļu apvienotāji, piemēram, Webpack, Rollup un Parcel, spēlē būtisku lomu mūsdienu JavaScript izstrādē, īpaši front-end lietojumprogrammām. Tie apstrādā moduļus, atrisina atkarības un iepako tos optimizētos paketēs. Šī procesa laikā tie veic arī pārbaudes, kuras var uzskatīt par validācijas veidu.

Kā apvienotāji palīdz moduļu validācijā:

• Atkarību atrisināšana: Apvienotāji nodrošina, ka visas moduļu atkarības ir pareizi identificētas un iekļautas galīgajā paketē. Kļūdas `import`/`require` ceļos bieži tiek atklātas šeit.
• "Mirušā koda" likvidēšana (Tree Shaking): Apvienotāji var identificēt un noņemt neizmantotus eksportus no moduļiem, nodrošinot, ka galīgajā izvadē tiek iekļauts tikai nepieciešamais kods, kas ir validācijas forma pret nevajadzīgu uzpūšanos.
• Sintakses un moduļu formāta transformācija: Tie var transformēt dažādus moduļu formātus (piemēram, CommonJS uz ESM vai otrādi) un nodrošināt saderību, procesā atklājot sintakses kļūdas.
• Koda sadalīšana: Lai gan galvenokārt optimizācijas tehnika, tā balstās uz moduļu robežu izpratni, lai efektīvi sadalītu kodu.

Globālas ieviešanas padoms:

Standartizējiet moduļu apvienotāju savam projektam un konfigurējiet to konsekventi visās izstrādes vidēs. Integrējiet apvienošanas procesu savā CI/CD konveijerā, lai agri atklātu būvēšanas laika kļūdas. Dokumentējiet būvēšanas procesu un jebkuras specifiskas konfigurācijas, kas saistītas ar moduļu apstrādi.

5. Koda pārskatīšana

Cilvēka uzraudzība joprojām ir neaizstājama kvalitātes nodrošināšanas daļa. Kolēģu koda pārskatīšana nodrošina validācijas slāni, ko automatizētie rīki nevar pilnībā aizstāt.

Kā koda pārskatīšana palīdz moduļu validācijā:

• Arhitektūras ievērošana: Pārskatītāji var novērtēt, vai jauni moduļi atbilst kopējai lietojumprogrammas arhitektūrai un noteiktajiem dizaina modeļiem.
• Biznesa loģikas validācija: Viņi var pārbaudīt loģikas pareizību modulī, nodrošinot, ka tā atbilst biznesa prasībām.
• Lasāmības un uzturamības pārbaudes: Pārskatītāji var sniegt atsauksmes par koda skaidrību, nosaukumu konvencijām un kopējo uzturamību – aspektiem, kas ir būtiski globālai sadarbībai.
• Zināšanu apmaiņa: Koda pārskatīšana ir lieliska iespēja izstrādātājiem no dažādām komandām un reģioniem dalīties zināšanās un labākajās praksēs.

Globālas ieviešanas padoms:

Izveidojiet skaidru koda pārskatīšanas procesu ar noteiktām gaidām gan pārskatītājiem, gan autoriem. Izmantojiet versiju kontroles sistēmu funkcijas (piem., GitHub Pull Requests, GitLab Merge Requests), kas atvieglo strukturētu pārskatīšanu. Veiciniet asinhronu pārskatīšanu, lai pielāgotos dažādām laika joslām, bet apsveriet arī sinhronas pārskatīšanas sesijas kritiskām izmaiņām vai zināšanu nodošanai.

Labākās prakses globālām moduļu validācijas stratēģijām

Efektīvas moduļu validācijas ieviešana globālā komandā prasa stratēģisku un konsekventu pieeju. Šeit ir dažas labākās prakses:

1. Izveidojiet skaidrus kodēšanas standartus un vadlīnijas

Definējiet visaptverošu stila rokasgrāmatu un kodēšanas konvenciju kopumu, kas jāievēro visiem komandas locekļiem. Tas ietver noteikumus par moduļu nosaukumiem, eksporta/importa sintaksi, failu struktūru un dokumentāciju. Tādi rīki kā ESLint, Prettier (koda formatēšanai) un TypeScript spēlē būtisku lomu šo standartu ieviešanā.

2. Centralizējiet konfigurāciju

Nodrošiniet, ka visi konfigurācijas faili lintēšanas rīkiem, formatētājiem, tipu pārbaudītājiem un būvēšanas rīkiem tiek glabāti centrālā repozitorijā (piem., `.eslintrc.js`, `tsconfig.json`, `webpack.config.js`). Tas novērš neatbilstības un nodrošina, ka visi strādā ar vienādiem noteikumiem.

3. Automatizējiet visu CI/CD konveijerā

Jūsu CI/CD konveijeram ir jābūt koda kvalitātes vārtsargam. Automatizējiet lintēšanu, tipu pārbaudi, vienību testēšanu un būvēšanas procesus. Jebkurai kļūmei šajos posmos ir jānovērš koda apvienošana vai izvietošana. Tas nodrošina, ka kvalitātes pārbaudes tiek veiktas konsekventi un neatkarīgi no manuālas iejaukšanās, kas ir būtiski sadalītām komandām.

4. Veiciniet īpašumtiesību un atbildības kultūru

Mudiniet visus komandas locekļus, neatkarīgi no viņu atrašanās vietas vai pieredzes, uzņemties atbildību par koda kvalitāti. Tas ietver testu rakstīšanu, aktīvu piedalīšanos koda pārskatīšanā un bažu izteikšanu par potenciālām problēmām.

5. Nodrošiniet visaptverošu dokumentāciju

Dokumentējiet savas moduļu sistēmas izvēles, kodēšanas standartus, validācijas procesus un to, kā iestatīt izstrādes vidi. Šai dokumentācijai jābūt viegli pieejamai visiem komandas locekļiem un jākalpo kā atsauces punktam labākajām praksēm.

6. Nepārtraukta mācīšanās un pielāgošanās

JavaScript ekosistēma strauji attīstās. Regulāri pārskatiet un atjauniniet savus validācijas rīkus un stratēģijas, lai iekļautu jaunas labākās prakses un risinātu jaunus izaicinājumus. Nodrošiniet apmācības un resursus, lai palīdzētu savai globālajai komandai būt lietas kursā.

7. Izmantojiet monorepozitorijus (ja piemēroti)

Projektiem ar vairākiem saistītiem moduļiem vai paketēm apsveriet iespēju izmantot monorepozitorija struktūru ar rīkiem, piemēram, Lerna vai Nx. Šie rīki var palīdzēt pārvaldīt atkarības, palaist skriptus vairākās paketēs un ieviest konsekvenci lielā, sadalītā kodu bāzē.

Biežākās kļūdas un kā no tām izvairīties

Pat ar labākajiem nodomiem globālās izstrādes komandas var saskarties ar kļūdām moduļu validācijā.

1. Nekonsekventi rīki dažādās vidēs

Problēma: Izstrādātāji, kas izmanto dažādas rīku versijas vai nedaudz atšķirīgas konfigurācijas, var radīt atšķirīgus rezultātus validācijas pārbaudēs.

Risinājums: Standartizējiet konkrētas Node.js, npm/yarn un visu izstrādes rīku versijas. Izmantojiet bloķēšanas failus (`package-lock.json`, `yarn.lock`), lai nodrošinātu konsekventas atkarību versijas visās mašīnās un CI/CD konveijerā.

2. Nepietiekams testu pārklājums

Problēma: Paļaušanās tikai uz lintēšanu un tipu pārbaudi bez adekvāta testu pārklājuma atstāj funkcionālus defektus neatklātus.

Risinājums: Definējiet skaidrus mērķa koda pārklājuma rādītājus un ieviesiet tos savā CI konveijerā. Mudiniet rakstīt testus visām jaunajām funkcijām un kļūdu labojumiem un nodrošiniet, ka testi aptver robežgadījumus un potenciālos kļūmju režīmus.

3. Pārmērīga paļaušanās uz manuāliem procesiem

Problēma: Paļaušanās uz to, ka izstrādātāji manuāli palaidīs pārbaudes vai veiks rūpīgu pārskatīšanu bez automatizācijas, ir kļūdaina un nekonsekventa.

Risinājums: Automatizējiet pēc iespējas vairāk validācijas soļu CI/CD konveijerā. Koda pārskatīšanai ir jāpapildina, nevis jāaizstāj automatizētās pārbaudes.

4. Moduļu sistēmas specifikas ignorēšana

Problēma: Validācijas noteikumu, kas paredzēti CommonJS, piemērošana ESM projektiem vai otrādi, var novest pie nepareizām pārbaudēm vai nepamanītām kļūdām.

Risinājums: Izprotiet izmantotās moduļu sistēmas specifiskās prasības un konvencijas un attiecīgi konfigurējiet savus validācijas rīkus. Piemēram, ESLint ir specifiski noteikumi ESM.

5. Slikti definētas moduļu saskarnes

Problēma: Moduļus ar netiešām atkarībām vai neskaidrām atgrieztajām vērtībām ir grūti validēt un testēt.

Risinājums: Izmantojiet TypeScript vai JSDoc, lai skaidri definētu savu moduļu gaidāmās ievades un izvades. Dokumentējiet katras eksportētās entītijas mērķi un lietojumu.

Noslēgums: uzticības veidošana jūsu kodu bāzē

JavaScript moduļu validācija nav vienreizējs uzdevums, bet gan pastāvīga apņemšanās nodrošināt koda kvalitāti. Globālām izstrādes komandām stabilu validācijas procesu izveide un uzturēšana ir būtiska, lai veidotu uzticamas, uzturamas un mērogojamas lietojumprogrammas. Apvienojot automatizētus rīkus (lintēšanu, statisko tipizēšanu, testēšanu) un stingrus procesus (koda pārskatīšanu, skaidras vadlīnijas), jūs varat veicināt kvalitātes kultūru, kas pārsniedz ģeogrāfiskās robežas.

Ieguldījums JavaScript moduļu validācijā nozīmē ieguldījumu jūsu projekta ilgtermiņa veselībā, samazinot izstrādes berzi un galu galā piegādājot labāku programmatūru saviem lietotājiem visā pasaulē. Tas ir par uzticības veidošanu – uzticību jūsu kodam, uzticību jūsu komandai un uzticību kolektīvajai spējai radīt izcilu programmatūru, neatkarīgi no tā, kur atrodas izstrādātāji.