Prakse efikasnog programiranja

Efikasno programiranje ne znači pisanje što manje linija koda ili korišćenje najdovitljivijih apstrakcija. Radi se o promišljenim tehničkim odlukama koje služe proizvodu na duge staze. Za nas to znači nekoliko stvari.

Pravilna arhitektura od samog početka. Pre nego što napišemo ijednu liniju koda, razmišljamo o tome kako će aplikacija rasti. Koristimo obrasce poput servisnih klasa, slojeva repozitorijuma i arhitekture vođene događajima u Laravelu kako bismo održali organizovanost baze koda tokom njenog rasta. Dobro strukturirana aplikacija sa 10.000 linija koda i dalje je upravljiva sa 100.000 linija.

Praćenje konvencija frejmvorka. Laravel i React imaju jasne stavove o tome kako kod treba da bude organizovan. Mi pratimo te konvencije umesto da se borimo protiv njih. Time naš kod postaje predvidiv za svakog programera koji poznaje ove frejmvorke, što je važno kada vaš tim raste ili kada angažujete dodatnu pomoć.

Statička analiza i tipska bezbednost. Na PHP strani koristimo PHPStan da uhvatimo čitave kategorije grešaka pre nego što se kod uopšte pokrene. PHPStan analizira bazu koda i označava neusklađenosti tipova, nedefinisane metode i logičke greške koje bi se inače pojavile tek u produkciji. Na klijentskoj strani pišemo React aplikacije u TypeScript-u umesto u čistom JavaScript-u. TypeScript dodaje sistem tipova koji refaktorisanje čini bezbednijim, automatsko dopunjavanje pametnijim, a greške teže za uvođenje. Zajedno, PHPStan i TypeScript nam daju sigurnost da promene u jednom delu sistema ne kvare nešto drugo.

Automatizovano testiranje. Pišemo testove za kritičnu poslovnu logiku, API krajnje tačke i tačke integracije. Testovi nisu dodatni posao koji nas usporava. Oni su ono što nam omogućava da isporučujemo nove funkcionalnosti sa sigurnošću, znajući da nismo pokvarili nešto drugo u procesu. Koristimo PHPUnit i Pest za Laravel, a Jest za React aplikacije.

Pregled koda. Svaki deo koda koji ide u produkciju pregleda drugi programer iz našeg tima. Ovo nije formalnost. Tu hvatamo greške, diskutujemo o alternativnim pristupima i delimo znanje unutar tima.

Za veće aplikacije i kompanije koje očekuju značajan rast, često preporučujemo arhitekturu modularnog monolita. To je srednje rešenje između tradicionalnog monolita i potpune mikroservisne arhitekture. Aplikacija se pokreće kao jedna celina za postavljanje, ali je interno organizovana u jasno razdvojene module sa definisanim granicama.

Svaki modul ima svoju poslovnu logiku, tabele baze podataka i API površinu. Moduli komuniciraju kroz jasno definisane interfejse, a ne posezanjem u unutrašnjost jedni drugima. To znači da dobijate jednostavnost postavljanja i upravljanja jednom aplikacijom, uz dovoljno organizovanu bazu koda da više timova može da radi na različitim modulima bez međusobnog ometanja.

Praktična prednost je u tome što izbegavate operativnu složenost mikroservisa (zasebna postavljanja, otkrivanje servisa, distribuirano praćenje, mrežno kašnjenje između servisa), a i dalje dobijate čisto razdvajanje nadležnosti. Ako modul na kraju treba da postane zaseban servis, granice su već postavljene. Laravel-ov ekosistem modula i paketa dobro podržava ovaj obrazac.

Svaki projekat vremenom akumulira određeni tehnički dug. Pitanje je da li njime upravljate namerno ili ga pustite da se gomila dok ceo sistem ne postane krhak.

Mi pratimo tehnički dug eksplicitno. Kada napravimo prečicu da bismo ispunili rok, dokumentujemo šta je urađeno i šta treba poboljšati kasnije. U svakom razvojnom ciklusu izdvajamo vreme za rešavanje najkritičnijih stavki tehničkog duga, tako da baza koda ostaje zdrava tokom celokupnog trajanja projekta.

Pišemo dokumentaciju koja je korisna, a ne dokumentaciju koja samo ispunjava formalnost. To znači jasne README fajlove koji objašnjavaju kako da se projekat postavi i pokrene, komentare u kodu za složenu poslovnu logiku i API dokumentaciju koja je usklađena sa stvarnim kodom.

Za veće projekte vodimo zapise o arhitektonskim odlukama koji objašnjavaju zašto su donete određene tehničke odluke. Ovo je posebno dragoceno kada se članovi tima menjaju ili kada se vraćate na odluke donete mesecima ranije.

Softver pravimo sa razumevanjem da neko drugi možda treba da radi na njemu posle nas. Bilo da planirate da formirate interni tim, angažujete drugu agenciju ili nastavite da radite sa nama godinama, kod koji isporučujemo treba da bude razumljiv svakom kompetentnom programeru koji poznaje Laravel i React.

To znači dosledne konvencije imenovanja, logičnu organizaciju fajlova, odsustvo magičnih stringova ili fiksno unetih vrednosti, i paket testova koji služi kao živa dokumentacija o tome kako sistem funkcioniše.

Predali smo projekte internim timovima u Nemačkoj, Holandiji i Skandinaviji, i povratne informacije su uvek iste: kod je čist, dobro organizovan i lak za razumevanje i preuzimanje. To je standard koji postavljamo na svakom projektu.