Мы стараемся стать лучше! :) А вообще – обусловлено изначальным бэкграундом всех трех ведущих. Я, Стас и Глеб были iOS разработчиками (хотя я лет шесть назад начинал с андроида).
Да, считаем сейчас и покрытие тестами, и ряд других метрик с помощью SwiftLint. Для него же и пишем разные кастомные правила, которые позволяют автоматизировать разные проверки кода на Swift.
Пробовал, всегда работало хуже — возможно, просто неправильно строил процесс. Советы из статьи, на самом деле, не жестко привязаны к блокирующему ревью — все применимы и к неблокирующему.
Шуточка про «лучшее — враг хорошего». Такие штуки, если они действительно важны для проекта, стоит расценивать как техдолг и возвращаться к работе над ними позже.
> Всех членов команды? Не слишком ли большая нагрузка?
В случае команды из 3-4х человек — как раз самое оно.
Сознательно опустил эту часть — материалов есть довольно много, в том числе и те ссылки, которые приложили к комменту. Ну и, если что, есть задел для второй части материала :)
Про взаимодействие подмодулей и переходы между ними есть две отдельные главы. А вообще, как я упоминал, наши Issues всегда открыты для таких вопросов — будем рады помочь :)
> Код с анимациями туда не поместить.
Вообще неплохо решается на кастомных UIStoryboardSegue.
> Если их несколько, то при переходе с одного на другой — создается нагрузка на main thread (NSKeyedArchiver должен распарсить сториборду, а он сам по себе медленный).
Серьезно, несколько переходов между сторибордами не окажут сколько-нибудь значимого влияния на производительность :)
> Нельзя все сделать в Storybaord при все желании. Например, задать cornerRadius, shadowOffset и т.д.
Как уже отмечали выше, IBDesignable, либо User-defined runtime attributes.
Идеальный с точки зрения удобства работы и поддержки вариант — N сториборд + вынесение реиспользуемых элементов в xib'ы. Скатываться в чрезмерную оптимизацию имеет смысл только при наличии фактических проблем с производительносью, при том же скролле сложных таблиц. Лэйаут в коде обычно выглядит понятным только для его автора, а вот остальным приходится тяжелее.
Отличная вещь, но есть очень большая проблема — не умеет работать с WPA2-Enterprise, в результате нет возможности использовать на работе. А хотелось построить свой маленький уютный дэшборд :(
Спасибо за отзыв! Действительно, про VIPER — это затравка, мы постараемся рассмотреть все возможные аспекты его применения на Rambler.iOS где-нибудь ближе к концу года.
VIPER отлично подходит для условий постепенного переезда с любой другой архитектуры — как раз таки сейчас в нескольких крупных проектах этим и занимаемся, попутно покрывая все модули комплектами тестов.
Спасибо за отзыв :)
По поводу DI фреймворков соглашусь с Artem_zin — не настолько они востребованы среди разработчиков. Тем не менее, помимо Typhoon можно глянуть на Objection и BloodMagic (от 1101_debian) — но, на мой взгляд, не конкуренты.
Шуточка про «лучшее — враг хорошего». Такие штуки, если они действительно важны для проекта, стоит расценивать как техдолг и возвращаться к работе над ними позже.
> Всех членов команды? Не слишком ли большая нагрузка?
В случае команды из 3-4х человек — как раз самое оно.
Я обеими руками за реализацию таких вещей на сервере — но, к сожалению, это не всегда возможно.
Вообще неплохо решается на кастомных UIStoryboardSegue.
> Если их несколько, то при переходе с одного на другой — создается нагрузка на main thread (NSKeyedArchiver должен распарсить сториборду, а он сам по себе медленный).
Серьезно, несколько переходов между сторибордами не окажут сколько-нибудь значимого влияния на производительность :)
> Нельзя все сделать в Storybaord при все желании. Например, задать cornerRadius, shadowOffset и т.д.
Как уже отмечали выше, IBDesignable, либо User-defined runtime attributes.
Идеальный с точки зрения удобства работы и поддержки вариант — N сториборд + вынесение реиспользуемых элементов в xib'ы. Скатываться в чрезмерную оптимизацию имеет смысл только при наличии фактических проблем с производительносью, при том же скролле сложных таблиц. Лэйаут в коде обычно выглядит понятным только для его автора, а вот остальным приходится тяжелее.
VIPER отлично подходит для условий постепенного переезда с любой другой архитектуры — как раз таки сейчас в нескольких крупных проектах этим и занимаемся, попутно покрывая все модули комплектами тестов.
Ну и рекомендую не обходить вниманием последний доклад — поднимает жизненно-важные темы для любого приложения.
По поводу DI фреймворков соглашусь с Artem_zin — не настолько они востребованы среди разработчиков. Тем не менее, помимо Typhoon можно глянуть на Objection и BloodMagic (от 1101_debian) — но, на мой взгляд, не конкуренты.
Есть и поддержка Carthage: