iOS projekta paraugprakse un rīki

Ar atvērtā koda Xcode projekta veidni

Strādājot pie greenfield iOS projektiem, man bieži nācās sākt jaunu projektu no nulles. To darot, es un mana komanda vienmēr pavadījām daudz laika projekta pamata iestatīšanai, piemēram, rīku integrēšanai, projekta struktūras iestatīšanai, bāzes klašu rakstīšanai, ārējo bibliotēku integrēšanai utt.

Es nolēmu, ka var ietaupīt laiku, kas pavadīts projekta uzsākšanai, un procesu lielākoties var automatizēt. Es pierakstīju visu parasto paraugpraksi un rīkus, ko mēs izmantojām, un sagatavoju projekta veidni, kuru es un mana komanda varētu izmantot, uzsākot jaunus projektus. Šai veidnei vajadzētu ietaupīt projekta iestatīšanas laiku un arī nodrošināt kopēju pamatu, pie kura pieprasa katrs komandas loceklis, lai jums nebūtu jādomā un jāizpēta projekta struktūra un pamati. Viņi vienmēr būs vienādi.

Katrs rīks vai paraugprakse, kas iekļauta veidnē, ir pelnījusi rakstu pats par sevi, bet es gribēju mēģināt apkopot katru punktu un sniegt īsu paskaidrojumu, kāpēc es tos iekļāvu.

Kakapodes

Es nedomāju, ka šim ir nepieciešams ievads. Šī ir bibliotēka iOS projektu ārējo atkarību pārvaldībai. Tas ir pastāvējis jau ilgu laiku un ir izturīgs un cīņā pārbaudīts tūkstošiem (ja ne miljonos) projektu. Tur ir alternatīvi atkarības vadītāji, piemēram, Carthage, bet es nolēmu doties kopā ar Cocoapods, jo tam ir visplašākais atvērtā koda projekts, ko tas atbalsta. Cocoapods lietošana ir ļoti vienkārša, un tam ir pievienots meklēšanas indekss, kas ļauj viegli atklāt paketes, kas jums varētu būt vajadzīgas.

Veidnes projektam ir vienkāršs Podfile, kurā ietilpst Swiftlint un R.swift. Veidnē ir arī Gemfile Cocoapods versijas pārvaldībai, ko izmanto atkarību novēršanai. Šis ir bieži aizmirsts uzlabojums, kas novērš problēmu rašanos, kad jūsu komandas izstrādātāji instalē atkarības, izmantojot pašas Cocoapods dažādas versijas. Gemfile visā komandā piespiež izmantot to pašu Cocoapods versiju.

Swiftlint

Swiftlint ir ļoti noderīgs rīks, lai ieviestu noteiktus noteikumus un kodēšanas stilu katram komandas programmētājam. Varat to iedomāties kā automatizētu kodu pārskatīšanas sistēmu, kas brīdina programmētāju par bīstamām lietām, piemēram, spēka izpausmēm, spēka izmešanu, spēka mēģinājumiem utt., Bet arī ievieš kopēju kodēšanas stilu, pārliecinoties, ka visi programmētāji ievēro tos pašus “koda stila” noteikumus piemēram, atkāpes vai atstarpes noteikumi. Tam ir milzīgas priekšrocības, ne tikai ietaupot koda pārskatīšanas laiku, veicot šīs pamata pārbaudes, bet arī padarot visus projekta failus izskatīgus, kas palielina to lasāmību un rezultātā to izpratni visiem izstrādātājiem. Visu noteikumu sarakstu varat atrast šeit. Veidnē Swiftlint tiek instalēts, izmantojot Cocoapods, un tiek iekļauts veidošanas fāžu solī, tāpēc tas iekrāso un brīdina izstrādātāju par katru projekta izveidi.

R.swift

R.swift ir līdzeklis, lai iegūtu spēcīgi drukātus, automātiski pabeigtus resursus, piemēram, attēlus, fontu kopas un lokalizācijas. Tas tiek darīts, skenējot jūsu projektu un ģenerējot ātrās klases, kas vajadzīgas resursu iegūšanai. Šīs bibliotēkas lielākais pārdošanas punkts ir tas, ka, izmantojot resursus, tas veido jūsu kodu:

  • Pilnībā ierakstīts - mazāk liešanas un uzminēšanas, kāda metode atgriezīsies
  • Apkopotais laiks ir pārbaudīts - vairs nav nepareizu virkņu, kuru dēļ jūsu lietotne sabojājas izpildlaikā
  • Automātiski pabeigts - nekad vairs nevajadzēs uzminēt šo attēla / lentes / scenārija nosaukumu

Izmantojot oficiālo virknes API, apsveriet šo kodu:

let icon = UIImage (nosaukts: “custom-icon”)

Ja nepareizi uzrakstīsit attēla vārdu, šeit tiks parādīts nulle. Ja kāds no jūsu komandas locekļiem maina attēla resursa nosaukumu, šis kods atgriezīs nulli vai sabojāsies, ja piespiedīsit attēlu attīt. Izmantojot R.swift, tas kļūst par:

let icon = R.image.customIcon ()

Tagad jūs varat būt pārliecināti, ka ikona patiešām pastāv (kompilators brīdinās jūs, ja tā nenotiek, pateicoties kompilācijas laika pārbaudēm), un, ja jūs esat apbēdināts, ikonas nosaukumā neveicat drukas kļūdas, jo jūs izmantosit automātisko pabeigšanu.

R.swift tiek instalēts, izmantojot Cocoapods, un tiek integrēts veidnē kā veidošanas fāze, un tā radīs Swift iesaiņojuma klases katrai versijai. Tas nozīmē, ja jūs pievienojat failu / attēlu / lokalizāciju / fontu / krāsu / papīru utt., Tas būs pieejams jums, izmantojot R.swift, kad būsit sastādījis projektu.

Testiem atdaliet AppDelegate

Bieži aizmirstā labā prakse ir atsevišķa TestAppDelegate klase, veicot testus. Kāpēc tā ir laba ideja? Parasti AppDelegate klase veic lielu darbu lietotņu startēšanas laikā. Tas varētu iestatīt logu, izveidot lietotnes lietotāja interfeisa pamata struktūru, reģistrēties paziņojumiem, iestatīt datu bāzi un pat dažreiz veikt API zvanus uz kādu backend pakalpojumu. Vienības pārbaudēm nedrīkst būt nekādas blakusparādības. Vai tiešām nevēlaties veikt izlases veida api zvanus un iestatīt visu savas lietotnes saskarnes struktūru, lai izpildītu dažus vienības testus?

TestAppDelegate ir arī lieliska vieta, kur iegūt kodu, kuru testa komplekta izpildes laikā vēlaties palaist tikai vienu reizi. Tajā varētu būt kods, kas ģenerē ņirgāšanās, tīkla pieprasījumus utt.

Veidnē ir main.swift fails, kas ir lietotnes galvenais ieejas punkts. Šajā failā ir metodes, kas pārbauda, ​​kāda ir vide, kurā pašlaik darbojas lietotne, un, ja tā ir testa vide, tā izsauc TestAppDelegate.

Kompilatoru veiktspējas profilēšanas karodziņi

Swift ir lieliska valoda, vieglāk lietojama un daudz drošāka nekā Objective-C (SJO). Bet, kad tas pirmo reizi tika ieviests, tam bija viens liels negatīvie posmi - apkopošanas laiki. Atpakaļ Swift 2 dienās es strādāju pie projekta, kurā bija aptuveni 40 000 rindiņu Swift koda (vidēja lieluma projekts). Kods bija ļoti smags ar vispārējiem medikamentiem un tipa secinājumiem, un tīras būves sastādīšanai vajadzēja gandrīz 5 minūtes. Kad esat veicis pat nelielas izmaiņas, projekts tiks atkārtoti sastādīts, un vajadzēja apmēram 2 minūtes, lai redzētu izmaiņas. Šī bija viena no vissliktākajām izstrādātāju pieredzēm, kāda man jebkad bijusi, un es gandrīz pārtraucu lietot Swift tās dēļ.

Vienīgais risinājums toreiz bija mēģināt profilēt projekta apkopošanas laikus un mēģināt mainīt jūsu kodu tādā veidā, kas padarītu kompilatoru ātrāku. Lai to palīdzētu, Apple ievieš dažus neoficiālus kompilatoru karodziņus, kas brīdina jūs, sastādot metodes pamattekstu vai izteiciena veida noteikšanu, kas prasīja pārāk ilgu laiku. Es šos karodziņus pievienoju veidņu projektam, lai jūs jau pašā sākumā tiktu brīdināts par ilgo apkopošanas laiku jūsu lietotnei.

Mūsdienās būvēšanas laiki ir dramatiski uzlabojušies, un jums ļoti reti ir jāpielāgo savs kods tikai tāpēc, lai uzlabotu būvēšanas laiku. Bet tomēr labāk ir zināt iepriekš, tad mēģināt novērst problēmu, kad projekts kļūst pārāk liels.

Izstrādātāju / inscenējumu / ražošanas konfigurācijas

Vēl viena laba prakse (vai es varu teikt, ka tā ir nepieciešama) ir atsevišķa konfigurācija un vides mainīgie attīstības, inscenēšanas un ražošanas vidēm. Mūsdienās gandrīz katrai lietotnei ir jāpievienojas sava veida aizmugures pakalpojumam, un parasti šie pakalpojumi tiek izvietoti vairākās vidēs. Izstrādes vide tiek izmantota ikdienas izvietošanai un deviem, lai pārbaudītu to kodu. Pieturvietu vide tiek izmantota stabilām versijām testētājiem un klientiem testēšanai. Mēs visi zinām, kāda ir ražošanas vide.

Viens no veidiem, kā iOS projektā atbalstīt vairākas vides, ir pievienot projekta līmeņa konfigurācijas.

Projekta līmeņa konfigurācijas

Kad esat definējis konfigurācijas, varat izveidot failu Configuration.plist, kurā ir katras vides mainīgie.

Configuration.plist

Palaižot projektu, varat norādīt, kura konfigurācija jāizmanto. To var izdarīt būvēšanas shēmā.

Pēc tam projekta Info.plist failā jāpievieno vēl viens īpašums. Šī īpašuma vērtība tiks dinamiski atrisināta izpildlaika laikā uz pašreizējās konfigurācijas nosaukumu.

Tas viss jums ir iepriekš konfigurēts veidnē.

Atliek tikai uzrakstīt klasi, kas šos mainīgos var izgūt izpildlaikā atkarībā no konfigurācijas, kas izvēlēta būvēšanas shēmā. Veidnē ir ConfigurationManager klase, kas var iegūt pašreizējās vides mainīgos. Varat pārbaudīt šīs klases ieviešanu vietnē Github, lai redzētu, kā tā darbojas.

Readme

Katrā projektā jābūt pamata Readme programmai, kurā vismaz ir norādījumi, kā instalēt atkarības un palaist projektu. Tajā jāietver arī projekta arhitektūras un moduļu apraksti. Diemžēl izstrādātājiem nepatīk rakstīt dokumentāciju (readme ir tā sastāvdaļa), un esmu redzējis projektu, kas tiek izstrādāts vairākus mēnešus, un viņiem bija pat pamata Readme. Lai noņemtu šīs pamata lasīšanas rakstīšanas nastu, veidnē ir standarta lasīšanas vienība, kas aptver instalēšanu un projekta struktūru. Iestatot jaunu projektu, izmantojot veidni, jums automātiski tiks iekļauta Readme.

Gitignore

Mūsdienās lielākā daļa projektu izmanto GIT kā savu versiju kontroles sistēmu. Lietojot GIT, jūs parasti nevēlaties ignorēt dažus failus vai mapes projektā, piemēram, veidot mapi vai atvasināto datu mapi. Lai ietaupītu grūtības, meklējot gitignore failu, kas ir piemērots jūsu iOS projektam, veidnē ir iekļauts standarta Gitignore fails, ko nodrošina Github līdzautori.

Pamatklases dziļo saišu un paziņojumu apstrādei

Mūsdienās gandrīz katrai lietotnei ir jārīkojas ar dziļajām saitēm un paziņojumiem. Lai to izdarītu, izstrādātājam AppDelegate klasē ir jāieraksta zināms daudzums katlu plākšņu koda. Veidne ir ietverta, un tā nodrošina arī pamata klases, kas atvieglo darbu ar dziļajām saitēm un paziņojumiem.

Kopsavilkums

Apkopojot, veidne mēģina iekļaut labāko praksi un integrē noderīgus trešo pušu rīkus. Tas jums un mūsu komandai ļautu ietaupīt stundas, kas pavadītas jauna projekta iestatīšanai, kā arī nodrošinātu kopīgu un stipru pamatu pārējam projektam. Lai tas jums labi kalpo!

PS: Ja jums ir kādas problēmas vai veidnes pieprasījums, atstājiet man problēmu vietnē Github. Es centīšos to atrisināt savā brīvajā laikā.