Comments 59
Стол завален бумажками, где записаны все мои мысли и планы.
…а ещё стоит баночка Optimum Nutrition Creatine Powder и коробка от дрона Eachine E013 Small Pepper :)
Или же это просто чей-то стол с достаточным количеством бумажек сфотографировали?
Стол мой, бумажки мои, квадрокоптер коллеги, креатин мой, про него на интревью подзабыл.
А вот ещё любопытно: текст статьи — он ваш или же интервьюера?
Хотя одну книгу, пожалуй, упомяну — это «Обломов» Гончарова.
Как говорила наша учительница литературы: «бальзам на душу!», что программа 9 (10?) класса на кого-то произвела впечатление :)
Текст 100% записан интервьюером с моих слов, со всеми ляпами :)

что программа 9 (10?) класса на кого-то произвела впечатление
Впечатление произвело, но 9-10 класс рановат для Гончарова, Некрасова, Достоевского и т.д., в зрелом возрасте совсем по-другому воспринимаются, надо бы перечитать.
Просто в «Гугле» набиваешь и смотришь, что он тебе ответит.

Ответил человек из Яндекса)) Интересно, они с техническими вопросами все в Гугл ходят?

А Яндекс для этих целей куда хуже, причем это более заметно если ищешь англоязычные/редкие статьи

Тогда сотрудник Яндекса должен был бы внести полезные ресурсы, которые он нашел Гуглом и не нашел Яндексом, в особый список Яндекса на полную и частую индексацию. И более к Гуглу не обращаться ))

заголовок жесточайший кликбайт. по существу, если пишешь на swift, то это далеко не боль всех.
это боль всех на свете… потому и появляются люди пишущие слово кликбайт
Пожалуйста, давайте дополним картину, напишите свою боль.
Я сказал первое что пришло в голову при вопросе «что хотелось бы исправить?». Xcode объективно уступает другим IDE, особенно при работе со Swift. Я же еще забыл упомянуть про отсутствие нормального авторефакторинга и callers/callees/subclasses/superclasses/protocols и т.д., потому что уже и забыл что это такое.
> callers/callees/subclasses/superclasses/protocols
Да вроде давно уже работают

PS. С тем что XCode — это боль, всецело согласен.
>Да вроде давно уже работают
В картах не всё показывает часто, не осиливает :( На проектах поменьше работает ок, это да.
Ещё хотелось бы уточнить:
Даже наша работа зависит от того, что Xcode долго компилирует. […] Если бы он это нормально делал, не пришлось бы разбивать приложение на модули — нам пришлось проинвестировать в это.
Инвестиции заключались в покупке более мощного мака? Или в переходе на модульность?
В переходе на модульность. Поясню использование здесь термина «проинвестировать»

Я как-то раз для себя понял, что любой рефакторинг, переход на новую архитектуру, улучшение CI — это инвестиции, ровно как в бизнесе. Есть ресурсы — время разработчиков, есть понимание что хочешь получить, есть риски не получить что хотелось или отстать по другим задачам. И вот ты сидишь и думаешь стоит ли инвестировать или нет.

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

Xcode — компилирует, ага. В этом месте технически грамотному читателю стоит насторожиться.

Нормальное предложение. У нас в комманде часто говорят похожим образом, а ещё, иногда, мы .net называем c# и наооборот. Такие фразы здорово экономят время. Можно же и комп называть — электронная вычислительная машина.
зачем вообще начинали его использовать с учетом того что проект не маленький?
Не знаю как Яндекс выбирал, но в случае нашего проекта Swift значительно увеличил скорость разработки (несмотря на «слабый» компилятор) за счет компактности и читабельности кода. Плюс рано или поздно придется переходить с Objective-C на Swift.
По моим личным ощущениям написание и чтение Swift кода требует значительно меньше ментальной нагрузки, чем Objective-C (6 лет опыта Objective-C, 3 года опыта Swift).
Да, мы начали писать на Swift в первую очередь потому что это современный мощный язык, и потому что устали уже от неограниченной рефлексии, нестрогой типизации, бесконечных квадратных скобочек, указателей и прочих особенностей Obj-C. Хотелось чего-то нового.

К тому мы начинали на Swift 1.1 и еще не было известно про некоторые проблемы, которые вскрылись только когда мы перешли рубеж 100к строк. Отступать было поздно.

И еще могу сказать как человек, активно вовлеченный в процесс найма, что найти людей с опытом 2-3 года, а тем более новичков, которые хотели бы посвятить будущее Objective-C очень непросто. Не модный он уже. И то, что мы в свое время написали карты на Swift сейчас реально помогает в найме.

2-3 года не новички, и таких мы вполне нормально нанимаем. Новичков я упомянул для дополнения картины — что люди, приходящие в iOS, сейчас не учат Objc.
Джун из соседнего отдела около года на 1с проработал, через 2 недели устраивается на iOS как раз на Objc))
Было бы странно, чтобы не нашлось контрпримеров моим словам, в жизни ведь всякое бывает. Но джуну могу посочувствовать — какова вероятность, что через N лет, когда он будет менять работу, ему не придется переучиваться на Swift или жестко ограничиваться в выборе проектами на objc?
Лично я вообще придерживаюсь мнения что при достаточном опыте язык сменить достаточно просто, пусть с потерями какими то. Понятно что сеньером не стать с ходу, но все же.
К тому мы начинали на Swift 1.1 и еще не было известно про некоторые проблемы, которые вскрылись только когда мы перешли рубеж 100к строк. Отступать было поздно.

а неужели не было понятно что это будет авантюрой?) с учетом того что у эпл — все сырое — то что у других назовут раннеей преальфой у них идет как финальная версия
Да какая же это авантюра? Отличный язык. Да, тулинг подводит, но становится лучше с каждым годом. И я лучше подожду лишнюю минуту компиляцию, зато с generic-ами, enum-ами с ассоциированными значениями, строгой типизацией и БЕЗ ТОЧЕК С ЗАПЯТЫМИ И СКОБОЧЕК!!!
а угробленные тысячи человекочасов для миграций между версиями 1.1-1.2-2.0-2.2-3.0 это наверное не авантюра?

все выше перечисленное вам доступно и в C++ ;)
а угробленные тысячи человекочасов для миграций между версиями 1.1-1.2-2.0-2.2-3.0 это наверное не авантюра?

Да, была одна жесткая миграция, когда один человек из команды сидел 2 недели правил ошибки за мигратором, но в остальные разы мигратор отработал намного лучше. Проект тогда был 250к строк, ушло считайте сотня часов, никак не тысячи. Откуда такие цифры?
Как это без скобочек? В if скобочки обязательны. В guard тоже.
guard let win = self.view.window else { return }

Я про квадратные.

Some *some = [[Some alloc] initWith: other];
Third *third = [[[some foo] bar] map:^{...}];


Вместо
let some = Some(with: other)
let third = some.foo().bar().map {...}
Вместо того, чтобы стол бумажками захламлять, заведите себе тетрадку в твердой обложке.
заведите себе тетрадку в твердой обложке.
…чтобы вырывать из оной листочки? :)

Есть подозрение, что не всем удобна линейная структура тетради. Многим важна возможность группировать записи по определённым критериям.

image

Сомнительно — все равно будет лежать в одной стопке, перемешиваться, да еще и теряться. А в тетрадке можно найди события и прошлогодней давности, при необходимости.
С вашей точки зрения это хлам, с моей — мои мысли, которые я структурировал абсолютно так, как мне удобно.
Соглашусь про боль iOS (swift) разработчика. Если у них все 400k loc на Swift, то я могу только представить как долго весь проект компилируется.
От себя могу добавить еще несколько причин боли:
1. Постоянные проблемы с подключением iPhone / iPad к Xcode, особенно после того как «Debug over the air» был реализован в последнем Xcode.
2. Xcode компилирует проект с нуля если поменять «target» с телефона на симулятор или наоборот. На нашем проекте занимает около 5 минут (~100k loc на Swift).
3. Постоянные проблемы с подсветкой кода и «autocompletion». Часто работает с задержкой, иногда требуется перезагрузка Xcode.

Самое неприятное, что при работе с Xcode чувствуешь, что ты соображаешь быстрее, чем он, постоянно приходится ждать, недолго, но все равно чувствуется.
Пробовал перейти на AppCode, в каких-то моментах он быстрее и удобнее, в других на порядок медленнее, видимо за счет того, что написан не-нативно.
В AppCode вообще нету сторибордов.
В XCode чудовищная работа с окнами/табами. Очень бесит тот факт, что Assistant Editor может открыться совсем не на том view, а при переходе с Assistant Editor на Standard или Version Editor всегда остаётся сториборд.
— Самое эффективное — это когда у тебя есть конкретная проблема и ты ищешь решение.

Вот тут и не поспоришь, действительно самое эффективнее, и чем глобальнее проблема, тем обширнее поиск решения, вплоть до конференций и семинаров.
стоит монитор Thunderbolt и лежит ноут
Не понимаю как можно работать на ноуте и требовать скорости. Мобильные процессоры никогда не приблизятся к настольным, особенно таким как i7-8700k и новым i9.
18, если быть точным.
Но так слишком просто. Давайте разгоним 8700k до 4.8 (5.0 со скальпированием) и прогоним любой тест на пару часов.
Попробую предсказать результат: ноут перегреется и 8850H начнет троттлить, теряя до 50% мощности. По итогу разница будет 200%.

Ну не изобрели еще ноут который бы смог хотя бы сравняться с десктопом. Они не предназначены для этого.

Странно, я никогда не считал основной задачей десктопа (и рвущегося за ним следом ноута) быть оскальпированным и разогнанным. Что я делаю не так? Где научиться правильному восприятию целей существования вычислительной техники, чтобы сравнивать правильно?


А ноут у меня тупит, да. Но там Пентиум, ему можно.

Главное что вас устраивает. У любителей чтобы все летало свои заморочки.
Как-то много противоречий в этом человеке. С одной стороны он говорит что рад трудиться за идею. С другой — он никогда не фанател ни от научпопа, ни от изучения средств программирования.

В яндекс он пришёл с чистой трудовой книжкой, если я правильно понял из прочитанного. Что удивительно.

В общем и целом — самый середнячковый программист.
Портрет безликого.

Весьма познавательная статья.
а они сейчас все такие — кто пришел в индустрию ради денег а не потому что в руках зудит код пописать
Да, жаль нельзя собрать референдум о понижении зарплат программистам хотя бы в два раза. Я б проголосовал.
Зарплата определяется рынком. И сейчас конъюктура такая, что разработчиков, особенно опытных, не хватает. Мы можете ограничить референдумом максимальную зп, но тогда компании, в борьбе за кандидатов, просто будут какими-то другими плюшками завлекать.

И даже больше. Чтобы действительно снизилась зп, нужно чтобы во всем мире был переизбыток кадров. Снизите только в России — народ просто заведет тракторы и придется обратно повышать.
Да понятно, я пошутил )
А вот то что опытных разработчико не хватает — тут я не согласен.
Есть такая поговорка:
«С опытными работниками и тупой менеджер проект построит. Хороший же менеджер построит проект и с тупыми работниками».
Сложность проектов растёт из-за вечной «доделки» и напихивания костылей.

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

Сюда же можно отнести и течку каждов. Каждый новый кадр стремиться вставить своё решение, свою любимую библиотеку в проект, от чего деплой проекта (поддержка, развёртываемость, сложность) становиться все больше и толще. Это тоже влияет на всё возрастающую сложность.
Аудит, ревью всего хода работы отдела проводиться только тогда, когда полный капец и вызывают кризис менеджеров. Если бы аудит работы сотрудников (технический) проводили хотя бы раз в пол года, планово, не дожидаясь кризиса, то сложность работ была бы значительно ниже.

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

Конечно, согласен, т.к. сам за все это отвечаю.

«С опытными работниками и тупой менеджер проект построит. Хороший же менеджер построит проект и с тупыми работниками».

Под неопытным разработчиком я понимаю не тупого :) Просто некоторые знания, связанные с работой в большом проекте, появляются только с опытом. К ним относятся проблемы и из вашего сообщения. Грубо говоря, опытному разработчику не нужно объяснять важность кодревью или необходимость использования общих компонентов, нравятся они тебе или нет.

И вот людей с опытом работы в большом проекте с выстроенными процессами реально не хватает и они ценятся.
Предположим есть работник, который ну очень круто пишет на GLSL и разбирается в математике, но ему крайне трудно сделать коммит в отдельный бранч, смёржить или подмёржить себе изменения из другой ветки, или например дебажные/девелоперские фичи в коде для релоада шейдеров налету без перезапуска проекта — найти в коде, воспользоваться или сделать их самому для этого человека нереально сложно. Как такого можно классифицировать? Это опытный или как?
Можно классифицировать как опытного, но с опытом ограниченным. На должность старшего разработчика/тимлида претендовать не может. И если как есть бросить его в команду на сложный проект — и ему придется туго, и команде, и руководителю. Конечно, на каких-то проектах/должностях он будет востребован, но там скорее всего и зп другая будет.
жаль что так как ты мыслят далеко не все менеджеры. но я рад что хоть где-то есть порядок.
может быть в яндексе не всё так плохо как говорят.
было приятно пообщаться.
Хм…
Это странно.
Да, он сейчас не может сделать коммит в отдельный бранч, смёржить и подмёржить — потому, что он всю жизнь использовал ClearCase условно 1 (с бранчами и конфигспеком), ClearCase условно 2 (с забыл как называется c объединёнными изменениями), потом SVN, потом Perforce.

И это малолетние менеджеры называют «с ограниченным опытом»? Просто потому, что человек не знает git?

А я считаю, что в компании недостаточно развит процесс обучения /ввседения в команду новых сотрудников.
И такие идиоты как космонавт правят миром =(
Иногда от этого становится чуточку обидно…
В трудовой у меня был AnyVoid, так что вы неправильно поняли.

Это факт вашего сообщения, который я поправлю. Остальное — ваше собственное мнение, вы на него имеете право и спорить я не буду. В одном интервью с фиксированными вопросами человека как личность не раскрыть.
Only those users with full accounts are able to leave comments. Log in, please.