Zašto je važno da kompanije otvore svoj kod — Benefiti i dobre prakse open-source projekata

Većina softverskih kompanija svoje proizvode zasniva na korišćenju open-source biblioteka koje olakšavaju implementaciju nekih opštih aspekata razvoja aplikacije koji se ponavljaju iz projekta u projekat. Open-source nudi luksuz u vidu biblioteka svakojake namene, počevši od usko specijalizovanih biblioteka za manipulaciju datumima, filtriranje i validaciju podataka, preko HTTP klijenata, ORM-ova, do full-stack frameworka.

S druge strane, prava je retkost da se softverska kompanija odluči da objavi i podeli rešenja, alate i biblioteke tog tipa u vidu sopstvenih open-source projekata.

Benefiti

• Poboljšana reputacija kompanije
  Za softverske kompanije, veoma je važno da budu cenjene ne samo zbog proizvoda koji prave, već i zbog kvaliteta softvera koji stoji iza tog proizvoda. Jedan od načina za dokazivanje je upravo razvoj korisnih i kvalitetnih softverskih komponenti i njihovo deljenje sa zajednicom. Time između ostalog kompanija postaje magnet za vrhunske programere i inženjere kojima je stalo da rade u sredinama koje gaje i promovišu takvu kulturu.
• Poboljšan kvalitet proizvoda
  Izdvajanje različitih komponenti sistema u manje, nezavisne i testabilne celine omogućava njihovo iskorišćenje između projekata (reusability), ali i rezultuje povećanom pokrivenošću testovima na nivou čitavog sistema, pod pretpostavkom da će izdvojene komponente biti u potpunosti pokrivene unit testovima.
• Okruženje koje stimuliše lični razvoj programera
  Uključivanjem u razvoj open-source projekata, programeri unapređuju svoje veštine trudeći se da pišu kvalitetan i testabilan kôd, istovremeno podižući svoju reputaciju i prisustvo u zajednici. Ovo je važno sa stanovišta šansi za zapošljavanje, imajući u vidu da je sve više kompanija koje, umesto CV-a, od svojih kandidata traže isključivo link do GitHub profila.

Neophodni elementi

Kreiranje organizacije na GitHubu i izdvajanje reusable delova monolitnog koda u nezavisne repozitorijume deluje kao sve što je neophodno za upuštanje u open-source avanturu, ali postoje standardi i prakse koje treba ispoštovati, kao i detalji na koje treba obratiti pažnju kako bi celokupan poduhvat bio sproveden na profesionalan i kvalitetan način.

Neke od stvari koje će biti pokrivene su specifične za razvoj open-source biblioteka, ali mnogo je više onih koje se podrazumevaju za bilo koji drugi kontekst.

Kompanija u kojoj radim — Arbor, svoja rešenja bazira na PHP-u i srodnim tehnologijama, te će neki od saveta i primera u nastavku biti specifični za taj ekosistem, ali dovoljno opšti da mogu biti shvaćeni i primenjeni bez obzira na tehnologiju.

Standard kodiranja

Prva stvar koja upada u oči je formatiranje koda. Baš kao i nemarno opran pribor za jelo u restoranu, neuredan i nekonzistentan kôd daje loš signal onome ko namerava da koristi ili radi sa projektom u kojem preovlađuje takav kôd.

U PHP ekosistemu postoje opšteprihvaćeni standardi kodiranja — PSR-1 i PSR-2, definisani od strane PHP-FIG, organizacije koja predlaže i usvaja standarde specifične za PHP programski jezik. Pored pravila koja nameću ovi standardi, postoje mnogi drugi elementi stilizovanja koda za koje bi trebalo da postoji konsenzus oko načina njihovog pisanja, kao na primer long ili short notacija na nizove. Alati kao što su PHP-CS-Fixer olakšavaju uspostavljanje i održavanje standarda kodiranja definisanih u okviru PSR-1 i PSR-2 dokumenata, ali i mnogih drugih pravila.

Da li ćete koristiti PSR standarde ili ne, stvar je izbora i ličnih preferencija. Suština je da definišite i usvojite jedan standard kodiranja kojeg ćete se strogo pridržavati kako bi kôd koji pišete bio konzistentan. Homogen kôd je osnovni preduslov za razvoj kvalitetnih i održivih projekata.

Testovi

Postojanje automatizovanih testova u okviru vaše biblioteke je potvrda ispravnosti kôda i pokazatelj da zagovarate primenjivanje te nužne prakse.

PHPUnit je najpopularniji PHP framework za pisanje unit testova, inspirisan xUnit porodicom alata iste namene.

Stoprocentna pokrivenost kôda testovima svakako treba da bude krajnji cilj, ali ta metrika ne govori ništa o vrednosti samih testova. Umesto da veštački povećavate pokrivenost testovima, fokusirajte se na ispitavanje različitih slučajeva izvršavanja vašeg kôda, vodite računa da testovi budu izolovani i nezavisni, testirajte isključivo stvari koje su u vašem vlasništu, održavajte brzinu izvršavanja testova na visokom nivou.

Kvalitet koda

Poslednja, ali ujedno i najvažnija i verovatno najkompleksnija stavka koja se tiče kodiranja jeste pitanje kvaliteta koda. Mnogo bitnije od toga da li je kôd lepo formatiran jeste da li je on razumljiv, jednostavan za održavanje i proširivanje, testabilan. U svetu programiranja, postoje ustaljeni principi i prakse za postizanje visokog kvaliteta koda.

SOLID je osnovni set principa objektno-orijentisanog dizajna čijom se primenom značajno unapređuje održivost i proširivost sistema koji se razvija.

Manje poznat, ali vrlo koristan princip je Object Calisthenics — set pravila koja za cilj imaju čitljiv, održiv i razumljiv kôd. Jedan nivo uvlačenja unutar metoda, nekorišćenje ELSE ključne reči, klase dužine do 50 linija koda, nekorišćenje getter i setter metoda, samo su neka od pravila definisana u okviru ovog principa.

Budući da će vaša open-source biblioteka biti javno dostupna, korišćena i eventualno proširivana od strane programera koji su se odlučili da je koriste, potrudite se da njen kôd bude vrhunskog kvaliteta.

Dokumentacija

Činjenica je da programeri ne vole da pišu dokumentaciju, ali baš kao što su se autori vama omiljenih biblioteka potrudili da kvalitetnom dokumentacijom dostave uputstva za korišćenje, od vas se očekuje da uzvratite istom merom.

U najmanju ruku, repozitorijum vaše biblioteke treba da sadrži README fajl sa osnovnim informacijama o njenoj nameni i primerima za korišćenje.

Licenca

Licenca definiše odgovornosti koje preuzima neko ko namerava da koristi i/ili modifikuje vaš open-source proizvod, te je izbor odgovarajuće licence ključan sa stanovišta održavanja softvera na način koji vama najviše odgovara. Osnovna preporuka je korišćenje samo onih licenci koju su odobrene od strane Open Source Initiative (OSI) korporacije.

Continuous Integration

Velika je šansa da će biblioteku održavati ne jedan već nekoliko programera ili čak manji tim. Iz tog razloga, bitno je uspostavljanje efikasnog načina rada koji obezbeđuje glatku saradnju, ali i kontrolu ispravnosti i kvaliteta same biblioteke.

Travis CI je verovatno najpopularniji i najkorišćenji servis za uspostavljanje procesa kontrole u slučaju open-source projekata. U pitanju je hosted Continuous Integration servis za build i testiranje softvera. U potpunosti je besplatan za open-source projekate, što je verovatno jedan od glavnih razloga za njegovu veliku popularnost.

Scrutinizer je još jedan sjajan servis koji omogućava kontinuirano merenje i praćenje kvaliteta kôda. Scrutinizer u velikoj meri pojednostavljuje, a u nekim situacijama i zamenjuje code review, tačnije proveru osnovnih aspekata kvaliteta i ispravnosti koda, koji ne podrazumevaju sam domen vašeg projekta. Dosta jednostavno se integriše sa Travisom, pa je uz kombinaciju sa izvršavanjem testova moguće uspostaviti zaokružen i kontinuiran proces kontrole statusa i kvaliteta vaše biblioteke.

Releases

Vaš open-source projekat će se menjati vremenom, bilo kroz ispravke, unapređenja ili nove funkcionalnosti. S toga je vrlo bitno da korisnicima omogućite jednostavno i bezbolno ažuriranje biblioteke.

Composer je de facto standardni menadžer paketa u PHP svetu, koji omogućava jednostavnu manipulaciju (instalaciju/ažuriranje) biblioteka koje se koriste u okviru projekta. Sve što je neophodno da vašu biblioteku učinite kompatibilnom sa Composerom jeste da je održavate u skladu sa pravilima i instrukcijama koje on nalaže. Ukratko, proces se svodi postavljanje composer.json konfiguracije, tagovanje release-ova vaše biblioteke na GitHub-u i sinhronizacija sa Packagistom, podrazumevanim repozitorijumom paketa.

Pri objavi novih verzija, vodite računa da to bude u skladu sa semantičkim verzionisanjem. Niko ne voli kada regularno ažuriranje paketa prouzrokuje greške u aplikaciji, pojava poznatija kao backward-compatibility (BC) break.

Takođe je poželjno da održavate tzv. changelog fajl u okviru projekta kako bi vaši korisnici bili upućeni u novine i izmene koje pravite tokom razvoja vaše biblioteke. Keep a Changelog format je opšta preporuka za ovaj tip fajla.

PHP Package Skeleton

Prethodno navedene stavke se ponavljaju iz projekta u projekat i razlike u njihovom konfigurisanju su minorne ili ih uopšte nema. Kako bi stvari bile konzistentne, ali i sa ciljem lakšeg započinjanja, upravljanja i održavanja open-source biblioteka koje u budućnosti budu razvijane i objavljivane u okviru Arbor kompanije, kreirali smo PHP Package Skeleton projekat. Pored šablona za strukturu samog projekta, skeleton sadrži Travis CI i Scrutinizer konfiguracije, zatim PHP-CS Fixer i PHPUnit konfiguracije, kao i sve ostalo što je neophodno za dostojnu PHP biblioteku.

Završne misli

Open-source doprinos je samo jedan od načina na koji kompanija može da pokaže podršku programerskoj zajednici. Činjenica je da što više softverska kompanija podržava programersku zajednicu, njen proizvod postaje bolji. Ako date malo, možete dobiti mnogo više zauzvrat.

Ekipa iz Arbora ima u planu i dodatno širenje, a trenutno zapošljavaju Senior JavaScript inženjera.