@yarmolchuk29 окт 2019 в 10:43

Лучшие практики и инструменты при разработке iOS приложений

7 мин

9.2K

Objective C * Swift * Программирование * Разработка мобильных приложений * iOS *

Перевод

Комментарии 14

@iStaZzzz 29 окт 2019 в 10:53

Лучшие практики

Обычно класс AppDelegate выполняет много работы при запуске приложения. Он может настроить окно, построить базовую структуру пользовательского интерфейса приложения, выполнить регистрацию для получения уведомлений, настроить базу данных и даже иногда выполнять вызовы API для определенной службы серверного приложения

@yarmolchuk 29 окт 2019 в 11:51

Автор статьи не говори, что это хорошо, он говорит что иногда такое встречается… и как решать такую проблему когда вы пишите юнит тесты…

@iStaZzzz 29 окт 2019 в 12:33

Решать проблему нужно в корне. Борьба с последствиями и игнорирование причины и есть плохая практика.

@yarmolchuk 29 окт 2019 в 12:55

Согласен на все 100%… но суть статьи не в том… если Вы не заметили. Автор статьи не говорит про рефакторинг и как правильно организовать код в AppDelegate.

@iStaZzzz 29 окт 2019 в 14:55

а говорит что к одному жуткому AppDelegate нужно добавить еще один — тестовый.

@IgorFedorchuk 31 окт 2019 в 19:21

В тестовом AppDelegate не будет много логики, он будет подключен только к тестовому таргету и из основного проекта его не видно.

@iStaZzzz 1 ноя 2019 в 11:28

В том то и дело что будет. Человек один раз уже ошибся, а ему вместо решения предлагают сделать ошибку в 2 раза больше. И при изменениях одного файла придется менять второй. Или не прийдется. В общем радость от поддержки в полной мере.
На претензию что такого не будет: будет.
Все в курсе про объекты-Боги, о SOLID. Но перегруженные AppDelegate все равно создаются.

@debug45 29 окт 2019 в 14:21

«Работая над разработкой»…

НЛО прилетело и опубликовало эту надпись здесь

@alexwillrock 30 окт 2019 в 03:09

Видимо, вы недавно пришли в командную разработку.
Смысл линтера — чтобы весь код имел консистентный внешний вид, нейминг etc. Если каждый будет писать так, как ему вздумается — мы получим хаотичные текстовые файлы, и для изменения каждого придется долго вникать.
Про количество переменных — уже давненько не используются циклы вида for(x;y;z), писать дженерики вида тоже не очень ясно или замыкания в виде T -> (where: { v -> x in }) тоже не передает сути.
Проект не соберется до тех пор, пока не будут исправлены все ошибки линтера — это дополнительная гарантия того, что только после успешного билда на CI будет влит данный PR и он не противоречит командным правилам.

НЛО прилетело и опубликовало эту надпись здесь

@iWheelBuy 1 ноя 2019 в 14:31

Еще fastlane туда можно положить

@yarmolchuk 1 ноя 2019 в 14:38

Все зависит от количества разработчиков на проекте и сложности проекта. Часто бывает, что нужно четко завязывайся на определенную версию pod.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий