TheCodestReview #5 - divreiz nedēļā programmatūras inženierijas sula

Pēdējā epizodē es esmu uzjautrinājis komentēt rakstu par humora nozīmi darbavietā, bet tikmēr es sapratu, ka tas ir pelnījis daudz lielāku atzinību, tāpēc es drīzumā par to uzrakstīšu veselu bloga ierakstu.    

Lietas, kas mani nodarbināja pēdējo pāris nedēļu laikā: 

a) Pirms Ziemassvētkiem es sāku ar pirmizrādi epizode “Bulletproof CTO” semināru sērija (sekojiet līdzi 2. epizodei februārī, kurā būs iekļauta SaaS CTOs, sīkāka informācija drīzumā būs pieejama manā LinkedIn).

b) mūsu izaugsmes plāna pielāgošana 2021. gadam ar mērķi pārsniegt mūsu Rubīns un JS pamatdarbību un attīstīt Magento un Produkts Dizaina kompetence iekšējais.

Pietiek ar pašreklāmu, ļaujiet man jūs uzaicināt uz mūsu #TheCodestReview sērijas 5. epizodi. 

Tēmas mans komanda ir sagatavojis šim laikam: 

1. mērogojama un uzturamā front-end arhitektūra.
2. Parastās saistības.
3. Ruby 3.0.0 izlaiduma atjauninājumi.

Komentārus par frontend lietojumprogrammu un parastajām saistībām šonedēļ piegādā mūsu React inženieri bet Ruby 3.0.0 mūsu Ruby sapnis team.

Mūsdienās daudzi izstrādātāji, lai ietaupītu laiku, izmanto jau izveidotas lietotāja saskarnes bibliotēkas un atkārtoti lietojamus komponentus. Tā ir laba prakse, kas palīdz mums ietaupīt daudz laika, bet, kad mūsu projekts kļūst lielāks - jūs sapratīsiet, ka ar to nepietiek, lai apstrādātu ar kods.

Ir divi labi modeļi, kas izmantoti back-end izstrādē - domēna virzīta izstrāde (Domain Driven Development - DDD) un interešu nodalīšana (Separation of Concerns - SoC). Tos varam izmantot arī front-end arhitektūrā.

DDD mēs cenšamies sagrupēt līdzīgas funkcijas un pēc iespējas vairāk atdalīt tās no citām grupām (moduļiem).

Savukārt SoC gadījumā mēs, piemēram, nodalām loģiku, skatus un datu modeļus (piemēram, izmantojot MVC vai MVVM projektēšanas modeli).

Ir daudz labas prakses un modeļu, ko izmantot, bet man vislabāk patīk šis veids.

Ja izmantosim šo modeli, iegūsim šādu attēlu:

Sākumā lietotājs tiek novirzīts uz pareizo moduli, izmantojot lietotnes maršrutēšanu. Katrs modulis ir pilnībā ietverts. Taču, tā kā lietotājs sagaida, ka izmantos vienu lietojumprogrammu, nevis vairākas mazas, pastāv zināma sasaiste. Šī sasaiste attiecas uz konkrētām funkcijām vai biznesa loģiku.

Un mums ir šāda struktūra:

app mape - lietojumprogrammu slānis

assets - mape bildēm, fontiem, ikonām utt.

komponenti - šeit jābūt atkārtoti izmantojamiem komponentiem, kuriem nav sarežģītas loģikas.

config - šeit mēs saglabāsim globālo stāvokli

lib - mape sarežģītu funkciju un loģikas aprēķināšanai

moduļi - šeit ir mūsu moduļi

pubsub - vieta, kur glabāt shēmas aprakstīšanai. dati struktūra.

stili - mūsu css/scss kodam

Šī struktūra palīdzēs mums apstrādāt mūsu augošo lietojumprogrammu un novērst kļūdas. Tas arī palīdzēs ērtāk izveidot darba daļas ar atsevišķiem moduļiem, tos testēt un atvieglos refaktorizāciju un atkļūdošanu (atsevišķu moduļu dēļ).

Ja mēs dziļāk aplūkosim moduļu arhitektūru un to saikni ar API - mēs saņemsim kaut ko līdzīgu:

Ja ir mape ‘app’, mēs izveidosim vēl vienu mapi ‘api’ ar API izsaukumu kodu un datiem, kurus saglabāsim mapē ‘config/store’. Šeit mēs glabājam statiskus un nemainīgus datus, kurus izmantojam visā lietojumprogrammā.

Arī mapē pubsub/schema mēs aprakstīsim konkrētus datu tipus, kas paredzēti JavaScript objekti.

Visi moduļi satur datus, kas mums ir jāizmanto (lietotāji, maršruti, tabulas, darbības utt.). Katrs modulis ir savienots ar lietojumprogrammas slāni un pārņem visus nepieciešamos datus.

Front-end ir pirmais piekļuves punkts mūsu lietotājiem. Pieaugot mūsu front-end projektu funkciju skaitam, mēs ieviešam arī vairāk kļūdu. Taču mūsu lietotāji sagaida, ka kļūdu nebūs, un jaunas funkcijas būs pieejamas ātri. Tas nav iespējams. Tomēr, izmantojot labu arhitektūru, mēs varam tikai censties to sasniegt, cik vien iespējams.

Parastās saistības ko Sathyabodh Mudhol at DZone

Iemesls nepieciešamībai labāk veikt darbu

Iedomājieties, ka esat sākumposmā uzņēmumā, kurā tikko esat pieņemts darbā. Visi cilvēki pret jums ir laipni, un viss šķiet labi līdz brīdim, kad jūs iepazīstina ar kodu bāzi no laikiem, kad JavaScript vēl nebija valoda un Netscape ielādēja lapu, kas varētu šķist kā mūžs.

Koda mantošana, šķiet, ir milzīga problēma, kad projektā tiek iesaistīti jauni izstrādātāji. Viena lieta ir lasīt kodu, bet saprast, kā lietojumprogramma tika izstrādāta, nav gluži tas pats. Bieži vien apņemšanās izrādās noderīgas un sniedz kontekstu, kāpēc šos console.logs linter nav noķēris vai kāpēc šis nepatīkamais // TODO ir tur tā izstrādātāja bērniem, kurš sākotnēji izveidoja anotāciju.

Sāksim ar to, kāpēc parastās saistības ir labākas nekā nestandartizēti saistību noteikumi.

Ja mēs pieņemam darbā jaunus izstrādātājus projektā, kurā lielākā daļa nodevumu sastāv no ziņojumiem, kas ir līdzīgi tam, ka vajadzētu strādāt vai Sleepy fix for footer ASAP, kas parādās jūsu galvā?

Es teiktu, ka sarkanie karogi, jo:

• Mēs nezinām, kam tieši vajadzētu strādāt
• Kāpēc kāds kaut ko stūma, būdams miegains un potenciāli kļūdains?
• Bija noteikt steigā, ja mēs varam redzēt ASAP anotāciju?

Tā kā jūsu team var piemērot pielāgotus noteikumus, kad tiek veiktas izmaiņas, ir mazāk iespēju kļūdīties, jo jūsu izmaiņu nodošanai ir jābūt stabilai. Tas vairs nav veids, kā vienkārši izrakstīties. Tas ir paraksts, kas informē citus cilvēkus, ka jūs zinājāt izdarītās atzīmes saturu. Nav vajadzības pieminēt, ka, ja jūsu paveiktais darbs nav pareizi parakstīts, tas, visticamāk, radīs kļūdu un parādīs jums ziņojumu

Pastāv iespēja, ka jūsu team vēlas iestatīt noteikumu, kas aizliedz izmantot noteiktus atslēgvārdus, tāpēc ASAP vai jebkādi rupjības vārdi var tikt iekļauti melnajā sarakstā.

Instrumenti

Projekta sākumā ir ļoti noderīgi iepazīstināt visus ar to, kā jūsu izstrādes komanda vēlētos, lai jaunie izstrādātāji veiktu izmaiņas. Tad izveidojiet rīku, kas palīdzēs viņiem sekot līdzi tam, par ko jūs visi vienojāties.

Viens no rīkiem, ar kuru man bija iespēja strādāt, bija commitlint un tas padarīja konvencionālās saistības par manu ierasto praksi, kad es sāku strādāt pie jauniem projektiem, kuros nav noteikumu, un team ir atvērts idejai tos ieviest.

Strādājot ar iestatījumiem un izplatot tos visā jūsu team varat vienkārši vienkārši izveidot npm paketi un vienkārši mpn i -D to katrā projektā. Tas noteikti palīdzēs visiem projekta dalībniekiem vienmēr būt uz vienas lapas un vajadzības gadījumā pārvietoties no projekta uz projektu, saprotot, kādas bija pēdējās izmaiņas (un kāpēc tās tika veiktas).

Draugi ar vairākiem ieguvumiem

Tātad tagad, kad viss ir iestatīts un sapratāt, kāpēc būtu lietderīgi sākt izmantot CC, vislabākā daļa būs programmēšana, kas saistīta ar tikko piemērotajiem noteikumiem! Mēs izmantojam standartizētu veidu, kā mēs veicam commit, mēs pievēršam lielāku uzmanību tam, par ko patiesībā bija commit, tāpēc kāpēc gan nenoteikt āķus, kas ļautu jums ātri testēt uz staging, ja ir kāds karodziņš? Mēs nevēlamies pārslogot pakalpojumus un samazināt izmaksas, kad tas ir nepieciešams, un ir daži iemesli, kāpēc testēt uz produkcijai līdzīga servera, nevis localhost.

Pieņemsim, ka jūs strādājat ar PWA un jums ir nepieciešams SSL, lai pilnībā pārbaudītu tā potenciālu, un jūsu testēšanas platformā ir SSL. Viss, kas jums tagad ir nepieciešams, ir tikai labs commit. Kaut kas līdzīgs feat(PWA): manifest icons workbox setup upload varētu iedarbināt visu testēšanas un zobratu pārvietošanas mehānismu. Mums tas nav nepieciešams, kad vienkārši augšupielādējam dažus statiskus datus, piemēram, manifest.json, tāpēc mēs pievienojam karodziņu [TEST_SKIP] kā postfiksu mūsu commit. Tas ļauj mūsu CI vienkārši augšupielādēt jaunus līdzekļus testēšanas vidē un izlaist testēšanu. Jūs varat izlasīt vairāk par to šeit

Pēc kāda laika jūs varēsiet redzēt citu peļņu, piemēram, vieglu CHANGELOG ģenerēšanu un labāku versiju veidošanu ar semantisko versiju veidošana. Ja ar to nepietiek, lai pārliecinātu jūs mainīt savu saistību ziņojumu rakstīšanas veidu, varbūt, iemērcot pirkstus svaigā aukstā ūdenī un kādu laiku mēģinot tos izmantot savā privātajā repozitorijā, mainītu jūsu domas.

Laimīgu parasto saistību uzņemšanos!

Rubīna 3.0.0 izlaiduma atjauninājumi līdz Ruby Community

Ilgi kopienā gaidītā Ruby 3.0.0 versija ir ieraudzījusi dienas gaismu Ziemassvētkos, lai visi Ruby izstrādātāji to varētu atrast zem Ziemassvētku eglītes, tiklīdz pamostos no rīta. Uz The Codest mēs kultivējam zināšanu apmaiņas kultūru, organizējot iknedēļas izstrādātāju sanāksmes, kurās mūsu inženieri apspriež tehnoloģiju tendences un savus jaunos atklājumus, kas ir uzmanības vērti. Zemāk atradīsiet saiti uz slaidiem no demo dienas, kurā mūsu vecākais Ruby inženieris no sava subjektīvā viedokļa apsprieda dažas svarīgas izmaiņas Ruby 3.0.0 versijā:

https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing

Turklāt mūsu Ruby mentors ir veicinājis jaunās versijas izstrādi ar savu pull pieprasījumu, kas tika veiksmīgi apvienots. Vairāk par privātuma kontroles metodēm lasiet mūsu izstrādes vadītāja īsajā rakstā zemāk.

https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods

Liels paldies, ka izlasījāt, un, ja esat nonācis tik tālu, es novērtēju jūsu laiku, un ikviena atsauksme ir vairāk nekā apsveicama LinkedIn vai manā e-pastā.

Atgriežamies pie jums ar nākamo epizodi februāra beigās, kad tiks pārskatīts podkāsts, kurā tiks intervēts Shopify. CTO, vīrietis, kurš strādā pie lieliskās Rubīna monolīta lietotnes team inženierijas!

Uz tikšanos.

Lasīt vairāk:

TheCodestReview #4 - iknedēļas programmatūras inženierijas sula

TheCodestReview #3 - iknedēļas programmatūras inženierijas sula

TheCodestReview #2 - iknedēļas programmatūras inženierijas sula