Комментарии 14
Лучшие практики
Обычно класс AppDelegate выполняет много работы при запуске приложения. Он может настроить окно, построить базовую структуру пользовательского интерфейса приложения, выполнить регистрацию для получения уведомлений, настроить базу данных и даже иногда выполнять вызовы API для определенной службы серверного приложения
Автор статьи не говори, что это хорошо, он говорит что иногда такое встречается… и как решать такую проблему когда вы пишите юнит тесты…
Решать проблему нужно в корне. Борьба с последствиями и игнорирование причины и есть плохая практика.
Согласен на все 100%… но суть статьи не в том… если Вы не заметили. Автор статьи не говорит про рефакторинг и как правильно организовать код в AppDelegate.
а говорит что к одному жуткому AppDelegate нужно добавить еще один — тестовый.
В тестовом AppDelegate не будет много логики, он будет подключен только к тестовому таргету и из основного проекта его не видно.
В том то и дело что будет. Человек один раз уже ошибся, а ему вместо решения предлагают сделать ошибку в 2 раза больше. И при изменениях одного файла придется менять второй. Или не прийдется. В общем радость от поддержки в полной мере.
На претензию что такого не будет: будет.
Все в курсе про объекты-Боги, о SOLID. Но перегруженные AppDelegate все равно создаются.
На претензию что такого не будет: будет.
Все в курсе про объекты-Боги, о SOLID. Но перегруженные AppDelegate все равно создаются.
«Работая над разработкой»…
НЛО прилетело и опубликовало эту надпись здесь
Видимо, вы недавно пришли в командную разработку.
Смысл линтера — чтобы весь код имел консистентный внешний вид, нейминг etc. Если каждый будет писать так, как ему вздумается — мы получим хаотичные текстовые файлы, и для изменения каждого придется долго вникать.
Про количество переменных — уже давненько не используются циклы вида for(x;y;z), писать дженерики вида тоже не очень ясно или замыкания в виде T -> (where: { v -> x in }) тоже не передает сути.
Проект не соберется до тех пор, пока не будут исправлены все ошибки линтера — это дополнительная гарантия того, что только после успешного билда на CI будет влит данный PR и он не противоречит командным правилам.
Смысл линтера — чтобы весь код имел консистентный внешний вид, нейминг etc. Если каждый будет писать так, как ему вздумается — мы получим хаотичные текстовые файлы, и для изменения каждого придется долго вникать.
Про количество переменных — уже давненько не используются циклы вида for(x;y;z), писать дженерики вида тоже не очень ясно или замыкания в виде T -> (where: { v -> x in }) тоже не передает сути.
Проект не соберется до тех пор, пока не будут исправлены все ошибки линтера — это дополнительная гарантия того, что только после успешного билда на CI будет влит данный PR и он не противоречит командным правилам.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лучшие практики и инструменты при разработке iOS приложений