Перша робота, або як не треба розробляти під iOS

У даній статті я спробую розповісти про нетривіальних проблем, з якими може зіткнутися початківець розробник. Якщо Ви, шановний читачу, вже працюєте в цій сфері, то навряд чи почерпнете для себе щось нове, але якщо Ви тільки вчитеся або робите свої перші кроки, то деякі з цих порад можуть допомогти вам. Вони мало стосуватимуться мови і більше відносяться до якихось спільних речей, пов'язаних з процесом розробки. Якщо стаття виявиться не банальщиной, то я буду пробувати писати подібні статті на тему якихось конкретних завдань.

Вступні п'ять слів про себе і чому я хочу написати цю статтю: закінчив бакалаврат МДТУ їм. Н. Е. Баумана, Swift і iOS розробку почав вивчати за CS193P влітку 2015 року, досвіду програмування до цього не мав. Знайшовши свою першу роботу, по суті своїй є якоюсь подобою стартапу, я толком не розбирався, що таке UITableView, асинхронність, про cocoapods я навіть не чув. Завданням було написанням великого, близько 50 екранів, клієнт-серверного додатка. Через півроку роботи додаток близько до готовності. І ось, переписуючи один і той же UIViewController вже в третій раз, я подумав, що якщо хто-то розповів би мені всі ті, вже здаються очевидними, речі, коли я тільки починав, процес розробки скоротився б на місяць, а кількість негативних емоцій, отриманих при роботі, в рази.

1. git, xcode, консоль
Перші 3 місяці я користувався вбудованим в xcode контролем версій, і все було відмінно, поки до мене не приєднався другий розробник. Кількість якихось дивних помилок на рівні xcode було неймовірним, часом простий merge займав 2 години часу. Безумовно, через деякий час ми вже обходили всі підводні камені, але кожен раз молитися, щоб все пройшло добре не дуже приємне заняття, тому ми спробували використовувати консоль, і з тих пір з цією частиною роботи не було жодної проблеми, окрім…

2. storyboards
Ніколи, ніколи не намагайтеся працювати в одному .storyboard файлі, навіть якщо Ви програмуєте один. Розносите більш-менш закінчені блоки UI в окремі файли. Це заощадить Вам дні роботи. Спочатку все просто чудово, але, .storyboard по суті своїй — XML файл, а тому при роботі з одним файлом декількох людьми, при будь-якій спробі merge буде виникати конфлікт. І тоді Вам доведеться відкривати файл XML і руками все там виправляти, що є пекельно пекельним заняттям. Ще один підводний камінь, який проявляє себе на пізніх стадіях розробки — дикі лаги при роботі з ним. Якщо у Вас .storyboard, наприклад, 30 екранів, то на MacBook Air 13' 2012 він буде відкриватися близько 30 секунд, якщо xcode просто не вилетить з помилкою.

3. Коментування та документація
Не знаю, може бути я такий один, але коли я починав, то думав: "Пф, потім все відразу закомментирую, навіщо це взагалі потрібно, ніколи не буде дивитися мій код, а я то знаю, що я написав". Це величезна помилка. Коли зараз я переробляю код, який був написаний мною на самому початку, я фактично роблю все заново, тому що, дивлячись на код, я просто не розумію навіщо я зробив ту чи іншу річ, звідки тут взялася ця функція або навіщо я ввів цю умову. Завжди варто залишати хоча б мінімальний коментар до того, що Ви написали, інакше потім Ви зіткнетеся з тим, що витратите в два рази більше часу на розбір написаного.

4. Технічне завдання та календарний план
Якщо Ви працюєте на когось і почали виконувати якусь роботу без структурованого та прозорого технічного завдання — Ви в лайні. Відсутність ТЗ веде до кромешному мраку в роботі, коли Ви будете переробляти один екран по 10 разів, тому що замовник/начальник/той хто платить гроші буде придумувати нові божевільні ідеї, які Вам доведеться втілювати, втілюючи їх буде рухатися ваш термін здачі програми, і Ви будете думати, що Ви 10 разів змінюєте одне і те ж, то термін рухається. Немає. У термін з Вас запитають, і відкараскатися тим, що Ви там щось переробляли може і вийде, але ситуація не з приємних. Завжди прискіпливо запитуйте про кожному пункті завдання, щоб уникнути подібних ситуацій.

5. Stack overflow
Цей сайт — Мекка початківців розробників, і він, безумовно фантастично корисний застосовно до iOS розробці, але з ним теж пов'язані пару речей, які я відкрив для себе не відразу. По-перше, не варто брати перше-ліпше правильне рішення: подібний поспіх на великій дистанції може призвести до того, що через деякий час ви подивіться на цей код і проб'є особа фейспалмом. Подивіться кілька рішень і подумайте, яке більш застосовно до вашої ситуації. По-друге, намагайтеся не просто копіпаст код, але намагатися розібратися в ньому, це і прискорює процес навчання, але, що найважливіше, в разі чого, Ви зможете змінити цей код вже без участі пошукових машин. Звідси випливає по-третє: stack overflow відмінно допомагає зі стандартними завданнями, але як тільки у Вас будуть нетривіальні проблеми, які повністю належать тільки до Вашого коду — на допомогу звідти краще не сподіватися, зате тут Вам допоможуть навички користування документацією та знання свого коду, отримані з по-друге.

6. @IBInspectable
Максимально налаштовуйте свої UI-елементи з допомогою асистента. Захаращення коду чимось на зразок
self.customView.backgroundColor = .clear
не є добре, але якщо це все-таки необхідно — виносьте всі подібні налаштування в окрему функцію, це допоможе тримати свій код читабельним.

7. Дерево папок
Створюйте папки для груп файлів з самого початку. Ті папки, які відображаються в лівому меню xcode, нічого з фізичним розміщенням файлів не мають: перетягування файлу в таку папку на жорсткому диску він залишиться там, де був створений. Дуже важливо при створенні відразу думати, де цей файл буде розташований, оскільки в майбутньому можна змінювати його адресу, і з одним файлом проблем не буде, але я відкрив для себе це коли в моєму докорінно було близько 50 файлів, які я потім вручну переміщував туди, де від повинен був бути, і задоволення в цьому було мало.

На цьому все, сподіваюся, кому-то ці поради допоможуть уникнути тих проблем, з якими зіткнувся я.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.