Архив недели @dmtopolog
Понедельник
Привет всем! Меня зовут Дима и я iOS-разрабочкик (сочувствующие кивки в аудитории). Буду с вами эту неделю. Из локдаунного Лондона (спасибо @lightdelay за отличную неделю) мы переносимся в практически такой же перекрытый Амстердам.
Прежде всего хочу респектануть предыдущим авторам сего коллективного твиттера (ну почти всем ;-)).
Ооочень много годноты понаписали тут за всё это время (сколько уже, года полтора-два?), лестно оказаться в такой хорошей компании.
Каждому следующему автору сложнее и сложнее создавать контент, ибо его уже было много: и тематического, и обыденного, и с нестандартной подачей, и порой даже фрикового...
Темы, кажется, были примерно все (а некоторые и понескольку раз), так что с точки зрения тем уникального ничего не ждите. Буду стараться выезжать на опыте (не в смысле, я дохрена опытный, а в смысле, что рассказывать буду про себя и про то, с чем в основном имею дело).
Первую половину недели планирую не уходить в платформенную специфику (постараюсь, чтоб всем было интересно), но в последствии придётся... от своей айосной сущности никуда не спрячешься.
Чёткого плана по дням нет, но вот примерный список тем, на которые мне есть что написать:
- про себя
- про Голландию в которой живу и работаю (про релокацию тоже поговорим, куда уж без неё)
- про ING (компания, особенности)
- про мобильную архитектуру (ну а как?.. немножко можно)
- про модульность (вцелом и в iOS в частности)
- про протоколы и экстеншны в iOS
Под конец, может дам себе волю и поговорю про что-то несвязанное с разработкой: книги, музыка, фильмы, спорт... игра в шахматы, в го, в покер плетение из бересты... сон, образ жизни, мировоззрение, философия, квантовая физика VS теория струн,... вращайте рулетку.
Но это всё неточно. Посмотрим как пойдёт.
Тред "Ты чьих будешь?"
Эпизод 1. Родной город Вологда. Первый опыт программирования - класс 5-й, год 99-й, когда в доме появился первый комп и отец притащил какую-то книжку про Basic. Изучали вдвоём с отцом (который от программирования сам был очень далёк).
Главное достижения на том этапе - это программки вычисляющие площади геометрических фигур и объёмы тел по введённым пользователем параметрам.
Потом я начал злоупотреблять компьютерными играми, и компьютер из дома исчез, не простояв, кажется и года. Интерес к программированию пропал, не успев толком начаться.
Эпизод 2. Старшая школа, год 2005-й, уроки информатики, паскаль и html. На паскале делали что-то не сильно сложнее моих программ по вычислению площади, а вот html меня поразил сильно.
Интернет тогда дома уже был и возможность сделать что-то, что работает в браузере и выглядит как сайт (пусть и примитивный) просто сносила башню.
Интерлюдия. Разговор с родителями "куда поступать после школы". Мать эмоционально восклицает: "Да забудь ты про программирование! К моменту твоего окончания программистов будет как собак нерезаных, так что не найдёшь работу". Мама боялась повторения своего опыта бухгалтера.
Эпизод 3. 2007г. Я учусь на инженерно-физическом факультете, лазерная физика. Первый курс. Мы кажется всей группой списываем лабы по СИ со старшекурсника.
Предмет ненавидели все, так что кажется списывали даже те, кто мог бы и сам сделать. Препод был наидичайший, мой интерес к программированию начал превращаться в неприятие. Как будто бы и к лучшему, что программирование на первом курсе и закончилось.
Эпизод 4. 2011г. На последнем курсе универа начал искать какую-то более или менее постоянную работу. В лазерной физике я уже разочаровался так что выбирал между проведением оптоволокна в жилых домах и продажей компьютеров.
В этот момент мне попадается объявление о наборе людей для внедрения и доработки 1С с месячным подготовительным курсом.
Эпизод 5. Конец 2012г. Питер. Я уже год как занимаюсь доработкой 1С-конфигурации БИТ: Отель. Солидный специались, на неплохом счету в отделе, получил недавно повышение и получаю уже 25к рублей.
Кажется даже в трудовой было записано, что-то типа 1С-программист, хотя программирование там было весьма кастрированное. 1С-программирование - это изменение конфиг-файлов без доступа к исходному коду продукта. Но возможности этих конфигов позволяют тебе сделать очень много.
Метапрограммирование, как оно есть. Если интересно, плюсуйте этот твит и я с удовольствием расскажу чуть подробнее, об 1С-программировании позже.
От кого-то из коллег, я узнаю что есть какое-то настоящее "объектно-ориентированное программирование", где можно не только манипулировать уже имеющимися типами объектов (как это было в 1С), но и создавать свои.
В это же время, один мой близкий товарищ, работавший в мобильном отделе некоего дейтинг-сервиса, стал активно зазывать меня в команду, заманивая модным офисом, бесплатным кофе, плюшками и джуниорской зарплатой в 30к-40к.
Причём люди нужны и в айос и в андроид. Надо было определиться, чем я буду заниматься. Так как сам этот мой товарищ был айосником (а значит было у кого спросить совета в случае затыков или проблем) я выбрал именно эту платформу.
Совсем с нулевым навыком меня туда брать были не готовы, так что я раздобыл себе на время старый макбук, купил книжку "iOS для начинающих", и начал смотреть стэндфордский курс от Пола Хоггарти.
Эпизод 6. март 2013г. Я устроился айос-джуном в дэйтинг-сервис Topface. Про компанию тут уже говорили мои бывшие коллеги. Кажется, большинство, из наших (из мобильщиков), кто сейчас вспоминает Topface согласно, что было очень здорово.
У кого-то ещё есть отдельный (всё ещё живой!) слак с коллегами с прошлой работы? ;-) Посоны, прошедшие со мной через ТФ, всем привет!!!
Эпизод 7. лето 2015. Я больше 2х лет уже айосник и волей случая уже тим-лид. Не потому что достаточно опытный для этого, а тупо потому что команда осталась без лида (3-4 человека) и я оказался самым опытным (и не боящимся ответственности).
Но вот меня тянет на приключения, всё любопытнее какого оно жить и работать забугром, всё меньше и меньше устраивает ситуация в РФ и вот я налегаю на английский и начинаю подаваться на заграничные вакансии. Рассматриваю в основном Европу.
Эпизод 8. Февраль 2016. Ещё в декабре я съездил на он-сайт в Booking (не взяли), погулял по городу и решил, что Амстердам - это там, где я бы хотел жить, так что я концентрируюсь на переезде в Нидерланды. Наконец получаю оффер от стартапа в Амстердаме и начинаю оформлять переезд.
Эпизод 9. 02.06.2016 с утра прямо из аэропорта Схипхол я приезжаю с чемоданом в офис (заселение во временное жильё ближе к вечеру). Ребят я уже знаю, 1,5 месяца работал удалённо из РФ пока оформлялись бумаги.
Интерлюдия. В один из первых рабочих дней я узнаю, что мой замечательный тимлид, к которому я с таким желанием сюда ехал, через месяцок отваливает из компании... я немножко в ахуе.
Компания называется Qardio. Выпускает свои смарт-девайсы по теме здоровья. Девайсы замеряют показатели тела (экг, давление, температура, вес,...) и общаются с мобильным приложением, информация хранится в облаке.
Через год я и тут тимлид по той же самой необходимости что и в прошлый раз.
Компания развивается, имеет офисы в Амстере (разработка), Лондоне (маркетинг, продажи и логистика) и Сан-Фране (дизайн и продажи), имеет производство на Тайвани, дружит с эпплом (как айосный лид, я даже общался с кем-то из яблочных представителей в их офисе).. всё вроде шоколадно
Классный коллектив (мне кажется с этим везёт). И даже руководство (прежде всего мой непосредственный бос СТО компании) - адекватные, увлечённые делом люди, с которыми и за работу поговорить приятно, и в баре под пиво посидеть интересно.
Всё хорошо... но бардачина в управлении и принятии решений страшный. Я как могу вместе с лидом бэкэнда пытаюсь направить это в продуктивное русло, СТО кивает, соглашается... но делает по-своему потому что "так сейчас правильнее"
Эпизод 10. Март 2019. Я устал от аврал-дривен-девелопмента и других неприятных моментов и после полутора лет поиска альтернативы (и 3х лет работы на Qardio) наконец нашёл то, что искал. Я перешёл в ING.
Ок, пара слов об 1С, как и обещал
1С - очень интересная, я бы сказал революционная идея, которая могла взлететь только на постсоветском пространстве. Конструктор для автоматизации бизнесс-процессов.
База (строительные блоки) всего 1С ПО написана и поддерживается небольшой командой профессиональных программистов (то ли на плюсах, то ли на шарпе).
Ими же из этих блоков собраны основные программные продукты (1С-Бухгалтерия, 1С-Предприятие,...) которые можно купить, установить... а потом платить за поддержку. А поддержки там немало ибо постоянно что-то меняется в законодательстве, что требует изменений в процессах.
Если же тебе стандартные системы от 1С не подходят, ты можешь либо собирать из тех строительных блоков свои программные продукты для учёта либо допиливать эти стандартные продукты под свои нужды.
Изюминка этого "допиливания" в том, что делать это можно было не особо разбираясь в программировании. Делалось это путём редактирования конфигов, которые были написаны на собственном 1С-языке программирования (том самом, где можно по-русски писать "если ... тогда ...").
Там есть объекты, функции, циклы.. есть свой язык запросов к БД (очень похожий на SQL, но естественно кириллический)... всё вроде бы серьёзно.
Однако ты не программируешь, а конфигурируешь программу. Т.е. сломать в коде ты ничего не можешь, но вот похерить данные, что-то нетуда перенаправить или затереть - это легко.
Т.е. одна из особенностей 1С в том, что так называемые 1С-программисты - это на самом деле "конфигураторы", бесконечно допиливающие какую-то 1С-софтину (или даже конфигурирующие что-то новое с нуля).
Программистов пишущих сам 1С десятки (ну может сотня-другая). "1С-Программистов" работающих над конфигурациями тысячи (если не десятки тысяч) по всему СНГ. В какой-то момент казалось, что в каждой уважающей себя конторе где пользуют 1С должен быть минимум 1 штатный 1С-программист
Порог вхождение - 1-2 недели и вот ты уже орудуешь регистрами (БД), документами (файлами) и проводками (командами по трансформации данных).
Мне почему-то кажется, только у нас на постсоветском пространстве (с нашим менталитетом и образованием) могла образоваться такая прослойка программистов-конфигураторов.
Ну и лично для меня это сработало очень классно для облегчение вхождения в "настоящее" программирование. Классно что можно туда попасть с улицы, без какого-либо профильного образования и через несколько недель уже что-то реальное "программировать"
Ок, пара слов об 1С, как и обещал
мини-тред про 1С тут: twitter.com/mobileunderhoo…
В ING я и работаю на текущий момент, о чём планирую рассказать подробнее завтра-послезавтра.
@mobileunderhood @A_SemperVirens Без цели все ограничится хелоуворлдом. А тут сделал мвп, можно в резюме сунуть. Даже можно читать @mobileunderhood с осознанием что целое приложение есть!
Вот тут не соглашусь. Кажется и нескольких хэллоуворлдов (в купе с горящими глазами и общей адекватностью) достаточно, чтоб начинать искать какую-то джуновскую работу (а там тебе уже и цель приложат, и возможностей развития подкинут) twitter.com/norrittmobile/…
Вторник
Сегодня поговорим немного про релокацию и жизнь в новой стране. Начну с пары опросов.
Какова на ваш взгляд главная (их всегда несколько) причина релокации (реальной или потенциальной):
Какая главная причина не уезжать, в случае, если такие мысли возникают (или если вы уже пережили или переживаете переезд):
Если что-то другое, пишите в комментах... Сложно вместить всё в 4 возможных варианта опроса (кажется, люди как-то больше вариантов умудряются делать...)
Да, тема релокации поднимается в этом (да и не только) аккаунте раз в несколько месяцев. Жаль у меня нет данных с предыдущих опросов. Интересно, есть ли какая-то динамика ответов?..
@mobileunderhood @andrey_oshev @vas3k Мне не важно выделяться, но мне важна свобода. Только тут я могу содержать многодетную семью при этом работая в районе 80 часов в месяц, остальное время занимаясь тем, чем считаю важным.
и плевать, что это с одного из прошлых обсуждений ;-) twitter.com/dimaip/status/…
@dimaip @mobileunderhood При переезде в развитые страны нужно быть готовым к понижению отношения твоей зп к тому, что получают люди вокруг. Простыми словами: ты больше не король мира, который получает очень много сразу после университета, а просто средний класс. Это многих расстраивает
и вот это вот тоже twitter.com/ruggerprogramm…
@mobileunderhood Либо высокая зп + политические, экономические и прочие риски. Либо живешь как все, безопасно и стабильно, но без особых понтов.
это как с инвестициями: либо доходность и риски, либо стабильность и низкий доход... совпадение? ;-) twitter.com/starkyru/statu…
В общем, картинка про релокацию у большинства адекватная (недаром килотонны статей и тредов написаны). Приоритеты у каждого свои, но какие-то общие позиции проглядываются. Всё-таки наше комьюнити тут довольно однородно.
Расскажу про себя, раз уж стою на сцене с микрофоном.
Что меня мотивировало на переезд:
Для меня на первом месте было любопытство. Очень было интересно, каково оно жить и работать зарубежом, насколько оно отличается от привычной России. Ещё со школы было любопытно.
На втором месте было нарастающее беспокойство по поводу политико-экономической ситуации в стране. (то что в опросе я назвал "там жизнь приятнее/спокойнее")
Про то, что рынок труда в сфере АйТи в РФ хорош я знал. Как с этим обстоит зарубежом понятия не имел.
Ну и про деньги иллюзий не строил. И про цены ситуацию примерно понимал, и про налоги. Так что в деньгах готов был и потерять.
И ещё фоном, я постоянно думал, что раз уж занесло меня в АйТи, и раз работу в этой сфере можно без труда найти зарубежом - то надо не упустить возможность попробовать.
Что меня демотивировало:
Сложность и неизведанность жизни в другой стране. Т.е. это и манит и пугает одновременно. В 2010 я по WorkAndTravel провёл лето в Штатах, так что представлял, что такое жить в чужой стране, где свои правила, свой ритм жизни, свои обычаи и устои, своя культура.
Английский был на уровне "понимаю 50% речи, когда смотрю фильмы, сам говорю только на бытовые темы". Опять же спасибо W&T я трезво представлял свой уровень (который без практики с тех пор ещё и подупал), что я могу, а что - не очень.
Отдаление от друзей. Невозможность посидеть за пивом или провести вечер за настолками в компании близких людей тоже заставляла серьёзно задуматься. Мне это было важно.
Экономический аспект. (упомянем деньги ещё разок) Я не до конца представлял каково будет соотношение зп/траты в моём случае зарубежом. Были опасения, что денег будет оставаться сильно меньше.
last but not least, жена, которой скорее всего будет сложно найти работу в другой стране.
Отмечу, что я никогда не ставил целью "свалить из страны". Цель была "поехать пожить годик-другой, а там видно будет". (прошло почти 5 лет... живу, смотрю...)
@katyatyukova @mobileunderhood я бы еще добавил возможность обзавестись своим жильем в столице, что по сравнению со многими другими европейскими странами, звучит как недосягаемая мечта
Ну ипотеку никто не отменял ("ипотека? а что это?" подумают те самые страдальцы с 400к/мес) twitter.com/TheTaier/statu…
Локацию я выбирал следующим образом: Европа мне была всегда была ближе по духу и образу жизни. Ни в Штатах, ни в Азии, ни в Арабских странах мне жить особо не хотелось.
Внутри Европы мне были более интересны северные и западные страны. Тут и климатическая близость, и экономическая ситуация, и рынок труда и отношение к порядку и законам.
Ну и бонусом, хотелось жить в красивом и удобном но немаленьком городе. Так что выбирал в итоге между Британией/Ирландией, Скандинавией, Голландией и Германией.
Как я уже упоминал на окончательное решение повлияла поездка в Амстердам, когда город как-то влюбил меня в себя. Понимаю, что так же мог бы влюбиться в какой-то другой город. По прошествии нескольких лет я очень рад этому стечению обстоятельств.
Сейчас уже очень сложно куда-то отсюда переехать, даже когда очень хочется, даже когда есть какие-то интересные возможности по работе (ребята из ФБ, намекните там уже своим, что пора открывать офис в Амстере ;-))
@ruggerprogrammr @dimaip @mobileunderhood При переезде в места вроде Лондона еще вдобавок оказывается что ты вообще не самый умный в комнате, и что вокруг толпы людей гораздо талантливее чем ты когда-либо будешь
Мне кажется, это отрезвляет. Главное работать над тем, что это переставало тебя пугать/расстраивать, а наоборот мотивировало. Сложно, но можно. twitter.com/alexsavinme/st…
Что оказалось на деле по истечении периода адаптации:
Работа. АйТи в Европе плюс/минус то же самое. Разница между большой компанией, стартапом и галерой в рамках одной страны существеннее, чем разница между двумя компаниями схожего типа в разных странах.
Рынок труда в Европе очень неоднородный. В больших городах типа Амстера, Берлина или Варшавы по мобильной разработке варианты есть, но ассортимент ощутимо меньше чем в Москве или Питере.
Мне кажется, даже в Минске или Киеве вариантов побольше (отпишитесь, кто может сравнить).
В городах поменьше (или поюжнее) ситуация с вакансиями похуже.
Особняком стоит Лондон. Где-где, а там с рынком мобильной разработки всё хорошо (и не только из-за офиса ФБ ;-)), возможно даже лучше чем в крупных городах России. В остальной Британии, кажется, всё как и в остальной Европе.
Жизнь. Она другая да, но т.к. культурные различия между Европой и нами не столь велики, привыкаешь довольно быстро.
Привыкаешь ездить на велосипеде, привыкаешь заполнять налоговые декларации, привыкаешь к оставленным на пороге посылкам, привыкаешь к индивидуальному бойлеру в квартире, привыкаешь к парацетамолу как универсальному лекарству, привыкаешь здороваться с незнакомыми встречными...
привыкаешь что в детских садах нет понятия сменной обуви, привыкаешь к более крепкому пиву в меньшей таре... так привыкаешь, что потом на родине всё начинает казаться "не так" (то, что раньше было нормой и обыденностью).
Деньги. Их тут меньше (имею ввиду после вычета всех расходов), и меньше ощутимо. Я был готов. С рождением ребёнка трат прибавилось и пришлось уже прилагать усилия, чтоб сводить ежемесячный баланс в ноль и не выходить в минус.
Без семьи (или когда оба получают зарплату уровня АйТи) картинка совсем другая =)
Жене действительно трудно (труднее чем в РФ) найти тут работу, особенно ту, которая бы радовала.
Язык. Тут всё обернулось лучше, чем я ожидал. Для работы моего уровня без проблем хватило. Мой уровень оказался примерно средним для понаехавшего. Для общения с друзьями за пивом в целом тоже стало хватать в последнее время, но тут всегда есть куда расти.
Постоянную прокачку не отменяю и по сей день.
Друзья. Их конечно очень не хватает. Особенно сейчас, когда уже год авиасообщение и путешествия весьма затруднены. Переписки и перезвоны с ними помогают, но на 100% не замещают (да и не со всеми работает удалённый формат в принципе).
Конечно появились и новые приятели, в том числе и весьма близкие, в том числе и русскоязычные (т.е. и языкового барьера нет, и менталитет один). Так что этот аспект тоже понемногу налаживается. Когда есть с кем поговорить по душам, жить легче.
Появление друзей - процесс долгий и тут (как и в отношениях) от тебя зависит далеко не всё, сложно что-то форсировать. Велика доля везения/невезения
Бонусы. Приятным бонусом стал Амстердам как среда обитания. Город мне кажется ощутимо красивее и удобнее Питера. Самое главное, что при размере в 7 раз меньше, кажется, что в городе есть всё что нужно для комфортной жизни. Тут всего хватает.
После жизни в РФ у меня было когнитивное искажение: что город либо огромный (как Мск или СПб), либо с недоразвитой инфраструктурой (как родная Вологда и все города-немилионники). А тут оказывается всё есть, и при этом до всего ты доберёшься максимум за полчаса на велосипеде.
Поездка в гость к друзьям - это 10-40 минут, в магазин за едой - полчаса (туда-обратно), на работу 15-40 минут... Начинаешь искренне со всеми жалеть бедолагу-коллегу, которому приходится 2 дня в неделю ездить в офис из соседнего города (и тратить 50 минут на дорогу!)
Это аспект, который мне вообще не приходил в голову, и который приятно удивил постфактум.
Всем привет. Давайте сегодня поговорим об эмиграции. Стоит переезжать или нет? А если стоит, то куда? Обсудим!
Тут уже продолжают дискуссии начатые, полгода назад, когда так же обсуждали релокацию (достаточно много интересного тогда наобсуждали) twitter.com/mobileunderhoo…
@mobileunderhood Я правильно понял, что ты сейчас в Амстердаме? Расскажешь, как переехать и где искать работу?
Тут никакой особой специфики. Рассылаешь свои резюме, активизируешься в LinkedIn, можно какие-то другие площадки тоже использовать (monsterboard для Голландии)... Ищешь вакансии, где работодатель обеспечивает тебе визу. При хорошем резюме, рекрутеры быстро возьмут тебя в оборот. twitter.com/maks_gorin/sta…
@mobileunderhood Что является хорошим резюме для зарубежных компаний при учёте того, что они не знают многих русских крутых компаний?
А им конкретные названия не так важны. Тут важно, чтоб ты мог грамотно описать, что ты делал, над какими проектами работал, какими навыками обладаешь. Написать в CV и в последствии рассказать на собесе (углубившись, где нужно) twitter.com/xd720p/status/…
@mobileunderhood Мне кажется, что переезд в другую страну, это в первую очередь огромный и крутой жизненный опыт. Естественно, это не просто, в первую очередь психологически. Надо понимать, что тебя ждет. Но главное помнить, что если прям не зайдет, всегда можно вернуться.
плюсую twitter.com/Crazy_surfer/s…
Ещё немного отдельных мыслей про Нидерланды
Тут очень много экспатов (прежде всего в больших городах, особенно в Амстердаме), причём не только в АйТи.
Тут свободно говорят по-английски почти все. По моему скромному опыту Амстердам - самый англоговорящий город из тех, где английский не является национальным языком. (Может Стокгольм поспорит, но вряд ли... слишком уж тут близкие культурно-исторические связи с UK)
#1 Work-life balance Никто не пишет после 6 вечера, на выходных или когда ты в отпуске. Поначалу, я думала, что дело во мне, и что-то не так. Но потом оказалось, что большинство коллег так работают, и это норм.
Тут (как и в среднем в Западной Европе) чтят work-life balance. В соседнем аккаунте буквально вчера обсуждали то же самое про UK: twitter.com/produnderhood/…
У нас в целом то же самое.
Недавно горел проект, в какой-то момент можно было поднажать на выходных, чтоб закончить в срок. Естественно никто о таком не попросит тебя.
Я вызвался поработать Суперменом (естественно с условием, что отгуляю эти выходные потом на неделе). Меня 3 разных начальника разного уровня спросили приватно, не просил ли меня кто об этом, и действительно ли это не окажет негативного влияния на мою жизнь.
А то ведь поработаю так выходные, а потом в бёрн-аут, плавали - знаем! (о бёрнаутах ещё поговорим)
А собственно, что откладывать... Бёрн-ауты. Опять же много чего уже было сказано, кажется, даже тут кто-то уже вёл отдельный тред.
Бёрн-аут это реальная проблема, человек впадает в апатию (или иногда даже в депрессию) на почве работы и его без помощи специалиста очень сложно оттуда вытянуть.
В Голландии (как и много где в "развитых" странах) это официальный диагноз со сроком реабилитации и возвращения к работе до 2-х лет, в течении которых работодатель или государство будут выплачивать тебе 70%-100% твоего оклада.
Главная проблема тут, что это не перелом ноги, а ментальное состояние, и отличить реально выгоревшего человека от симулянта очень сложно даже будучи профессионалом
Так что конечно многие этим пользуются. А трудовое законодательство таково, что всем проще закрывать на это глаза и просто оплачивать всем реабилитацию. (Реабилитация - это режим отдыха от работы, с периодическими сессиями с психологом)
На двух моих работах в Голландии в сумме человек 7 знакомых были на бёрн-ауте в тот или иной момент (в Кардио в один момент выгоревшими были 3 человека из офиса в 30-40 человек), и ещё человек 5 знакомых вне работы.
@cocoryse @mobileunderhood Переработки как один из симптомов высокой конкуренция большого города, куда съезжаются "покорять". Я не спец, но мне кажется традиционно было жестко в Сити (банки, трейдинг, консалитинг), а теперь еще и big tech из Америки и стартапы
С полей сообщают что в UK не всё так сладко с переработками (как минимум в разных конторах по-разному) twitter.com/ruggerprogramm…
Среда
Сегодня расскажу про ING и немного уже начнём копать внутрь наших iOS проектов.
Начну с того, почему ING. Мне очень хотелось поработать в большой компании, в большом мобильном отделе, в большой айосной команде. Хотелось посмотреть на более или менее отстроенные рабочие и технические процессы и поучаствовать в их дальнейшем налаживании.
Хотелось пощупать серьёзный CI и позаниматься платформенной разработкой, хотелось других масштабов.
Всего этого я получил и продолжаю с удовольствием получать. Наверное в какой-то момент будет достаточно и надо будет идти обратно в стартапы (или просто переходить на контракты, как тут делают все состоявшиеся разработчики). Но пока всё путём.
Говоря о крупных АйТи конторах в Амстердами в голову приходят Uber, Booking... ну Atlassian (но у них насколько я знаю какой-то обширной мобильной разработки нет). Ну EPAM который нынче везде (но их масштабов тут я не знаю.. и не продукт это).. В принципе и всё.
Но тут нам на помощь приходят банки.
Как и в РФ банки тут варятся в весьма конкурентной среде. Не знаю, что именно движет технических прогрессом в Российских банках и как так получилось, что лет 5 назад банки стали чуть ли не главными АйТи компаниями в стране (есть мысли, но сейчас не об этом).
Нынче многие банки (и финтех вцелом) на передовой АйТи - это факт (как минимум в мобилках).
Основные банковские бэк-энд сервисы чрезвычайно зарегулированы, обмазаны секурностью и ломятся под легаси-кодом десятилетней давности, являясь главными представителями того самого "кровавого энтерпрайза". С мобильными приложениями дела обстоят гораздо лучше.
Ещё до ковида (а с ковидом это лишь ускорилось) банки в Голландии начали активно резать косты и сварачивать свои отделения по стране. В замен этого они предлагают интернет-банкинг и мобильные приложения. Так что теперь это - одно из основных полей конкурентной битвы.
Стоит отметить, что в Голландии финтех вообще очень активен в плане мобильной разработки от криптокошельков, биржевых торгов, всяческих аггрегаторов подписок до кучи каких-то B2B решений, которые вообще непонятно чем занимаются (но судя по всему неплохо живут).
На айосных митапах больше половины народа - это ребята из финтеха.
ING - крупнейший Голландский банк; в топ 10 банков по Европе с отделениями во многих странах (в основном Европа, но что-то есть и в Австралии, Сингапуре, Индии, Японии, Турции и т.д.) en.wikipedia.org/wiki/ING_Group
Даже в РФ, Украине и Казахстане какой-то бизнес есть (но как понимаю немного и только B2B)
В каждой стране своё мобильное приложение, в некоторых странах не по одному (отдельное для бизнеса, отдельное для инвестиций, и т.д.).
Уже не первый год ведётся масштабная работа по объединению всех и вся, но там очень много подковёрной борьбы, интриг и политики, налаживание общих инфраструктуры и контрактов для бэкэндов и прочей работы, которая занимает годы.
Но процесс движется и очень много масштабных и интересных проектов создаётся на основе (и для продвижения) этих изменений.
Мобильного отдела как такового нет. То подразделение, где работаю я, включает в себя несколько фиче-тимов работающих над мобильным приложением для Голландии и Бельгии. Несколько - это порядка 2х-3х десятков, включая команды из Недерландов, Бельгии, Испании и Румынии.
Мобильных разработчиков - человек 30 на каждую платформу, плюс ПО, ui/ux-специалисьы, несколько разработчиков АПИ, девопсов, дата-аналитики, спецы по accessibility... ну человек 200-300 наберётся.
Со Сбером не сравнить, но всё равно народу немало ;-)
@mobileunderhood А что интересного в плане технологий и продукта на мобильных девайсах в банках происходит?
Ну в РФ сходи на любую мобильную конфу и парни из Сбера, Тинькофф и Альфы много всего интересного расскажут. Что интересного у нас, расскажу дальше twitter.com/Matveyich/stat…
@mobileunderhood Кстати, встречал мнение, в плане айти российские/снгшные банки более продвинутые и удобные для клиентов, нежели европейские и американские. Врут?
всё так, не врут. Банки, интернет-провайдеры и мобильные операторы. twitter.com/algridmd/statu…
@mobileunderhood Было бы интересно узнать, как у вас собеседования проходят. Всё-таки крупная компания, но не техгигант, но и не стартап. Любопытны требования и этапы.
Каких-то общих стандартов по всей компании нет. Всё отдано на откуп отдельным чаптерам (о чаптерах и скводах расскажу сегодня). Так что везде по-разному. twitter.com/CocoTut02/stat…
В нашем iOS чаптере до последнего времени было несколько беспорядочно. У меня как раз в прошлом году была цель (про цели тоже расскажу ещё) наладить процесс найма, так что только к прошлой осени удалось выстроить что-то более или менее чёткое.
Сейчас это:
- отсмотр резюме чаптер-лидом
- тестовое задание
- техническое собеседование + собеседование с чаптер-лидом
Естественно были обычные споры включать/не включать тестовое. Но я отстоял, чтоб оно было. (Да, я за тестовые)
Техническое собеседование - это 1 час, где мы обсуждаем тестовое (если есть вопросы), ну и говорим за iOS (общие знания, платформа, наши языки)
После этого 30-40 минут с кандидатом говорят чаптер-лиды, проверяют общую мотивацию, насколько человек подходит нам по общим характеристикам (всё остальное, исключая технические навыки... софт-скилы).
Оба собеседования идут друг за другом (в одной переговорке раньше, сейчас - в одном канале). На каждом по 2 интервьюера. Сразу после блока все вчетвером собираются и принимают решение по кандидату.
По сути 2 этапа получается: тестовое задание + само интервью (~2 часа). Тестовое стараемся в течение недели проверить, если человек проходит в течение следующей недели стараемся назначить интервью.
Фидбек кандидату даёт чаптер лид (через рекрутера, если он привёл кандидата) на следующий день.
@mobileunderhood Например, в вашу платформенную команду iOS как собеседования проходят? Что критически важно знать? Например, как в ФААНГ нет смысла подаваться без знаний алгоритмической части.
Алгоритмы (как и тестовое) - это кажется везде предмет спора =). Мы решили не включать их. Я лично из лагеря противников алгоритмов на собеседованиях. twitter.com/CocoTut02/stat…
Как у нас всё устроено огранизационно. Мы работаем по так называемой модели Спотифая с командами (squads) и чаптерами (chapters).
Суть модели - это две пересекающиеся на конкретном работнике иерархии: техническая и продуктовая.
По технической разработчик является частью чаптера, чаптер - часть айти-зоны и тд. По продуктовой, разработчик - часть своей фиче-команды, команда - часть трайба и тд.
Получается, у разработчика нет никакого прямого начальства, контролирующего все аспекты его работы. Официально - это чаптер-лид, но он занимается только техническим развитием разработчика и помогает ему в решении технических вопросов.
Чаптер-лид может понятия не иметь, чем разработчик занимается в команде, над какими задачами работает и насколько он эффективен в этой связи.
Но он понимает, какое место этот разработчик занимает в чаптере, насколько он значим для проекта, как много технических вопросов он закрывает и какие технические компетенции имеет.
Со своей стороны разработчик ответственен перед командой за вклад в продукт (за каждой командой закреплён какой-то функционал, какие-то фичи), а перед чаптером - за технический вклад в проект.
Продукт - это непосредственно фичи и баги. Тут есть скрам, бэклог, спринты... всё как везде.
Технический вклад - это качество кода, техдолг, технические улучшения и миграции, переход на новую версию сетевого слоя или UI-компоненту, код-ревью, собеседования (если разработчик привлекается), какие-то дополнительные технические проекты. По сути тут есть свой отдельный бэклог
И вот разработчик сам определяет для себя задачи, черпая их из обоих бэк-логов и балансируя между ними.
@mobileunderhood Если человек делает UI, много знать про стек и немного про деревья и понимать сложность своих while{for{}} может дать преимущество а работе, если конечно там не absolutelayout и надо только двигать view в визуальном редакторе.
Кажется, это то о чём я и говорил: приятный бонус. twitter.com/ikimruslan/sta…
Разговоры про алгоритмы навели на вопрос: до какого-то уровня наверняка можно без алгоритмов обходиться, но может ли программист в мобильной разработке считаться сеньором без знания алгоритмов?
Четверг
@mobileunderhood Программист в мобильной разработке может считаться сеньором, даже без навыка читать :)
вот это респектнул нашему брату! twitter.com/nordilion/stat…
@mobileunderhood Так же как и без знания сетевого стека, ассемблера, джедайского пользования гитом, громкой клавиатуры и многого другого :) Если ты решаешь (а в идеале сам находишь) проблемы, приносишь ожидаемую пользу, помогаешь расти другим и себе без знания алгоритмов - почему нет?
Главное "находить" проблемы, а не "создавать" их ;-) А так, пинту эля за чёткость формулировки, господину в регбийке! twitter.com/ruggerprogramm…
@mobileunderhood Любой код, который ты пишешь, это алгоритм 🤷🏻♂️
Ждал, кто первый спросит "а что есть алгоритм в данном контексте?" Но давайте всё-таки более специфично подходить к вопросу. Алгоритмы в том понимании, в котором они идут в одноимённом университетском курсе и включаются в "алгоритмическую секцию" интервью. twitter.com/AndreyMishanin…
Ещё о специфики работы. (Есть подозрения, что многое применимо к большой компании в принципе.)
Упомяну адовую многослойность (а соответственно и сложность), что на фронте, что на бэке.
На мобильном фронт-энде это например 2 сетевых слоя (общий для всех стран, и один NL-специфичный поверх первого) или отдельная дизайн-система для UI-компонентов.
Фичи (а каждый сетевой слой, например - отдельная фича) - это отдельные модули, контролируются отдельными командами и живут в отдельных репозиториях (о модулях поговорим подробнее).
На бэке слои - (очень упрощённо) это расстояние от конкретного сервиса с базой данных до АПИ, который дёргает мобилка. Часто нужны какие-то аггрегированные данные из разных сервисов, так что есть какие-то промежуточные слои.
Ну и пару проксей для секурности воткнуть тоже просто необходимо... куда без этого!
В итоге, когда возникает какая-то проблема с запросами-ответами (а ты, допустим не копался ещё в этом всём), ты сначала тратишь полдня, разбираясь что же на самом деле уходит в сеть и почему. А потом, если выясняется что на фронте всё чисто, пытаешься нащупать проблему на бэке.
Ходишь от одной команды к другой, пытаясь понять, какой именно слой лажает. Каждая бэкненд команда будет прикрываться своим бэклогом, зелёными тестами и тотальной занятостью разработчиков.
Чем дальше бэк (тот сервис, который тебе нужен) и фронт разнесены по структуре организации, тем больше это похоже на разные компании со всеми вытекающими. В смысле, что сложнее достучаться и добиться помощи.
На самом деле сильно разнесённые команды - это не только дихотомия фронта и бэка. Вполне могут быть 2 мобильные команды работающие над одним продуктом, но одна из них находится в Брюсселе или Мадриде, а другая в Амстердаме или Дюссельдорфе.
И вот 2 эти команды решают одну задачу (например интеграция модуля в хост-приложение), но видят решение по разному и даже после нескольких раундов обсуждений не могут прийти к консенсусу.
Обычно это решается поиском общего начальника где-то вверх по иерархии и надавливанием на него с обеих сторон (кто глубже продавит... или у кого связи и авторитет).
Но иногда общий босс - это председатель ING Group, и интеграции модуля в айос приложении - не его уровень компетенции. Тут уж какие-то менеджеры из середины цепи будут договариваться, вытогровывая друг у друга какие-то уступки, не особо разбираясь в технических деталях.
Или вот ещё случай из жизни. Какому-то из сервисов нужно знать локаль пользователя, чтоб возвращать локализованный текст, например. Всё кажется тривильно, мы же засылаем локаль с клиента на сервер при каждой авторизации...
Но нет, по какой-то никому не ведомой причине локаль не представляется возможным прокинуть с одного бэкэнд сервиса на другой. Поэтому все бэкэндеры дружно просят нас совать её в хэдер каждого запроса.
Мы в мобилках саркастически предлагаем добавлять туда все метаданные пользователя, девайса и положение звёзд в момент отправки запроса. Ну мало ли кому пригодится.
В общем фронтенд против, и начинаются долгие раунды переговоров с привлечением архитекторов и вышестоящих менеджеров.
В итоге после долгих переговоров бэкенд соглашается на то, что это какая-то ересь и нужно всё-таки прокидывать локаль между слоями бэкенда... начинают работать в этом направлении и даже что-то выкатывают...
Но вот незадача локаль прокидывают с одним айди пользователя, а ожидают с другим (в смысле, что разные сервисы основываются на разных системах идентификации пользователя.. упрощённо: айди человека против айди его аккаунта)
И по какому-то стечению архитектурно-исторических обстоятельств, эти два айди не удаётся связать между собой.
А потом ещё внезапно появятся ребята из секьюрити, которые скажут, что не стоит вообще прокидывать локаль между этими сервисами, потому что где-то что-то торчит во внешнюю сеть и это попахивает возможной утечкой личных данных.
А любые вопросы так или иначе связанные с секурностью и приватностью сразу блочат все намечающиеся изменения, дабы чего не вышло... в итоге все пользователи независимо от языка на девайсе продолжают получают пуши на голландском.
Это, конечно, всё крайние случаи... но всё же. Суть в том, что в большой организации даже решение самого тривиального вопроса порой может занять очень много времени.
@mobileunderhood Ну вот, если есть из кого выбирать, то секция алгоритмов даст сравнить. Ведь как проверить, что "если надо разберется", когда на входе даже не проверяется разобрался ли с чем-то заранее известным (списком задач). Но согласен, тема спорная, не всем командам нужна на разных этапах.
Согласен, если можешь себе позволить использовать алгоритмы как один из входных фильтров (и при этом иметь на выходе адекватное количество кандидатов), то почему бы и нет. Тут всё упирается в количество заявок на входе воронки. В FAANG это всё мне не кажется диким ;-) twitter.com/ikimruslan/sta…
Разговоры про алгоритмы навели на вопрос: до какого-то уровня наверняка можно без алгоритмов обходиться, но может ли программист в мобильной разработке считаться сеньором без знания алгоритмов?
Кажется мы достигли баланса и проценты уже не меняются особо. Мне тоже кажется, что даже для сеньора в нашем деле это не определяющий навык. twitter.com/mobileunderhoo…
"Какого же хрена в таком кровавом энтерпрайзе работать!" - воскликнет читатель после всего что я понаписал про работу в банке. "Да даже на галере лучше!"... Давайте поговорим про положительные моменты.
Процессы.
Какие-то вещи работая в стартапе не реализовать потому что нужно пилить продукт, быстро и много. И это нормально, это специфика стартапов. Часто компания уже вроде заматерела, и темп развития подсбросила, а процессы налаживать не хочет, в этом отношении так и осталась "стартапом"
Чего мне не хватало по части процессов в подобных компаниях:
Настройка и поддержка развесистого CI с тестами, интеграциями и системами статического анализа. (Согласитесь, на небольших проектах это особо и не нужно)
Следование поставленным планам, работа над тем, что было оговорено. Стартапу нужно быть гибким и постоянно подстраиваться. То к чему рвались вчера уже не ориентир, то над чем работали последний месяц можно выкинуть: планы быстро меняются.
Какая-то рефлексия, ретро, работа над ошибками. Какие-то меры, чтобы не наступать на старые грабли.
Чёткий процесс работы над задачей: ux/ui-проектирование, обсуждение между стейкхолдерами, дизаинерами и разработчиками на начальных стадиях, тщательная проработка механики и переходов между состояниями.
Чёткая постановка ТЗ на выходе
Даже банальное обсуждение нового АПИ между фронтом и бэком есть не везде.
Definition of Ready (DoR) - когда можно сказать, что задача готова к разработке) и Definition of Done (DoD) - что именно должно быть реализовано, чтоб фича считалась законченной.
Отдельная боль - это оценка задачи, которую в стартапе нужно дать быстро и не имея чёткого ТЗ.. естественно потом тебе за эту оценку и отвечать.
В ING никакой оценки ты не даёшь пока все основные моменты не ясны, дизайн не продуман и все галочки не поставлены в DoR.
Чёткие периодические релизы (release trains) - это требует и технической организации, и особой организации работы персонала.
Какой-то план роста разработчика, понимание, что тебе необходимо для повышения. (Не то чтобы мне конкретно этого не хватало, но знаю людей, для которых это принципиальный момент).
Процессы организации работы 30 разработчиков над одним проектом - это тоже ново и интересно, если до этого ты работал только в маленьких командах.
Чем больше команда, тем больше правил, формализации и туллинга вокруг разработки. Это иногда замедляет разработку (если что-то ломается), но в целом без этого никак.
Задачи.
Многие наслышаны историй про сеньоров, которые приходят в стартапы и начинают всё перепиливать, рефакторить и доводить до ума... останавливая весь фиче-девелопмент, само собой.
Это такое себе. Стартап - это не про качество кода и правильную архитектуру, а про гибкость, драйв, азарт, надежду и фичи, фичи, фичи.
Только когда у тебя устоявшийся продукт, большая команда и ощутимый ресурс, ты можешь позволить и платформенную команду содержать (чью бизнесс-вэлью не так-то просто обосновать далёким от технологии менеджерам), и рефакторинги проводить где и когда нужно...
и задачи выполнять не "быстро" а "правильно", если надо попробовать разные решения и выбрать более оптимальное - пробуешь, разбираешься в нюансах, пилишь MVP, сравниваешь.
Немного конкретики по задачам; в чём мне довелось принять участие за время работы в ING (и что мне кажется интересным):
Разработка компонентов для базовых фреймфорков. Тут интересно то, что компонент толжен быть общим, употребимым в различных юзкейсах, кастомизируемым, все эджкейсы должны быть хорошо протестированы. Иначе к тебе придут, и придётся дорабатывать, а то и переделывать.
Копание в CI (развлечение на любителя, понимаю). Сначала копался в кишках нашего гитлаба (обильно обмазанного скриптами). Потом участвовал в переводе всего CI с gitlab на MS Azure.
Разработка нового модуля инвестиций. Модуль для нескольких приложений в разных странах, а соответственно много стэйкхолдеров, разное законодательство и регулирование.
Тут интересен был сам процесс: проектирование АПИ сразу с несколькими слоями бэкэнда, взаимодействие с коллегами из других стран (вряд ли вы можете представить, насколько отличается, например Голландский и Бельгийский менталитеты... я точно не мог)
(чувствую себя, как будто на собеседовании о своём опыте рассказываю =)) )
Вообще бОльшая часть моей работы состоит в поддержке старых и создании новых модулей для приложений в разных странах. Тут тоже и организационные вызовы и технические. О модулях мы отдельно поговорим в один из следующих дней.
На больших проектах появляются такие задачи, которых просто не может быть на проектах поменьше. Можно сказать, что большие команды создают себе проблемы, которые потом сами и решают. И это может быть очень интересный и полезный опыт.
Команда.
@ruggerprogrammr @dimaip @mobileunderhood При переезде в места вроде Лондона еще вдобавок оказывается что ты вообще не самый умный в комнате, и что вокруг толпы людей гораздо талантливее чем ты когда-либо будешь
Вот этот твит очень хорошо выражает то, что я ценю на своей текущей работе: twitter.com/alexsavinme/st…
Мне чертовски не хватало этого в маленьких командах. Когда ты самый опытный, очень трудно учиться у других (всегда есть чему, но мало). Начинаешь глубже копать в бэкэнд или соседнюю платформу. Но вот чтоб увидеть/услышать что-то новое про родной айос - вот этого не хватает.
Тут тупо теория вероятности: если в команде 30 разработчиков (и какая-то фильтрация есть на входе), как ни крути а будут люди с интересным опытом, отличающимися взглядами и новыми для тебя знаниями.
Команда у нас подобралась очень классная. Все разные и честное слово нет ни одного плохого или просто ленивого разработчика.
Свобода.
В больших компаниях обычно больше свободы выбора. У нас, конечно, не ФБ, но в разумных границах ты сам решаешь чем заниматься внутри команды.
Если есть желание, можно попробовать перейти в другую команду (если тебе там будут рады) или даже на другой проект. Бывает, что человек меняет кардинально род деятельности.
В мою команду с начала этого года поступил джун, который полгода до этого писал другое приложение на React Native внутри ING. А год до этого вообще был дата-аналитиком.
Знаний iOS (как и ооп, например) у него примерно 0. С такого уровня джунами мне ещё не доводилось работать - новый челлендж опять таки).
Я приставлен к нему личным ментором. Половину рабочего времени он занимается изучением АйОса (вторую половину - делает какие-то простенькие задачи). Я думаю, что было бы со мной, если джуном я бы развивался в таких же тепличных условиях... хз, но белая зависть иногда накатывает.
В соседней iOS команде есть джун-разработчица, которая до этого работал в отделении банка, просто общалась с клиентами. Никакого АйТи опыта или образования у неё нет. И довольно быстро прогрессирует девушка.
Конечно не всегда такие кардинальные смены направления это удачная идея. Есть примеры и неудачных переходов. Но здорово, когда компания даёт тебе шанс.
@mobileunderhood Я тут уже писал свое мнение, просто дублирую 🙂 twitter.com/mobileunderhoo… Имхо без знания "алгоритмов" можно написать плюс-минус все что угодно(благо уже есть куча АПИ и библиотек), просто это займет много времени, а работать будет очень плохо, медленно и жрать кучу памяти.
Ну ооочень зависит от специфики твоей работы. Не все же занимаются оптимизацией компиляции гигантского проекта ;-) twitter.com/maksim_ovtsin/…
"Мы строили, строили... и наконец построили". Об архитектуре много не будем, но пару мыслей накину.
За архитектуру любит потрещать подобающее большинство разработчиков, и я не исключение. Правда смысла обсуждать что-то без конкретного проекта немного.
Архитектура должна решать какую-то задачу, что-то более частное, чем "создать мобильное приложение". Пока нет чего-то более определённого и говорить толком не о чем.
Модели, паттерны, аббревиатуры... Мы выбираем ту или иную модель и начинаем воплощать её в проекте.
Как бы классно всё ни было в теории, на практике появляются миллион деталей, которые сложно уложить в стройную теорию. И даже если по началу уложили, в течение дальнейшего развития проекта местами это делать всё сложнее.
Ты гуглишь, как другие решают похожие проблемы, спрашиваешь коллег (если есть у кого спросить)... и в итоге как-то приспосабливаешь выбранную архитектуру под свои нужды.
В итоге существуют сотни вариации какого-нибудь MVVM, потому что у каждого он немножко свой. И часто люди говорят об одном паттерне, имея ввиду совсем не одно и то же.
Главная претензия к основным архитектурным паттернам в iOS - это их ограниченность одним экраном. Тот или иной паттерн обычно говорит лишь, как мы распилим view controller, чтоб он у нас не был massive.
А дальше что? Как мы переключаемся между экранами или сценами? Как переходим из одного юзер-флоу в другой?
Тут кто-то вспомнит про координаторы (презентеры, интеракторы). Хорошо, тут как-то порешали.. А что делать с остальным? С сервисами, например.
Допустим у нас какое-то взаимодействие с локальной БД, сетевой слой, какие-нибудь сервисы для внешних bluetooth-девайсов, авторизация, кэширование изображений...
какие-нибудь независимые от экранов фоновые демоны (причём какие-то привязаны к циклу всего приложения, а другие к сетевой-сессии, например).
Можем мы предложить какие-то типовые модели для решения этих проблем?
Мне кажется, не особо.
Если в плане низкоуровневых паттернов (singleton, factory, adapter, observer,...) и логики построения экранов (MVC, MVVM,...) задачи у всех примерно одинаковые, то построение приложения из этих экранов-модулей уже сильно отличается от приложения к приложению.
Тут мы вспомним мы вспомним best practices, про DRY, и про KISS; согласимся что dependency injection обычно лучше использования синглтона; попеняем на модульность, чистые интерфейсы и понятный не слишком запутанный граф зависимостей.
Но вряд ли сможем что-то общее вывести за пределами этого.
Пятница
О чём вы думаете, когда видите слово "модульность"?
У меня, конечно, первые мысли профессиональные - программные модули, но если сделать над собой усилие и направить мозг в сторону от работы, сначала возникают какие-то неясные геометрические ассоциации: фигуры и формы, разделение целого на части.
Но потом мысль уносится в область архитектуры (той, где люди имеют дело с постройками).
"Модульность" - это и то как застраиваются районы внутри города (район - это модуль), и то как распределяется пространство внутри района (квартал - это модуль), и то как распределены жилые и нежилые постройки внутри квартала (здание - это модуль), и то что внутри этих построек.
У меня в студенчестве общага была модульного типа, например. Там модулем назывался блок из 8 комнат, расположенных вокруг общих кухни и туалета.
Но вообще всё что угодно можно декомпозировать и говорить про "модульность" в этом контексте.
К чему это всё? Во-первых, слово очень общее и соответственно многозначное. Во-вторых (что нам интереснее) даже в рамках одного контекста, модульность можно воспринимать на разных уровнях абстракции (район, квартал, здание, часть здания).
Меня немного расстраивает, когда на iOS-собеседовании я прошу человека рассказать о модульности и он сразу начинает рассказывать про фреймворки (это самый частый случай)...
или про то, как он делит своё приложение на слои по Дядюшке Бобу... или про то как он аккуратно группирует файлики по папкам model, view, controller в своём проекте.
Конечно, это всё про модульность.. Но мне сразу начинает казаться, что человек не видит этих разных уровней абстракции.
Будучи на месте соискателя, если речь заходит о модулях, я сам либо разворачиваю эту свою телегу "ах сколько разных красок в этом мире есть!" либо сразу спрашиваю, "а в каком контексте сей термин вас собственно интересует?"
По мне, модульность - это такая базовая штука в нашей области, что знание и понимание её полезнее всего СОЛИДа вместе взятого.
Для чего вообще оно?
На мой взгляд, главное в модульности - это декомпозиция. Декомпозиция, или разделение целого на части, - это один из основных инструментов сдерживания усложнения системы.
А деление на части - это ничто иное как выделение и формирование модулей.
С чем бы вы не работали, когда система растёт и усложняется, деление её на модули и работа с этими модулями по-отдельности - это главное что вам нужно делать, чтоб ваша голова не разлетелась в клочья.
В единицу времени в голове может хранится весьма ограниченный контекст. Да, все мы разные, да, этот размер можно прокачать и постепенно добавлять по одному мячику во время наших занятий по жонглированию.. Но предел есть у всех.
Когда модуль становится слишком жирным и уже и он не умещается без проблем в голове при работе, мы делим его на ещё меньшие модули и начинаем работать с ними по отдельности.
Это как раз та проблема, которую можно и нужно решать введением очередного уровня абстракции.
Тут как раз "Разделяй и властвуй" во всей красе. Небольшими изолированными компонентами управлять (и прогнозировать) гораздо проще, чем одной большой спагетти-системой где всё неявно взаимосвязано между собой.
Актуально как для софтварной разработки, так и для управления командами, для оценки сроков проекта и т.д.
Другая сторона модульности - это масштабируемость. Когда у нас уже есть оформленные функциональные модули мы можем объединять их в системы.
Модули - это наши строительные блоки из которых мы собираем что-то бОльшее.
В случае разработки приложения, если у нас уже есть готовые модули (базовые типы и структуры данных, сетевой слой, модуль авторизации, дизайн-система, ...), мы относительно быстро можем собрать из них новое приложение.
Насколько я понимаю, на галерах, там где производство новых приложение поставлено на поток часто начинают именно с уже готовых блоков.
Переиспользуемость - это тоже сюда же.
У вас может быть общий домен (модели), общая дизайн-система (UI), общая логика обработки ошибок (сетевой слой), всё что угодно в уже имеющихся приложениях. И если какая-то логика шарится между приложениями удобнее иметь её в отдельном модуле.
В общем по моему скромному мнению, после какого-то порога сложности любому проекту нужна модульность.
И тут встаёт вопрос о конкретной реализации.
Можно просто разбить код по папочкам в проекте.
Следующий вариант - создать отдельные таргеты и распределить код по ним. Тут у нас появляются уже отдельные фрэймворки и библиотеки для модулей.
Сепарируя код ещё дальше, мы создаём отдельные проекты (возможно даже в отдельных репозиториях) и подключаем их зависимостями к основному.
Естественно каждый подход имеет плюсы и минусы.
Ко всем уже принятым мерам Нидерладны вводят комендантский час с завтрашнего дня и до 10 февраля, после 9 вечера на улицу ни-ни. Сегодня последний шанс попить пива с друзьями (у кого-то в гостях... бары то уже 2 месяца как закрыты).
Хороший, годный тред в @mobileunderhood. Где-то на уровне плоской Земли. Или даже выше =3 twitter.com/mobileunderhoo…
То ли похвалил, то ли сказал, что антинаучную ересь несу... ;-) twitter.com/LeontyevGeorgi…
Так, от общего к частному. Расскажу, про модульность в ING.
У нас уже несколько лет как основной функционал вынесен в отдельные модули. Новые фичи (если они достаточно изолированы, имеют свой бэкэнд сервис и сложнее пары экранов) обычно тоже начинаются в отдельных модулях.
Каждый модуль живёт в отдельном репозитории. У него отдельное покрытие тестами, отдельные пайплайны на CI.
Модули релизятся под семантическим версионированием. В качестве менеджера зависимостей используем Carthage (слегка допиленный)
Модули разные: это и фиче-модули, и интеграция сторонних сервисов, и кор-компоненты (дизайн-система, основные структуры данных)
Какие есть плюсы помимо декомпозиции и шаринга функционала между разными приложениями?
Большому количеству людей удобнее работать в нескольких маленьких проектах нежели в одном большом. Меньше пересекающегося функционала, меньше конфликтов.
Модулями просто делить функционал между командами: одна команда работает над одним модулем, другая - над другим.
У каждого фиче-модуля есть своё приложение-витрина (showcase app), где во-первых представлен весь функционал модуля, во-вторых показано, как этот функционал правильно интегрировать в host app
В-третьих, это даёт возможность вообще не выходить за пределы модуля при разработке (или изменении) фичи. Showcase app маленький, лёгкий, собирается быстро, фичи сразу же на виду.
В основном приложении надо ещё до них дощёлкать, или временно поменять какую-то логику, чтоб отобразить экран, который в обычной жизни только при каких-то хитрых условиях вылезает. А тут всё в один-два клика.
Весь цикл разработки заметно ускоряется по сравнению с большим монолитом: изменение в коде, компиляция, отладка, прогонка тестов.
В общем случае модули в основном приложении уже скомпилированные, так что не приходится пересобирать весь код при каждом чихе (с этим, конечно, не всегда всё гладко... про сложность инвалидации кэша все знают)
Как я уже говорил, модуль - это ограниченный контекст. Когда ты работаешь в модуле, тебя вообще не интересуют все остальные части приложения.
Это же очень помогает при онбордниге нового разработчика. Очень здорово иметь ограниченный контекст когда только начинаешь знакомится с проектом.
Если модуль имеет дело с сетью, то запросы-ответы лежат в модуле в виде моков. Это и разработку упрощает, и для end-to-end UI тестов удобно. Обычно к реальному бэку ты и не подключишься из модуля.
Другое важное преимущество - это независимая разработка фич. Нет нужды прикрываться фиче-флагами или интеграционными бранчами в процессе разработки.
Работаешь, тестируешь у себя в модуле, а как-готово - мерджишь, релизишь и интегрируешь (если нет изменений в интерфейсе модуля, то интеграция - это просто инкремент версии модуля в проекте).
Думаю каждый, кто работал над какими-то большими фичами, в больших проектах, оценит подобный бонус. Особенно если фича не изолированная и в этих же классах работает кто-то другой параллельно. Синхронизация изменений в таком случае - это боль.
У нас постоянно какие-то проблемы с тестовым бэком для основного приложения. Из-за многослойности, которую я уже упоминал, постоянно где-то что-то ломается и долго чинится. Если слетела авторизация на бэке, то в приложение не попадёшь.
Закоммитить пару строчек чтоб проскочить авторизацию тоже не получится - без живой сетевой сессии запросы не будут ходить.
Те, кто работает над основным приложением, в такие моменты страдают. Кто работает в модуле - радуется и ловит лучи зависти от коллег.
Теперь о минусах нашего подхода
Долгий переход от "фича сделана" до "фича вмёрджена в приложение". Сначала делается изменение в модуле, потом релизится новая версия модуля (и не после каждой фичи), потом эта версия интегрируется в приложение.
Учитываем, что и у приложения и у модуля - отдельные CI-пайплайны. Т.е. на каждый пулл-реквест (а их мимимум 3 получается) прогоняется свой пайплайн с билдом, тестами, статическим анализом и прочей лабудой.
Пайплайн в модуле занимает 10-30 минут (в зависимости от модуля), в основном приложении - 1-2 часа. Так что даже на однострочный хот-фикс в модуле может уйти полдня.
Такое бывает не часто, и в общем к такому процессу привыкаешь. Ппривыкаешь, что хот-фиксы успевают подостыть в пути.
Разруливание зависимостей периодически подкидывает какой-то головняк. То кто-то напортачил с версионностью, то carthage ведёт себя не по-человечески.
Отдельный маленький ад во всей этой системе проапдейтить все модули на новый свифт или поднять minimum deployment target. Приходится обновлять все модули, причём довольно быстро, причём в строгом порядке (либо от кор-модулей к приложению, либо наоборот).
Итак-то процесс неприятный, а если кто-то напортачит, то ещё хуже. Как раз сейчас такая ситуация. Кое-кто поднял минимальную iOS версию в одном из базовых модулей (т.е. надо обновляться всем модулям), и при этом зарелизил это минорным апдейтом.
Из-за минорного апдейта картаж теперь везде подтягивает эту версию (так как формально это совместимое изменение) и приходится вручную править версии модулей. Иначе проект не скомпилируется.
А главное, что какие-то фиче-модули вполне себе совместимы с этой версией кор-модуля, и они уже в своих новых релизах ссылаются но неё. Так что приходится и их версии менять вручную.
И эти новые релизы фиче-модулей не могут быть интегрированы в приложение, пока все модули не поднимут минимальную версию.
В общем бардак, требующий много координированных усилий. Благо такое тоже нечасто.
Про инвалидацию кэша я уже упоминал. Модули кэшируются в бинарном виде, причём есть несколько уровней кэша: 2 уровня в картаже плюс derived data, иногда что-то кэшируется ещё и на девайсе (ресурсы например).
Периодически из-за переключений с ветки на ветку или при апдейте модуля с версии на версию подтягивается какой-то невалидный кэш.
Иногда ты узнаёшь об этом на этапе компиляции, иногда в рантайме. Тогда идёшь и начинаешь чистить кэш с самого безболезненного уровня (derived data) до самого глубокого.
В самом худшем случае нужно почистить всё.. причём для всех проектов (иногда неверная зависимость может подтянуться из соседнего проекта, потому что картаж их шарит, чтоб не дублировать). А собрать проект после полной очистки занимает примерно полчаса.
В минусах (а точнее недоработках) ещё то, что не можем никак допилить картаж и настроить гит так, чтоб можно было при желании править код модуля прямо в основном проекте.
Дебажить-то в проекте приложения не проблема (исходники модулей там есть), но вот изменения не сохранятся. Так что нужно править в отдельном проекте модуля и подтягивать в хост-приложение оттуда.
Это болезненно, когда нужно менять что-то в коде интеграции модуля, когда изменения делаешь в модуле, а дебажить нужно в хосте.
Ну кэш в такой ситуации тоже может сыграть злую шутку, потому что он в основном на версию модуля сориентирован, так что твои незарелизенные изменения могут не подтянуться или не отобразиться (надо немного с бубном попрыгать, чтоб отогнать бесов)
Суббота
Поговорим сегодня про протоколы и экстеншны в свифте.
Не помню уже были ли протоколы в первой версии языка или нет, но в 2015г. с выходом Swift 2 на WWDC состоялась это знаменательная презентация: Protocol-Oriented Programming in Swift developer.apple.com/videos/play/ww…
Именно там Dave Abrahams назвал свифт протоколо-ориентированным языком программирования.
В кратце, что же именно сказал тогда Дэйв: структуры (и другие вэлью-типы) это здорово; классы - это тоже здорово ("classes are awesome"), но у них свои недостатки.
Один из них это злоупотребление наследованием и вообще использование подкласса вместо суперкласса (привет Барбара Лисков).
Затем Дэйв рассказывает какие же преимущества имеет композиция с использованием протоколов по сравнению с наследованием. И в конце говорит про экстеншны и то, как они ещё больше расширяют возможности для композиции.
В середине презентации (на 15-й минуте) Дэйв вбрасывает "We have a saying in Swift: 'Don't start with the class, start with the protocol'"... И после этого тысячи разработчиков начинают считать, что их программы на свифте должны быть построены исключительно вокруг протоколов.
Тут как в религии: общие фразы порождают различные трактования, и вот разные люди начинают видеть разное в понятии "протоколо-ориентированное программирование".
Условно можно выделить два основных течения этой протокольной религии.
Абсолютизм. Абсолютно каждый дата-тип нужно прикрывать протоколом сразу на этапе проектирования. Мы получаем минимальную связность и максимальную тестируемость. Минусом конечно идёт удвоение кол-ва типов в проекте.
Так же мы начинаем наблюдать premature generalisation (преждевременное обобщение), впихивание лишних абстракций там где это не нужно.
Я повидал немало протоколов, у которых есть только один тип данных, который этот протокол имплементирует.
В результате ухудшает читаемость кода и повышается когнитивная нагрузка при работе с ним. Каждый раз между одной структурой данных и зависимой от неё другой структурой стоит протокол. Так что в голове приходится держать больше сущностей и по коду передвигаться сложнее.
Композитизм. Адепты этого течения яро топят за отказ от наследования и использование композиции через протоколы и экстеншны везде где можно. (В абсолютизме на экстеншнах особо внимание не концентрируется, но тут они чуть ли не во главе религии).
Это более умеренное и обдуманное течение. Например уважаемый мной Paul Hudson придерживается такой позиции hackingwithswift.com/sixty/9/5/prot…
Собственно композитизм - это как раз то, что Дэйв и имел изначально ввиду. В апреле 2020 в подкасте у Санделла (swiftbysundell.com/podcast/71) он так и сказал, что многие не правильно трактовали ту его презентацию.
Под "Don't start with the class, start with the protocol" он имел ввиду "when you need polymorphism, start with the protocol". Т.е. используй протоколы везде, где тебе нужны разные имплементации одного интерфейса, но не более того.
В том же разговоре с Сенделлом Дэйв говорит, что с "протоколо-ориентированным" он вообще-то погорячился...
Правильнее бы называть свифт "generic-oriented programming language", а протоколы - это лишь один из способов использовать эту "генерализацию" (слово "обобщение" тут кажется не подходит").
Разработчики свифта пытались разработать стоящую альтернативу наследованию, при этом не хотели убирать наследование из языка, как это сделано например в Го... (а есть, кстати, ещё какие-то языки без наследования?).
Главная функция протоколов - это предоставление интерфейса, что используется прежде всего для переиспользования кода и композиции, но так же очень удобно при тестировании (композиция vs наследование для создания моков - это отдельная тема).
Протокол - это что-то что ты "открываешь" в коде, а не изобретаешь сам заранее. При создании протокола идти нужно от частного к общему, а не наоборот. Ты видишь общий интерфейс у разных типов данных и тогда выделяешь его в протокол.
И всё бы было хорошо, если бы только интерфейсами протоколы и оставили... Но нет. Разработчики свифта решили поднакидать туда ещё разных фич.
Прежде всего изначально помимо динамического полиморфизма (подмена интерфейса имплементацией в рантайме) в свифте протоколы используются и так ограничения для компилятора (compile-time constraints).
И вот тут сразу начинается каша, потому что часто сложно уловить эту разницу, а на деле её понимание просто необходимо.
Но вот появляются ассоциативные типы в протоколе. Такой протокол тоже используется прежде всего как ограничение компилятора. Но теперь он не может быть одновременно использован и для динамического полиморфизма (без ассоциативных типов мог).
И вот из-за, казалось бы, небольшого изменения в коде уже вылезают странные ошибки компилятора типа "Protocol ‘YourProtocol’ can only be used as a generic constraint because it has Self or associated type requirements"
Но и тут разработчики языка не остановились. А давайте мы ещё сделаем кодогенерацию на основе протоколов! И вот в языке появляются Encodable, Decodable, Equatable - протоколы, которые нужны для динамического полиморфизма, но компилятор ещё и генерирует дефолтную имплементацию.
Здорово же!
Но вот к протоколам добавляют ещё и экстеншны. Фича без сомнений очень мощная и дающая огромные возможности (при этом имеющая несколько подводных камней). Но тут меня волнует, что она добавила ещё несколько новых юзкейсов к протоколам.
Прежде всего у нас появилась возможность поставлять дефолтную имплементацию к методам протокола. И вот перед нами уже не протоколы а самые настоящие mixins (даже и не знаю, как по-русски назвать).
И вот на собеседованиях уже говорят что это композиция+ (next generation), когда вообще ничего не надо делать для добавления нового функционала к имеющемуся типу кроме добавления имени протокола в определение этого типа данных.
А функционал сам подтянется через дефолтную реализацию в экстеншне.
В результате протокол как языковая фича превращается в монстра - мощная, многофункциональная языковая конструкция, наверное действительно главная фича свифта (THE feature), которая становится слишком тяжёлой и сложной в использовании.
Причём эта сложность не видима, пока не присмотришься. Использовать протоколы действительно просто и приятно. Но проблемы начинаются после.
Главная проблема - это ухудшение читаемости и понимания кода. Когда ты видишь протокол ты не можешь с первого взгляда разобрать что это: динамический интерфейс или ограничение компилятора... а может где-то ещё припрятаны какие-то экстеншны с дополнительным функционалом.
Хуже всего, когда это и то и другое и третье в одном флаконе. Ты видишь одно значение, начинаешь использовать протокол согласно ему, но потом выясняется, что не всё так просто.
И у тебя либо вылезут ошибки компиляции либо начнётся лажа в рантайме (например что-то может пойти не так если ты поправил сигнатуру функции либо в интерфейсе либо в дефолтной имплементации, но не в обоих местах сразу... тут компилятор не сможет выловить все проблемы)
Мне кажется, протокол, каков он сейчас в свифте нарушает принцип единой ответственности (SRP), слишком много на себя берёт разных языковых фич. И как и в случае нарушения этого принципа в коде, это черевато сайд-эффектами, которые я упомянул выше.
Единственный способ не наступать на эти заложенные в протоколах мины - это не мешать разные юзкейсы, и использовать каждый конкретный протокол только в одной роли.
Но это чёрт возьми очень сложно. Я и в своём-то коде не помню что к чему через пару месяцев, а уж про чтение чужого и говорить не стоит. Приходится каждый раз проверять, что это за протокол и как он вообще используется (а в большом проекте это могут быть сотни случаев).
Заплакал https://t.co/elwLzPweez
Мне кажется если у нас разработчиков есть возможность напортачить, кто-нибудь ей обязательно воспользуется (по не опытности, по запаре, по невнимательности). twitter.com/alexlit_double…
И я тут не о том, что какие-то фичи лишние, а какие-то - нет. А про то, что было бы гораздо удобнее, если бы эти фичи лучше были разделены в языке. Так было бы проще и читать и понимать.
И если в обычном языке или искусстве образность может быть на руку (не важно что я имел в виду, главное - что подумал и увидел тут ты), то в программировании едва ли этому есть применение.
Как мы уже говорили о "протоколо-ориентированном программировании", многозначность порождает различные трактовки. А это в свою очередь может завести мысль не туда, это мешает пониманию.
Не так давно я писал об этом в бложике (там больше текста об этом всём), если интересно: dmtopolog.com/do-protocols-b… (там несколько разных постов)
@mobileunderhood Протоколы, к тому же, одна из самых дорогих фич языка с точки зрения binary size и возможно performance. Особенно со структурами, тк компилятор создаёт VWT чтобы потом в рантайме ее копировать, удалять, etc. Мы, кстати, в FB работаем с Apple над оптимизацией этого кейса 🙂
динамика в рантайме вообще дорогая, медленная и плохо оптимизируемая компилятором... но без неё было бы совсем грустно ;-) twitter.com/maksim_ovtsin/…
@mobileunderhood Протоколы, к тому же, одна из самых дорогих фич языка с точки зрения binary size и возможно performance. Особенно со структурами, тк компилятор создаёт VWT чтобы потом в рантайме ее копировать, удалять, etc. Мы, кстати, в FB работаем с Apple над оптимизацией этого кейса 🙂
Про VWT (value witness table) и прочую подкапотщину протоколов и дженериков в свифте есть замечательная презентация от разработчиков свифта: youtube.com/watch?v=ctS8Fz… twitter.com/maksim_ovtsin/…
@mobileunderhood Но ведь interface oriented programming является очень известной концепцией реализованной например COM более 25 лет назад. А в чем разница между протоколом и интерфейсом?
прежде всего в маркетинге ;-) Но вообще, разница в том, что протокол стал сильно больше чем просто интерфейс (каковым, например, был протокол в ObjC) twitter.com/borisrozinov/s…
Воскресенье
Как-то так моя неделя тут и заканчивается. Спасибо всем, кто участвовал в обсуждениях. На сегодня у меня темы нет но до конца дня могу поотвечать на вопросы, если есть. А так пишите в личку: @dmtopolog. Всем добра!
