Comments 59
Стол завален бумажками, где записаны все мои мысли и планы.…а ещё стоит баночка Optimum Nutrition Creatine Powder и коробка от дрона Eachine E013 Small Pepper :)
Или же это просто чей-то стол с достаточным количеством бумажек сфотографировали?
Стол мой, бумажки мои, квадрокоптер коллеги, креатин мой, про него на интревью подзабыл.
Просто в «Гугле» набиваешь и смотришь, что он тебе ответит.
Ответил человек из Яндекса)) Интересно, они с техническими вопросами все в Гугл ходят?
заголовок жесточайший кликбайт. по существу, если пишешь на swift, то это далеко не боль всех.
это боль всех на свете… потому и появляются люди пишущие слово кликбайт
Пожалуйста, давайте дополним картину, напишите свою боль.
Я сказал первое что пришло в голову при вопросе «что хотелось бы исправить?». Xcode объективно уступает другим IDE, особенно при работе со Swift. Я же еще забыл упомянуть про отсутствие нормального авторефакторинга и callers/callees/subclasses/superclasses/protocols и т.д., потому что уже и забыл что это такое.
Я сказал первое что пришло в голову при вопросе «что хотелось бы исправить?». Xcode объективно уступает другим IDE, особенно при работе со Swift. Я же еще забыл упомянуть про отсутствие нормального авторефакторинга и callers/callees/subclasses/superclasses/protocols и т.д., потому что уже и забыл что это такое.
Ещё хотелось бы уточнить:
Даже наша работа зависит от того, что Xcode долго компилирует. […] Если бы он это нормально делал, не пришлось бы разбивать приложение на модули — нам пришлось проинвестировать в это.Инвестиции заключались в покупке более мощного мака? Или в переходе на модульность?
В переходе на модульность. Поясню использование здесь термина «проинвестировать»
Я как-то раз для себя понял, что любой рефакторинг, переход на новую архитектуру, улучшение CI — это инвестиции, ровно как в бизнесе. Есть ресурсы — время разработчиков, есть понимание что хочешь получить, есть риски не получить что хотелось или отстать по другим задачам. И вот ты сидишь и думаешь стоит ли инвестировать или нет.
В данном случае мы инвестировали наше время в разбитие на модульность — и получили возможность быстро поднимать небольшие тестовые приложения для отдельных модулей и легко обмениваться кодом между тестовыми приложениями и основным. Тестовые приложение компилируются быстро, тем самым нивелировали проблемы долгой компиляции и тормозов Swift.
Я как-то раз для себя понял, что любой рефакторинг, переход на новую архитектуру, улучшение CI — это инвестиции, ровно как в бизнесе. Есть ресурсы — время разработчиков, есть понимание что хочешь получить, есть риски не получить что хотелось или отстать по другим задачам. И вот ты сидишь и думаешь стоит ли инвестировать или нет.
В данном случае мы инвестировали наше время в разбитие на модульность — и получили возможность быстро поднимать небольшие тестовые приложения для отдельных модулей и легко обмениваться кодом между тестовыми приложениями и основным. Тестовые приложение компилируются быстро, тем самым нивелировали проблемы долгой компиляции и тормозов Swift.
Xcode — компилирует, ага. В этом месте технически грамотному читателю стоит насторожиться.
Компилятор, компилирующий swift, называется «swift», я писал об этом в habr.com/company/yandex/blog/335768
Не думаю, что интервью стало бы интереснее от этой подробности.
Не думаю, что интервью стало бы интереснее от этой подробности.
Нормальное предложение. У нас в комманде часто говорят похожим образом, а ещё, иногда, мы .net называем c# и наооборот. Такие фразы здорово экономят время. Можно же и комп называть — электронная вычислительная машина.
зачем вообще начинали его использовать с учетом того что проект не маленький?
Не знаю как Яндекс выбирал, но в случае нашего проекта Swift значительно увеличил скорость разработки (несмотря на «слабый» компилятор) за счет компактности и читабельности кода. Плюс рано или поздно придется переходить с Objective-C на Swift.
По моим личным ощущениям написание и чтение Swift кода требует значительно меньше ментальной нагрузки, чем Objective-C (6 лет опыта Objective-C, 3 года опыта Swift).
По моим личным ощущениям написание и чтение Swift кода требует значительно меньше ментальной нагрузки, чем Objective-C (6 лет опыта Objective-C, 3 года опыта Swift).
Да, мы начали писать на Swift в первую очередь потому что это современный мощный язык, и потому что устали уже от неограниченной рефлексии, нестрогой типизации, бесконечных квадратных скобочек, указателей и прочих особенностей Obj-C. Хотелось чего-то нового.
К тому мы начинали на Swift 1.1 и еще не было известно про некоторые проблемы, которые вскрылись только когда мы перешли рубеж 100к строк. Отступать было поздно.
И еще могу сказать как человек, активно вовлеченный в процесс найма, что найти людей с опытом 2-3 года, а тем более новичков, которые хотели бы посвятить будущее Objective-C очень непросто. Не модный он уже. И то, что мы в свое время написали карты на Swift сейчас реально помогает в найме.
К тому мы начинали на Swift 1.1 и еще не было известно про некоторые проблемы, которые вскрылись только когда мы перешли рубеж 100к строк. Отступать было поздно.
И еще могу сказать как человек, активно вовлеченный в процесс найма, что найти людей с опытом 2-3 года, а тем более новичков, которые хотели бы посвятить будущее Objective-C очень непросто. Не модный он уже. И то, что мы в свое время написали карты на Swift сейчас реально помогает в найме.
найме новичков?
2-3 года не новички, и таких мы вполне нормально нанимаем. Новичков я упомянул для дополнения картины — что люди, приходящие в iOS, сейчас не учат Objc.
Джун из соседнего отдела около года на 1с проработал, через 2 недели устраивается на iOS как раз на Objc))
К тому мы начинали на Swift 1.1 и еще не было известно про некоторые проблемы, которые вскрылись только когда мы перешли рубеж 100к строк. Отступать было поздно.
а неужели не было понятно что это будет авантюрой?) с учетом того что у эпл — все сырое — то что у других назовут раннеей преальфой у них идет как финальная версия
Да какая же это авантюра? Отличный язык. Да, тулинг подводит, но становится лучше с каждым годом. И я лучше подожду лишнюю минуту компиляцию, зато с generic-ами, enum-ами с ассоциированными значениями, строгой типизацией и БЕЗ ТОЧЕК С ЗАПЯТЫМИ И СКОБОЧЕК!!!
а угробленные тысячи человекочасов для миграций между версиями 1.1-1.2-2.0-2.2-3.0 это наверное не авантюра?
все выше перечисленное вам доступно и в C++ ;)
все выше перечисленное вам доступно и в C++ ;)
Без точек с запятыми?
а угробленные тысячи человекочасов для миграций между версиями 1.1-1.2-2.0-2.2-3.0 это наверное не авантюра?
Да, была одна жесткая миграция, когда один человек из команды сидел 2 недели правил ошибки за мигратором, но в остальные разы мигратор отработал намного лучше. Проект тогда был 250к строк, ушло считайте сотня часов, никак не тысячи. Откуда такие цифры?
Как это без скобочек? В if скобочки обязательны. В guard тоже.
guard let win = self.view.window else { return }
Вместо того, чтобы стол бумажками захламлять, заведите себе тетрадку в твердой обложке.
заведите себе тетрадку в твердой обложке.…чтобы вырывать из оной листочки? :)
Есть подозрение, что не всем удобна линейная структура тетради. Многим важна возможность группировать записи по определённым критериям.
…
С вашей точки зрения это хлам, с моей — мои мысли, которые я структурировал абсолютно так, как мне удобно.
Соглашусь про боль 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, в каких-то моментах он быстрее и удобнее, в других на порядок медленнее, видимо за счет того, что написан не-нативно.
От себя могу добавить еще несколько причин боли:
1. Постоянные проблемы с подключением iPhone / iPad к Xcode, особенно после того как «Debug over the air» был реализован в последнем Xcode.
2. Xcode компилирует проект с нуля если поменять «target» с телефона на симулятор или наоборот. На нашем проекте занимает около 5 минут (~100k loc на Swift).
3. Постоянные проблемы с подсветкой кода и «autocompletion». Часто работает с задержкой, иногда требуется перезагрузка Xcode.
Самое неприятное, что при работе с Xcode чувствуешь, что ты соображаешь быстрее, чем он, постоянно приходится ждать, недолго, но все равно чувствуется.
Пробовал перейти на AppCode, в каких-то моментах он быстрее и удобнее, в других на порядок медленнее, видимо за счет того, что написан не-нативно.
UFO just landed and posted this here
стоит монитор Thunderbolt и лежит ноутНе понимаю как можно работать на ноуте и требовать скорости. Мобильные процессоры никогда не приблизятся к настольным, особенно таким как i7-8700k и новым i9.
Разница в скорости между i7-8700k и i7-8850h — менее двадцати процентов.
18, если быть точным.
Но так слишком просто. Давайте разгоним 8700k до 4.8 (5.0 со скальпированием) и прогоним любой тест на пару часов.
Попробую предсказать результат: ноут перегреется и 8850H начнет троттлить, теряя до 50% мощности. По итогу разница будет 200%.
Ну не изобрели еще ноут который бы смог хотя бы сравняться с десктопом. Они не предназначены для этого.
Но так слишком просто. Давайте разгоним 8700k до 4.8 (5.0 со скальпированием) и прогоним любой тест на пару часов.
Попробую предсказать результат: ноут перегреется и 8850H начнет троттлить, теряя до 50% мощности. По итогу разница будет 200%.
Ну не изобрели еще ноут который бы смог хотя бы сравняться с десктопом. Они не предназначены для этого.
Странно, я никогда не считал основной задачей десктопа (и рвущегося за ним следом ноута) быть оскальпированным и разогнанным. Что я делаю не так? Где научиться правильному восприятию целей существования вычислительной техники, чтобы сравнивать правильно?
А ноут у меня тупит, да. Но там Пентиум, ему можно.
Как-то много противоречий в этом человеке. С одной стороны он говорит что рад трудиться за идею. С другой — он никогда не фанател ни от научпопа, ни от изучения средств программирования.
В яндекс он пришёл с чистой трудовой книжкой, если я правильно понял из прочитанного. Что удивительно.
В общем и целом — самый середнячковый программист.
Портрет безликого.
Весьма познавательная статья.
В яндекс он пришёл с чистой трудовой книжкой, если я правильно понял из прочитанного. Что удивительно.
В общем и целом — самый середнячковый программист.
Портрет безликого.
Весьма познавательная статья.
а они сейчас все такие — кто пришел в индустрию ради денег а не потому что в руках зудит код пописать
Да, жаль нельзя собрать референдум о понижении зарплат программистам хотя бы в два раза. Я б проголосовал.
Зарплата определяется рынком. И сейчас конъюктура такая, что разработчиков, особенно опытных, не хватает. Мы можете ограничить референдумом максимальную зп, но тогда компании, в борьбе за кандидатов, просто будут какими-то другими плюшками завлекать.
И даже больше. Чтобы действительно снизилась зп, нужно чтобы во всем мире был переизбыток кадров. Снизите только в России — народ просто заведет тракторы и придется обратно повышать.
И даже больше. Чтобы действительно снизилась зп, нужно чтобы во всем мире был переизбыток кадров. Снизите только в России — народ просто заведет тракторы и придется обратно повышать.
Да понятно, я пошутил )
А вот то что опытных разработчико не хватает — тут я не согласен.
Есть такая поговорка:
«С опытными работниками и тупой менеджер проект построит. Хороший же менеджер построит проект и с тупыми работниками».
Сложность проектов растёт из-за вечной «доделки» и напихивания костылей.
Аудит, ревью всего хода работы отдела проводиться только тогда, когда полный капец и вызывают кризис менеджеров. Если бы аудит работы сотрудников (технический) проводили хотя бы раз в пол года, планово, не дожидаясь кризиса, то сложность работ была бы значительно ниже.
Сюда же можно отнести и течку каждов. Каждый новый кадр стремиться вставить своё решение, свою любимую библиотеку в проект, от чего деплой проекта (поддержка, развёртываемость, сложность) становиться все больше и толще. Это тоже влияет на всё возрастающую сложность.
А вот то что опытных разработчико не хватает — тут я не согласен.
Есть такая поговорка:
«С опытными работниками и тупой менеджер проект построит. Хороший же менеджер построит проект и с тупыми работниками».
Сложность проектов растёт из-за вечной «доделки» и напихивания костылей.
Аудит, ревью всего хода работы отдела проводиться только тогда, когда полный капец и вызывают кризис менеджеров. Если бы аудит работы сотрудников (технический) проводили хотя бы раз в пол года, планово, не дожидаясь кризиса, то сложность работ была бы значительно ниже.
Сюда же можно отнести и течку каждов. Каждый новый кадр стремиться вставить своё решение, свою любимую библиотеку в проект, от чего деплой проекта (поддержка, развёртываемость, сложность) становиться все больше и толще. Это тоже влияет на всё возрастающую сложность.
Аудит, ревью всего хода работы отдела проводиться только тогда, когда полный капец и вызывают кризис менеджеров. Если бы аудит работы сотрудников (технический) проводили хотя бы раз в пол года, планово, не дожидаясь кризиса, то сложность работ была бы значительно ниже.
Сюда же можно отнести и течку каждов. Каждый новый кадр стремиться вставить своё решение, свою любимую библиотеку в проект, от чего деплой проекта (поддержка, развёртываемость, сложность) становиться все больше и толще. Это тоже влияет на всё возрастающую сложность.
Конечно, согласен, т.к. сам за все это отвечаю.
«С опытными работниками и тупой менеджер проект построит. Хороший же менеджер построит проект и с тупыми работниками».
Под неопытным разработчиком я понимаю не тупого :) Просто некоторые знания, связанные с работой в большом проекте, появляются только с опытом. К ним относятся проблемы и из вашего сообщения. Грубо говоря, опытному разработчику не нужно объяснять важность кодревью или необходимость использования общих компонентов, нравятся они тебе или нет.
И вот людей с опытом работы в большом проекте с выстроенными процессами реально не хватает и они ценятся.
Предположим есть работник, который ну очень круто пишет на GLSL и разбирается в математике, но ему крайне трудно сделать коммит в отдельный бранч, смёржить или подмёржить себе изменения из другой ветки, или например дебажные/девелоперские фичи в коде для релоада шейдеров налету без перезапуска проекта — найти в коде, воспользоваться или сделать их самому для этого человека нереально сложно. Как такого можно классифицировать? Это опытный или как?
Можно классифицировать как опытного, но с опытом ограниченным. На должность старшего разработчика/тимлида претендовать не может. И если как есть бросить его в команду на сложный проект — и ему придется туго, и команде, и руководителю. Конечно, на каких-то проектах/должностях он будет востребован, но там скорее всего и зп другая будет.
жаль что так как ты мыслят далеко не все менеджеры. но я рад что хоть где-то есть порядок.
может быть в яндексе не всё так плохо как говорят.
было приятно пообщаться.
может быть в яндексе не всё так плохо как говорят.
было приятно пообщаться.
Хм…
Это странно.
Да, он сейчас не может сделать коммит в отдельный бранч, смёржить и подмёржить — потому, что он всю жизнь использовал ClearCase условно 1 (с бранчами и конфигспеком), ClearCase условно 2 (с забыл как называется c объединёнными изменениями), потом SVN, потом Perforce.
И это малолетние менеджеры называют «с ограниченным опытом»? Просто потому, что человек не знает git?
А я считаю, что в компании недостаточно развит процесс обучения /ввседения в команду новых сотрудников.
Это странно.
Да, он сейчас не может сделать коммит в отдельный бранч, смёржить и подмёржить — потому, что он всю жизнь использовал ClearCase условно 1 (с бранчами и конфигспеком), ClearCase условно 2 (с забыл как называется c объединёнными изменениями), потом SVN, потом Perforce.
И это малолетние менеджеры называют «с ограниченным опытом»? Просто потому, что человек не знает git?
А я считаю, что в компании недостаточно развит процесс обучения /ввседения в команду новых сотрудников.
По-вашему я в 9-м классе пришел в компьютерную секцию ради денег?
В трудовой у меня был AnyVoid, так что вы неправильно поняли.
Это факт вашего сообщения, который я поправлю. Остальное — ваше собственное мнение, вы на него имеете право и спорить я не буду. В одном интервью с фиксированными вопросами человека как личность не раскрыть.
Это факт вашего сообщения, который я поправлю. Остальное — ваше собственное мнение, вы на него имеете право и спорить я не буду. В одном интервью с фиксированными вопросами человека как личность не раскрыть.
Коля, ты молодец! :)
Sign up to leave a comment.
«Могу рассказать про общую боль всех iOS-разработчиков» — 10 вопросов программисту, выпуск 2