Ищем стажёра в нашу команду 🏄‍♂️

Стажировка в Surf — крутая возможность проявить скиллы в разработке и поработать на иностранных проектах. Мы за развитие и карьерный рост — трудоустроим лучших и будем прокачивать их грейд.

Что делают в Surf для стажёров:

• Платят стипендию;
• Строят гибкий график;
• Подключают опытного наставника;
• Обеспечивают современным железом.

Смотри требования к будущим iOS-стажёрам на карточках. Если твои скиллы подходят, то отправляй заявку на стажировку — вышлем тестовое задание, которое нужно выполнить до 12.02 включительно.

Собрали материалы, которые помогут при подготовке к стажировке:

→ Список полезной инфы для iOS-разработчиков.
→ Советы новичкам в iOS-разработке.
→ Как проходят стажировки в Surf.

Не проводите код-ревью на голодный желудок!
Или немного о том, как устроен процесс код-ревью в Surf

Процесс код-ревью в Surf есть! А если без шуток, в разных командах он проходит немного по-разному и зависит от разных факторов. О них и поговорим.

1️⃣ Размер команды
В небольшой команде из двух-трёх человек каждый разработчик проводит ревью каждого пул-реквеста.

Это:
✅ повышает качество проекта,
✅ помогает прокачать технически менее опытных разработчиков,
✅ даёт возможность познакомить участников команды с кодом друг друга,
❌ приводит к затратам ресурсов: отнимает довольно много времени.

В команде от четырёх человек и больше такое не сработает: как раз из-за временных затрат. Поэтому количество участников ревью ограничено: их может выбрать лид или создатель пул-реквеста.

2️⃣ Жизненный этап проекта
Иногда в жизнь вмешиваются обстоятельства в виде жёстких дедлайнов. Иногда в жизнь вмешиваются обстоятельства в виде жёстких дедлайнов. В этой ситуации можно воспользоваться таким понятием, как «технический долг» 😉

Если фичу надо отдать срочно и возможности перенести дедлайн нет, нужно запомнить то, что сделано «плохо»: зафиксировать это в техническом долге, а после релиза вернуться и исправить.

3️⃣ На что обращаем внимание в процессе код-ревью
🔹 общепринятые проектные договоренности,
🔹 соблюдение архитектурных правил,
🔹 грамотное разделение ответственностей,
🔹 соблюдение принципов программирования,
🔹 соблюдение code-style.

Проверять ли код на «правильность выполнения»? Об этом много споров. Наши техлиды проверяют.

Да, это отнимает много времени, но позволяет отсечь большинство багов ещё до попадания сборки к QA: это экономит время и QA, и разработчиков. Ведь чем раньше исправлен баг, тем меньше «стоимость» его исправления.

В чем проблема с выпадающим списком

В прошлый раз мы рассказывали про расширяемые ячейки в UITableView и как в этом поможет RDDM.

Рассмотрим более сложный случай расширяемых ячеек.

На первой картинке виден пример «выпадающего» списка. По нажатию на одну ячейку появляется 2 новых после неё.

Мы могли бы использовать ExpandableItem с вложенным UIStackView, но это будет плохим решением, потому что:
❌ нет переиспользования,
❌ много кода в ячейке,
❌ трудно добавлять элементы с отличающимися размерами.

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

Хочешь узнать как делают в Surf❓

С помощью RDDM мы создаём абстрактное описание ячеек — генераторы, которые являются мостом между моделью и ячейкой.

Абстракция на генераторах позволяет нам даже делать вложенные списки внутри вложенных списков 🤯

Подробнее расскажем в посте ниже 👇

Знакомство с генераторами на примере выпадающего списка

Мы показали примеры выпадающего списка и познакомили с концепцией, а сегодня расскажем как легко и просто реализовать эту концепцию с помощью RDDM.

Итак, каждой ячейке соответствует генератор, который отвечает на вопросы:
🔹как регистрировать ячейку,
🔹какого размера будет ячейка.

Хорошая новость в том, что в RDDM есть базовый генератор, который подходит для большинства ячеек и позволяет совсем забыть об этих вопросах.

Вернемся к выпадающим спискам из предыдущего поста. Код генератора вы можете видеть на первой картинке, а подключение плагина и инициализацию на второй.

🗣️ И это всё?
🏄‍♂️ Ага

RDDM делает большую часть работы за вас:
🔹вычисление позиций (IndexPath) для новых ячеек,
🔹вызов UITableView.insertRows при разворачивании списка,
🔹вызов UITableView.removeRows при сворачивании.

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

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