iOS проект най-добрите практики и инструменти

С Xcode шаблон на проект с отворен код

Когато работех върху greenfield iOS проекти, често ми се налагаше да стартирам нов проект от нулата. Докато правех това, аз и моят екип винаги отделяхме много време за основни настройки на проекти като интегриране на инструменти, създаване на структурата на проекта, писане на базови класове, интегриране на външни библиотеки и т.н.

Реших, че времето, прекарано за стартиране на проекта, може да бъде спестено и процесът може да бъде предимно автоматизиран. Написах всички обичайни най-добри практики и инструменти, които използвахме и подготвих шаблон за проект, който аз и моят екип бихме могли да използваме при започване на нови проекти. Този шаблон трябва да спести време за настройка на проекта и също така да предостави обща основа, към която всеки член на екипа ще свикне, така че не е нужно да мислите и изследвате структурата и основите на проекта. Те винаги ще бъдат еднакви.

Всеки инструмент или най-добра практика, включени в шаблона, заслужават статия самостоятелно, но исках да опитам и обобщавам всяка точка и да дам кратко обяснение защо ги включих.

Cocoapods

Не мисля, че този има нужда от въведение. Това е библиотеката за управление на външни зависимости за iOS проекти. Това е от дълго време и е стабилно и биткойн тествано в хиляди (ако не и милиони) проекти. Там има алтернативни мениджъри на зависимости като Carthage, но реших да отида с Cocoapods, тъй като има най-широк спектър от проекти с отворен код, които поддържа. Използването на Cocoapods е много лесно и се предлага с индекс за търсене, който ви позволява лесно да откривате пакети, които може да ви трябват.

Проектът за шаблони се предлага с прост подфайл, който включва Swiftlint и R.swift. Шаблонът включва също Gemfile за управление на версията Cocoapods, използвана за разрешаване на зависимостите. Това е често пренебрегвано подобрение, което предотвратява възникването на проблеми, когато разработчиците от вашия екип инсталират зависимости, използвайки различни версии на самия Cocoapods. Gemfile налага използването на същата версия на Cocoapods в целия екип.

Swiftlint

Swiftlint е много полезен инструмент за прилагане на определени правила и стил на кодиране за всеки програмист в екипа. Можете да мислите за това като автоматизирана система за преглед на код, която предупреждава програмиста за опасни неща като разгръщане на сила, принудителни изстрели, опити за сила и т.н., но също така налага общ стил на кодиране, като се уверите, че всички програмисти спазват еднакви правила, свързани с „кодовия стил“ като правила за отстъп или разстояние. Това има огромни ползи от това, че не само спестявате време за преглед на кода, като правите тези основни проверки, но и прави всички файлове в проекта да изглеждат познати, което увеличава тяхната четимост и в резултат на това разбирането им от всички разработчици. Можете да намерите списък на всички правила тук. В шаблона Swiftlint е инсталиран чрез Cocoapods и е включен в стъпката на фази на сглобяване, така че той подсказва и предупреждава разработчика при всяко изграждане на проект.

R.swift

R.swift е инструмент за получаване на силно набрани, автокомплектовани ресурси като изображения, шрифтове и локализации. Това прави, като сканира вашия проект и генерира бързи класове, необходими за получаване на ресурси. Най-голямата точка на продажба на тази библиотека е, че докато използва ресурси, той прави вашия код:

  • Напълно въведено - по-малко кастинг и отгатване какъв метод ще се върне
  • Време за компилиране проверено - няма повече неправилни низове, които правят приложението ви да се срине по време на изпълнение
  • Автоматично завършено - никога повече не трябва да отгатвате името на това изображение / копче / табло за разказ

Помислете за следния код чрез официалния низ API:

нека икона = UIImage (с име: „custom-icon“)

Ако грешно написате името на изображението, ще получите нула тук. Ако някой от вашия екип промени името на ресурса на изображението, този код ще върне нула или ще се срине, ако накарате да развиете изображението. Когато използвате R.swift, това става:

нека икона = R.image.customIcon ()

Сега можете да сте сигурни, че иконата наистина съществува (компилаторът ще ви предупреди, ако не благодарение на проверките за компилиране на времето) и сте сури, че няма да правите грешка в името на иконата, тъй като ще използвате автоматично довършване.

R.swift се инсталира чрез Cocoapods и се интегрира в шаблона като фаза на сглобяване и ще генерира класовете за обвивка Swift при всяка компилация. Това означава, че ако добавите файл / изображение / локализация / шрифт / цвят / копче и т.н., той ще бъде достъпен за вас чрез R.swift, след като компилирате проекта.

Отделно AppDelegate за тестове

Често пренебрегвана добра практика е да имате отделен клас TestAppDelegate при изпълнение на тестове. Защо е добра идея? Е, обикновено класът AppDelegate върши много работа при стартиране на приложението. Той може да настрои прозорец, да изгради основната структура на потребителския интерфейс на приложението, да се регистрира за известия, да създаде база данни и дори понякога да прави обаждания в API към някаква резервна услуга. Единичните тестове не трябва да имат странични ефекти. Наистина ли не искате да правите произволни api разговори и да настройвате цялата структура на потребителския интерфейс на приложението си, само за да изпълните някои тестове на единица?

TestAppDelegate също е чудесно място да имате код, който искате да стартирате само веднъж по време на изпълнението на вашия тестов пакет. Може да съдържа код, който генерира макети, заявки за мрежови заявки и т.н.

Шаблонът съдържа файл main.swift, който е основната входна точка за приложението. Този файл има методи, които проверяват каква е средата, която приложението работи в момента и дали това е тестовата среда, извиква TestAppDelegate.

Профилиране на флагчета за изпълнение на компилатора

Swift е страхотен език, по-лесен за използване и много по-безопасен от Objective-C (IMO). Но когато беше представена за първи път, имаше един голям недостатък - време за компилиране. Върнах се в Swift 2 дни, аз работех по проект, който имаше грубо 40k линии от Swift код (среден проект). Кодът беше много тежък с генерични и типови изводи и отне близо 5 минути, за да се състави чиста конструкция. Когато направихте дори малка промяна, проектът ще се прекомпилира и ще отнеме около 2 минути, за да видите промяната. Това беше едно от най-лошите преживявания за разработчици, които някога съм имал и почти спрях да използвам Swift заради него.

Единственото решение тогава беше да се опита и да се профилират времената за компилиране на проекта и да се опитате да промените кода си по такъв начин, който да направи компилатора по-бърз. За да помогне с това, Apple представя някои неофициални флагове на компилатор, които биха ви предупредили при компилиране на метод на метод или разрешаване на типа на израз, отне твърде много време. Добавих тези флагове към проекта за шаблони, така че ще бъдете предупредени от самото начало за дългите времена на компилиране за вашето приложение.

В наши дни времената на сглобяване са драстично подобрени и много рядко се налага да ощипвате кода си само за да подобрите времената на сглобяване. Но все пак е по-добре да знаете отпред, за да се опитате да отстраните проблема, когато проектът стане твърде голям.

Конфигурации за разработка / постановка / производство

Друга добра практика (или мога да кажа необходимост) е да има отделни конфигурации и променливи на средата за среда за разработка, поставяне и производство. Почти всяко приложение в днешно време трябва да се свърже с някакъв вид резервна услуга и обикновено тези услуги се разполагат в множество среди. Средата за разработка се използва за ежедневни разработки и за разработка на тестове за техния код. Сцениращата среда се използва за стабилни версии на тестерите и клиентите за тестване. Всички знаем за какво е производствената среда.

Един от начините за поддържане на множество среди в iOS проект е добавяне на конфигурации на ниво проект.

Конфигурации на ниво проект

След като дефинирате конфигурациите, можете да създадете файл Configuration.plist, съдържащ променливите за всяка среда.

Configuration.plist

Когато стартирате проекта, можете да определите коя конфигурация да се използва. Можете да направите това в схемата за изграждане.

След това трябва да добавите още едно свойство във файла Info.plist на проекта. Стойността на това свойство ще бъде динамично разрешена по време на изпълнение към името на текущата конфигурация.

Всичко това е предварително конфигурирано за вас в шаблона.

Остава само да напише клас, който може да извлече тези променливи по време на изпълнение, в зависимост от конфигурацията, избрана в схемата за изграждане. Шаблонът съдържа клас ConfigurationManager, който може да извлече променливите за текущата среда. Можете да проверите изпълнението на този клас в Github, за да видите как работи.

Прочети ме

Всеки проект трябва да има основен Readme, който поне има инструкции как да инсталирате зависимости и да стартирате проекта. Той трябва също да съдържа описания на архитектурата и модулите на проекта. За съжаление, разработчиците не обичат да пишат документация (readme е част от това) и виждах проект, който се разработваше от месеци и те дори имаха основен Readme. За да премахнете бремето от писането на тази основна четене, шаблонът съдържа стандартен readme, който обхваща инсталацията и структурата на проекта. Когато настроите нов проект с помощта на шаблона, ще включите Readme автоматично.

Gitignore

В днешно време повечето проекти използват GIT като своя система за контрол на версиите. Когато използвате GIT, обикновено не искате да игнорирате някои файлове или папки в проекта, като например папката за сглобяване или производната папка с данни. За да ви спести проблемът с търсенето на gitignore файл, който да отговаря на вашия iOS проект, шаблонът включва стандартен gitignore, предоставен от сътрудниците на Github.

Основни класове за работа с преки връзки и известия

Почти всяко приложение в днешно време трябва да обработва връзки и известия. За да направите това, разработчикът трябва да напише някакво количество код на кокетната плоча в класа на AppDelegate. Шаблонът обхваща и предлага и базови класове, които улесняват работата с дълбоки връзки и известия.

резюме

В обобщение, шаблонът се опитва да включва най-добрите практики и интегрира полезни инструменти на трети страни. Това би трябвало да ви спести часовете и екипа ни, прекарани за нова настройка на проекта, а също така да осигури обща и силна основа за останалата част от проекта. Нека ви служи добре!

PS: Ако имате някакви проблеми или заявка за функция за шаблона, просто ми оставете проблем в Github. Ще се опитам да го разреша в свободното си време.