Я думаю, тут претензия к тому, что присутствуют лишние аллокации (т.е. создание новых массивов на каждом этапе) + итерирование с нуля (сначала filter, потом по отфильтрованным map)
т.о. аналогично такому коду:
const sliced = objects.slice(x, y)
const filtered = []
for (let i = 0; i < sliced.length; i++) {
if (...(sliced[i])) filtered.push(sliced[i])
}
const mapped = []
for (let i = 0; i < filtered.length; i++) {
mapped.push(...(filtered[i]))
}
Вместо:
const mapped = []
for (let i = x; i < y; i++) {
if (filterObject(objects[i])) mapped.push(mapObject(objects[i]))
}
Хочется сказать, что во-первых, скажите спасибо, что не так:
Ну, справедливости ради, реакт в 2024 уже мутировал до полной неузнаваемости :)
Как минимум, от него всё больше отпилили классы и прикрутили React.FC.
Хранение состояния внутри, изолированно - это как раз хорошо и правильно, это не проблема и решать ее не надо. И ни какие менеджеры глобального состояния в реальности не нужны, потому что глобальное состояние - это самое плохое, что бывает в программировании, от него надо избавляться всеми силами и любой ценой, а не "менеджить".
Ну, как бы, да, но нет.
С одной стороны, редукс — абсолютно безумная система, подразумевающая полностью глобальное состояние с одним центральным Root State. С другой стороны, моя главная претензия к редуксу — это не глобальное состояние, а бессмысленное и беспощадное MVC даже там, где это не нужно. Особенно когда он используется в комбинации с каким-нибудь RxJS, и в итоге вы пишете, по сути, клиент-серверную архитектуру, ещё до обращения к настоящему серверу.
Видел я вырожденный вариант этого подхода, когда локальный стейт вообще не использовался. Вспоминаю, как страшный сон. Была форма contact us, было что-то типа <textarea value={feedback} onChange={...} />, а вот любое изменение в этой форме проходило через экшн вида { type: 'FORM_CHANGE', id: 'contact-us', field: 'feedback', value: '...' }. В какой-то момент мне понадобилось в другой форме редактировать структуру из вложенных объектов с массивами, я психанул и удалил весь этот код. Поэтому, к сожалению, более конкретных примеров не будет.
А какой-нибудь контекст, хранящий в себе вебсокет и функции для манипуляций с ним — богоугодное дело. Главное, чтобы без лишних ререндеров. `useConstCallback` и его аналоги вам в помощь, равно как и штуки типа сигналов для отслеживания изменения конкретных полей контекста, а не обновление всех-всех-всех детей при любом изменении в модели.
Кроме вебсокетов ещё могут быть сложные UI-структуры, которые должны друг с другом взаимодействовать, типа вкладок как в VS Code (с возможностью разделения на зоны и перехода с вкладки на вкладку по кнопке открытия файла).
В общем, уходить в крайность и делать вообще любое состояние строго локальным — не менее ересь :)
Мне кажется, что в таких статьях и комментах под ними происходит столкновение двух концептуально разных подходов к рекрутингу — "нанять на века" vs "легко пришёл, легко ушёл".
Первое родилось в странах, где трудоустройство преимущественно официальное, а испытательные сроки либо не являются частью законодательства, либо реализованы через такую жопу, что работодатель этим заморачиваться не хочет. Например, если в случае увольнения придётся потом профсоюзу доказывать в суде, что это увольнение было обоснованным.
Ну и конкретно в РФ на это наложилось местное восприятие, что если устроился на работу — то не иначе как на ближайшие двадцать лет, а меньшее и планировать не стоит. Да и жаба как-то душит платить зарплату человеку, который может уйти через месяц. А вдруг следующий будет таким же.
В нашей компании технические собеседования обычно больше напоминают обмен кулстори, перемежающийся вопросами типа "а что вы думаете про useCallback?", "писали ли вы генсервер и в каких обстоятельствах это происходило?", или достаточно убойного "опишите, что происходит с запросом, идущим с фронта на бэк".
В последнем вопросе вообще нет правильного ответа, результат меряется на глаз и идёт сразу в несколько показателей, таких как: реакция на абстрактные вопросы, уровень структурированности мышления кандидата, дополнительные познания в смежных сферах, не указанные в резюме :)
Обмен кулстори и мнениями тоже предназначен больше для того, чтобы понять сразу ряд вещей, не всегда связанных напрямую с программированием, но очень сильно влияющих на результат. Типа склонности к изобретению велосипедов, излишней самоуверенности, абсолютного непонимания языка (английского языка, а не программирования), и т.п.
Но! Тут нужно иметь в виду ещё пару штук.
Во-первых, у нас нет предварительного шага в виде девочки, отсеивающей кандидатов тупыми вопросами типа "кем вы себя видите через пять лет". Техническое собеседование — оно же и социальное, если можно так выразиться. А дальше только разговор с менеджментом о зарплате и условиях в компании, если техническое прошёл.
Во-вторых, если человека наняли, но он стабильно не держит планку, то мы с ним расстаёмся. Это не испытательный срок, просто расстаёмся. Насколько быстро — зависит от размеров и частоты возникающих проблем и взаимонепониманий. В ранней истории компании были люди, которые вообще не понимали, где оказались и как работать. Неоднократно просирали сроки в самом начале, требовали ведения за ручку в коде, не отвечали или максимально неправильно для себя отвечали на прямые вопросы начальства, и т.п.
В-третьих, у нас стартап. Поэтому конкретно в нашем случае важнее, чтобы разработчик был способен взять фичу и сделать её от начала и до конца, а для всего остального есть код ревью, на котором всегда можно спросить, а почему у вас вот тут Enum.map() |> Enum.join() вместо Enum.map_join(), а вот тут в эффекте не отменяется запрос, идущий на сервер. Хотя вообще с частью этих проблем и статические анализаторы кода справляются.
В результате такого подхода в данный момент в компании с точки зрения написания кода вот уже пару лет неизменным составом работает несколько фуллстэков и один весьма крутой фронтенд. Но сколько людей при этом отсеялось с основания — не сосчитать :)
я приводил реальный пример из моего опыта c=a++++b
Честно говоря, я бы на этот вопрос ответил что-то в стиле — если это рабочий код из вашего приложения, то его нужно пошагово пропустить через дебаггер, чтобы понять, что при этом происходит, а потом переписать так, чтобы мозг не ломался при чтении :)
Точно так же, как корректный ответ на "что делает ++i++" — "это UB, не пишите так".
Могут быть уникальные случаи, когда это часть большого кода, который всеми используется как чёрная коробка, трогать его нельзя, и там всё написано таким образом, потому что автор — верный последователь Кармака и Силвермана. Тогда из вариантов только юнит-тестами обложить и не притрагиваться. А если от меня ожидают, что я это буду понимать интуитивно и сам писать то же самое, то спасибо, мне не туда))
Центр управления полётами крутой получился. Один минус — хрен переедешь на другое место жительства, если вдруг захочется. Но это не технологический минус)
Это к сожалению работает только для пет-проектов в которых у тебя нет ограничения по времени. При работе на дядю всегда есть строгие временные рамки и ты не можешь тратить время на изучение какой-нибудь новой для тебя фигни неделю.
Самый простой пример из мира веб-разработки: ты перед наймом на работу изучал React, может даже сделал пару страничек чтобы понять как это всё работает, а реальное продуктовое приложение построено с использованием не только реакта, но и Redux, причём скажем с RxJS и всё это образца года этак 2017. По своему опыту скажу что в таком проекте непонятно абсолютно всё.
А если там ещё какое-нибудь Immutable.js (никогда не пользуйтесь этим, кстати, очень медленная либа) то придётся ещё и изучать map/reduce, и на эти фокусы и пинг-понг во время код-ревью уйдёт ещё одна неделя.
С учетом контекста статьи - я правильно понимаю, что у вас остается только 1 джун из 10, остальных либо увольняют, либо они уходят сами?
Это не про джунов, а про разрабов в целом) И нет, неправильно. Смысл был в том, что те, кто уходят, уходят не из-за з/п, а потому что их увольняют из-за несоответствия должности.
Лояльность компании не совсем так работает. Пока твоя работа даёт тебе всё, что тебе нужно, ты на ней останешься чисто по привычке. Многие люди даже остаются на заведомо невыгодных работах просто потому, что боятся уйти в неизвестность. Чаще всего это происходит с первой-второй работой как раз, как у джунов.
А эти мифические люди, которые по мановению брови уходят к конкуренту, который больше заплатил... они как суслики, вроде бы существуют и все о них пишут, но я ни разу не видел их вживую.
90% текучки у нас — это люди, не справлявшиеся с задачами.
Вопрос: почему не брать сразу профицитных людей на х*2 зарплату?
Если рассматривать ситуацию с нуля, то смысла нет. Но джун-то уже есть, почему нельзя ему повысить зарплату? Это что-то из серии эффективного менеджмента класса "за что нанимался, за столько и паши" и "никогда не обсуждай зарплату с коллегами"?
А вообще ощутимый плюс в том, что не нужно посвящать нового человека в корпоративные секреты, выдавать доступы, забирать их потом, проверять насколько хорошо человек понимает задачи... нанять плохого разработчика очень легко, а если джун продержался достаточно времени, чтобы обоснованно просить повышения, то он скорее всего не плохой разработчик.
То есть повышая зарплату бывшему джуниору, который явно себя перерос, мы имеем явный плюс в его мотивации и лояльности. А увольняя его и нанимая другого человека мы имеем геморрой и неизвестность.
Другая картина: квартира, та же задача. Раздражение ментора, потому что вы обращаетесь, когда он максимально занят.
В нашей компании у ментора в такой ситуации нет права быть раздражённым, потому что "помочь новичку" — это конкретная задача, на которую выделяется время. Более того, это не для джунов, это для любого человека, который пришёл в компанию "только вчера". Как часть т.н. onboarding. Если я скажу начальству, что задача задерживается, т.к. я помогал новому разработчику, он поймёт и будет только рад, т.к. в его понимании — это освобождает от тупых вопросов его самого. Обратная сторона — если время будет тратиться очень часто, то нового разработчика всё-таки уволят, потому что мы джунов не нанимаем и об этом во второй половине поста.
А уж если заранее известно, что вы нанимаете человека без опыта, но при этом освоиться ему люди должны помогать в своё свободное время, никак не прописанное в распорядке дня, то что-то пошло серьёзно не так.
А ещё есть чудесная практика парного программирования через зум, когда один человек пишет, а другой на ходу делает ревью. Это хорошо работает даже для опытных программистов, например если ты фуллстэк и въезжаешь в какую-то принципиально новую для себя технологию, гораздо удобнее будет если тебя в неё посвятит человек для которого это главное или вообще единственное направление. У меня так было например со стэком Elixir+Ecto+LiveView.
В общем, это было о хорошем, а теперь о плохом.
У нас джунов не хотят брать не потому, что они чего-то не знают, а потому, что по определению начальства, джун — это человек, который думает о выполняемой задаче на принципиально неправильном уровне. То есть, он думает не о том, что делает (бизнес-логику и внешний вид), а о том, как пишет код. Это те самые джинны, которые выполняют желания слишком буквально, порождая недоработки и баги. Они не думают о том, как выглядит и работает существующая логика, бывшая до них. Честно говоря это может прозвучать грубо, но по-моему иногда они не думают вообще.
На случай, если этот коммент каким-то чудом будет читать человек, которому это когда-нибудь пригодится в работе, приведу парочку примеров типичных косяков джуниора в моём понимании (на самом деле эти косяки в нашей компании допускали люди, которые формально джуниорами не являлись и получали з/п от условных 2000$). Некоторые существенные, некоторые нет, но все из них отнимают время команды на фидбек от QA+заказчика, открытие багов, переоткрытие задач и т.п.
Кастомный кликабельный UI-элемент, в котором не будет прописано user-select: none или cursor: pointer, даже если во всей остальной платформе в подобных случаях оно прописано. Отсутствующий эффект ховера или нажатия, если его нет в дизайне. (Большинству дизайнеров пофиг с большой колокольни на ховеры, это не их уровень высоты художественного видения, так сказать)
Невнимательное чтение чужого кода при рефакторинге или переписывании, отсутствие тестирования совместимости с предыдущим кодом на всех промежуточных этапах. Конкретно этот пункт связан с записью JSON-данных в БД, но может произойти где угодно, где есть какие-то исторические вещи, с которыми нужно сохранять совместимость.
Цельный пулл реквест, содержащий одну фичу с нуля, которая не работает end-to-end. Например, фича регистрации через емейл, где емейл тупо не приходит или приходит в сильно поломанном виде. Или фича входа через OAuth, которая падает в 500 при попытке залогиниться через гугл. Это как правило указывает на то, что человек работает в режиме райт-онли и даже отдалённо не пытается свою логику тестировать, и ему норм.
Подпункт: реализация REST API условного микросервиса по спеку, по которому в этот API будут обращаться другие сервисы. Почему пункт здесь? А потому, что реализовано было абсолютно не по спеку, а по какому-то внутреннему пониманию программиста, и этого никто не замечал пока не пришли ко мне с "ничего не работает".
Боязнь задавать вопросы заказчику, дизайнеру и т.п. при явных несхождениях каких-то новых фич со старыми. Например, если заказчик скинул иконку, которая ни к селу ни к городу, она будет воткнута прям в таком виде, несмотря на то, что на самом деле имелось в виду что её надо использовать как референс и найти что-то похожее, но более уместное.
Спустя год от написания всё работает нормально с первого раза без танцев с бубном (по Ubuntu ставится 20.04), но статья всё равно мне помогла найти оптимальный способ запуска Airflow на виндовсе, спасибо :)
Например потому, что Hyper-V не работает с популярными у юзеров виртуалками (VMWare, VirtualBox)? Хотя сейчас, вроде, начали прикручивать (VirtualBox 6, VMWare Workstation 15.5), но работает очень через раз и по утверждениям разработчиков медленее чем должно.
При таком подходе очень заметно внезапное появление/исчезновение игроков, особенно при 200+ пинге. Ты чо, издатель не оценит. Некрасиво же. В бесплатных и индях ещё можно.
Ну и да, тот же аимбот таким образом не фиксится. Самый близкий «фикс» это не делиться с клиентом информацией о коллизии, отдельных сущностях (т.е. чтобы с точки зрения клиента не было разницы между моделью игрока и двери/стены).
Но я уверен что человек который достаточно сильно задастся целью продать чит — сможет эту информацию добыть хоть из положения пикселей на экране. Не говоря уже о перехватывании положения моделек непосредственно по идентификатору модели и т.п.
Это уже обфускация идёт, классическая криптографическая гонка между сложностью защиты и атаки. Причём в отличие от античита такой подход ещё и должен быть изначально интегрирован в сервер и клиент, а значит этим не смогут заниматься какие-нибудь индусы за 5 баксов, это придётся тратить время реальных разработчиков реальной игры.
И на фига, если можно воткнуть античит ценой возможного (не всегда ломается) отвала WINE? В общем, я бы тоже так сделал.
Какой-то чужой человек не хочет решать мои проблемы просто так? Какой ужас!
Ну я бы порешал, если бы денег было достаточно. После определённого порога уже +- пофиг, работаешь на интерес, а не на выживание.
Уточню. Вот если у меня не хватает денег пожрать вечером, тогда и работать не хочется. А если у меня не хватает денег купить дом через пару лет, или скажем на стартовый бюджет собственной компании, то это вообще не так воспринимается уже, и послать заказчика в лес по дрова не хочется.
Даже если бы мне резко стало не хватать на еду, ну или там резко деньги понадобились, я скорее тихо мирно буду искать новую работу где платят больше. А не филонить на этой. Ибо смысла в этом ноль вообще.
Фокус в том, что откуда-то берутся люди, живущие в Украине, получающие от 2-5 тысяч $ и всё равно имеющие позицию «ни малейшей мысли сверх джиры, ни строчки кода сверх оговоренного». Я таких видел. Не очень понравилось, для стартапа такая позиция подходит наихудшим образом, плохо было всем.
Самый простой пример обмана — сокрытие зарплат одного человека от другого. Одному говорят «денег нет, поднять не можем», а второго сразу нанимают за 5000 баксов в месяц без торга. И что, ни разу такого не встречалось? :)
По-моему это самая классическая практика которая есть везде.
И применяется ровно с целью уменьшения затрат у клиента на разработчиков.
Лол. Спасибо, узнал новое. Правда не совсем понимаю как можно было умудриться не найти коллизию. Чё-т мне подсказывает что они врут и никто и не искал)
Хотя ни разу не видев кода пинбола (даже в дизасме), но зная что это игра из 90-х, могу предположить что раз не нашли, то там могло быть какое-нибудь извращение с экономией памяти битмаской, которое резко перестало работать из-за изменения размера int/long.
Но это конечно с потолка взято. Уверен, что в инете уже кто-то это разобрал нормально чисто из интереса :)
Моё UnityAllods как раз и есть переписывание с нуля. Вопрос в том, что во-первых не все формулы совпадают (некоторые вещи в дизасме искать не очень удобно), во-вторых не все скрипты редактора работают (вернее, сейчас вообще никакие не работают — т.к. базовый функционал делается — но не все скрипты редактора вообще описаны).
Выкладывание исходников даст две вещи, во-первых будет возможность просто допилить существующую игру до исправления багов и совместимости с Win10, а во-вторых если это будет нецелесообразно (всё же это исходники 1999 года под реалии 1999 года) как минимум будет возможно потырить оттуда алгоритмы, которые ещё не потырены.
Насколько я знаю, из стороннего там используется только смакер, для проигрывания видео. А сама игра это самописная фигня, довольно странным образом использующая MFC и DDraw. Перепахана вдоль и поперёк в дизасме разными людьми за 20 лет, совпадений с другими играми не обнаружено.
Всё же русская игра 1999 года это не то место, где можно ожидать использования существующих лицензированных движков.
Но может конечно и да.
Хочется замолвить слово за людей, которые вникают в суть проекта. За тех, кому интересно что нужно сделать и главное для чего (а соответственно как быстро и насколько вдумчиво), а не только как это сделать технически.
Осторожно, много букв.
Я работаю в стартапе на удалёнке, уровней абстракции между мной и заказчиком — ноль. То есть он мне пишет в скайп что он хочет видеть, мы где-то полчасика беседуем если я чего-то не понял, после чего он уходит на какие-то свои митинги. К концу дня он возвращается и обычно видит всё, что хотел.
Бывают конечно ещё сложносоставные задачи, которые разбиваются на «спринт» по тематике — то есть создаём эпик, начинаем делать первую задачу в понедельник, в пятницу всё работает и деплоится на прод (иногда деплоится в следующий понедельник). Спринт в кавычках, т.к. методологиями по понятной причине никто не заморачивается.
Поначалу меня очень смущало, когда он внезапно с описания задачи переходил на описание своего бизнеса и пересказывания митингов. Но потом я понял, что в общем-то это позволяет мне одному выполнять задачи не менее эффективно, чем это делала команда из пяти человек до меня (полусуществующий БА, два фронтенда, два бекенда). При том что этих пять человек заказчику приходилось микроменеджить лично (вплоть до описания полей в БД для бекенда — как написано, так и сделают, даже если это было набросано за пару секунд и является примером, а так откровенным бредом). Потому их и уволили, собственно, а я плавно перешёл из QA-автоматизации в разработку — сначала вынужденно (пока искал работу), а потом з/п подняли и таки остался.
Самое главное, что эти разработчики не были куплены у галеры, они просто привыкли работать на большом продукте, где между ними и непосредственно заказчиком находится пара слоёв менеджеров, аналитиков, дизайнеров и прочих, которые разжуют всё.
В заключение хочется сказать, что существует два совершенно разных типа людей. Оба называют себя программистами, но при этом одни могут и хотят видеть картину в целом, а для других «за мкадом жизни нет» (то есть за их областью ответственности).
Они нужны в совершенно разных ситуациях, но при этом у первых есть преимущество: любой может целенаправленно абстрагироваться от целей проекта и прогать по джире, но очень сложно научить «марширующего» программиста мыслить более высокоуровнево.
А про отношение вида «состояние проекта в джире важнее, чем в реальности»…
Ну тут вообще уже нечего сказать. Воспитывавшие меня люди такое называли «подстава». Чисто по-человечески так делать нехорошо, если конечно заказчик со своей стороны поводов не давал.
P.S. По работе программирую на трёх языках стабильно и ещё около четырёх знаю по верхам на уровне «увязать вместе чтобы работало» и «понять шо ж там сломалось и почему». Также имею опыт работы с библиотеками, по которым документации нет и не будет, зато есть высокоуровневый диздок или вообще научная публикация в PDF с кучей матана внутри. Но собеседование на разработку скорее всего не пройду, потому что людям нужно, чтобы я на бумажке по памяти прогал с использованием новейших фреймворков :)
И именно такие требования на собеседованиях и появляются из-за засилья аутстафферов, умеющих проходить собесы и концентрирующихся на знании фреймворков, а не на поставленной задаче.
Ну во-первых, в начале подключения к серверу, клиенту скидывается дельта от изначального состояния уровня, называемая snapshot.
А потом — открытие/закрытие двери это глобальное действие посылающееся всем клиентам. Учитывая что дверей на уровне не очень много, и открываются/закрываются они не все сразу одновременно 60 раз в секунду, это решается отправкой пакета по reliable каналу в момент изменения состояния. (а конкретно в названном порте Дума таким же образом посылаются все эффекты анимации секторов (статических частей геометрии уровня), и даже так траффик достаточно низкий).
«Можно ли открыть» как правило предсказывается клиентом, т.к. у двери есть конкретный набор характеристик, прописанный в уровне. Есть конечно заскриптованные, но задержка 50-250мс не очень заметна пользователю, а если движок свой, то даже заскриптованные двери можно предсказывать в клиенте.
Я думаю, тут претензия к тому, что присутствуют лишние аллокации (т.е. создание новых массивов на каждом этапе) + итерирование с нуля (сначала filter, потом по отфильтрованным map)
т.о. аналогично такому коду:
Вместо:
Хочется сказать, что во-первых, скажите спасибо, что не так:
Во-вторых, скажите спасибо, что не
immutable.js. Кто видел, тот понял.А в-третьих, какая-то микро-оптимизация :)
Как минимум в реакте обычно проблема не в том, какие операции делаются, а в том, что они делаются слишком часто.
Ну, справедливости ради, реакт в 2024 уже мутировал до полной неузнаваемости :)
Как минимум, от него всё больше отпилили классы и прикрутили
React.FC.Ну, как бы, да, но нет.
С одной стороны, редукс — абсолютно безумная система, подразумевающая полностью глобальное состояние с одним центральным Root State. С другой стороны, моя главная претензия к редуксу — это не глобальное состояние, а бессмысленное и беспощадное MVC даже там, где это не нужно. Особенно когда он используется в комбинации с каким-нибудь RxJS, и в итоге вы пишете, по сути, клиент-серверную архитектуру, ещё до обращения к настоящему серверу.
Видел я вырожденный вариант этого подхода, когда локальный стейт вообще не использовался. Вспоминаю, как страшный сон. Была форма contact us, было что-то типа
<textarea value={feedback} onChange={...} />, а вот любое изменение в этой форме проходило через экшн вида{ type: 'FORM_CHANGE', id: 'contact-us', field: 'feedback', value: '...' }. В какой-то момент мне понадобилось в другой форме редактировать структуру из вложенных объектов с массивами, я психанул и удалил весь этот код. Поэтому, к сожалению, более конкретных примеров не будет.А какой-нибудь контекст, хранящий в себе вебсокет и функции для манипуляций с ним — богоугодное дело. Главное, чтобы без лишних ререндеров. `useConstCallback` и его аналоги вам в помощь, равно как и штуки типа сигналов для отслеживания изменения конкретных полей контекста, а не обновление всех-всех-всех детей при любом изменении в модели.
Кроме вебсокетов ещё могут быть сложные UI-структуры, которые должны друг с другом взаимодействовать, типа вкладок как в VS Code (с возможностью разделения на зоны и перехода с вкладки на вкладку по кнопке открытия файла).
В общем, уходить в крайность и делать вообще любое состояние строго локальным — не менее ересь :)
Мне кажется, что в таких статьях и комментах под ними происходит столкновение двух концептуально разных подходов к рекрутингу — "нанять на века" vs "легко пришёл, легко ушёл".
Первое родилось в странах, где трудоустройство преимущественно официальное, а испытательные сроки либо не являются частью законодательства, либо реализованы через такую жопу, что работодатель этим заморачиваться не хочет. Например, если в случае увольнения придётся потом профсоюзу доказывать в суде, что это увольнение было обоснованным.
Ну и конкретно в РФ на это наложилось местное восприятие, что если устроился на работу — то не иначе как на ближайшие двадцать лет, а меньшее и планировать не стоит. Да и жаба как-то душит платить зарплату человеку, который может уйти через месяц. А вдруг следующий будет таким же.
В нашей компании технические собеседования обычно больше напоминают обмен кулстори, перемежающийся вопросами типа "а что вы думаете про
useCallback?", "писали ли вы генсервер и в каких обстоятельствах это происходило?", или достаточно убойного "опишите, что происходит с запросом, идущим с фронта на бэк".В последнем вопросе вообще нет правильного ответа, результат меряется на глаз и идёт сразу в несколько показателей, таких как: реакция на абстрактные вопросы, уровень структурированности мышления кандидата, дополнительные познания в смежных сферах, не указанные в резюме :)
Обмен кулстори и мнениями тоже предназначен больше для того, чтобы понять сразу ряд вещей, не всегда связанных напрямую с программированием, но очень сильно влияющих на результат. Типа склонности к изобретению велосипедов, излишней самоуверенности, абсолютного непонимания языка (английского языка, а не программирования), и т.п.
Но! Тут нужно иметь в виду ещё пару штук.
Во-первых, у нас нет предварительного шага в виде девочки, отсеивающей кандидатов тупыми вопросами типа "кем вы себя видите через пять лет". Техническое собеседование — оно же и социальное, если можно так выразиться. А дальше только разговор с менеджментом о зарплате и условиях в компании, если техническое прошёл.
Во-вторых, если человека наняли, но он стабильно не держит планку, то мы с ним расстаёмся. Это не испытательный срок, просто расстаёмся. Насколько быстро — зависит от размеров и частоты возникающих проблем и взаимонепониманий. В ранней истории компании были люди, которые вообще не понимали, где оказались и как работать. Неоднократно просирали сроки в самом начале, требовали ведения за ручку в коде, не отвечали или максимально неправильно для себя отвечали на прямые вопросы начальства, и т.п.
В-третьих, у нас стартап. Поэтому конкретно в нашем случае важнее, чтобы разработчик был способен взять фичу и сделать её от начала и до конца, а для всего остального есть код ревью, на котором всегда можно спросить, а почему у вас вот тут
Enum.map() |> Enum.join()вместоEnum.map_join(), а вот тут в эффекте не отменяется запрос, идущий на сервер. Хотя вообще с частью этих проблем и статические анализаторы кода справляются.В результате такого подхода в данный момент в компании с точки зрения написания кода вот уже пару лет неизменным составом работает несколько фуллстэков и один весьма крутой фронтенд. Но сколько людей при этом отсеялось с основания — не сосчитать :)
Честно говоря, я бы на этот вопрос ответил что-то в стиле — если это рабочий код из вашего приложения, то его нужно пошагово пропустить через дебаггер, чтобы понять, что при этом происходит, а потом переписать так, чтобы мозг не ломался при чтении :)
Точно так же, как корректный ответ на "что делает ++i++" — "это UB, не пишите так".
Могут быть уникальные случаи, когда это часть большого кода, который всеми используется как чёрная коробка, трогать его нельзя, и там всё написано таким образом, потому что автор — верный последователь Кармака и Силвермана. Тогда из вариантов только юнит-тестами обложить и не притрагиваться. А если от меня ожидают, что я это буду понимать интуитивно и сам писать то же самое, то спасибо, мне не туда))
Пипец. Как же счастливы люди с хорошим зрением :)
Центр управления полётами крутой получился. Один минус — хрен переедешь на другое место жительства, если вдруг захочется. Но это не технологический минус)
Это к сожалению работает только для пет-проектов в которых у тебя нет ограничения по времени. При работе на дядю всегда есть строгие временные рамки и ты не можешь тратить время на изучение какой-нибудь новой для тебя фигни неделю.
Самый простой пример из мира веб-разработки: ты перед наймом на работу изучал React, может даже сделал пару страничек чтобы понять как это всё работает, а реальное продуктовое приложение построено с использованием не только реакта, но и Redux, причём скажем с RxJS и всё это образца года этак 2017. По своему опыту скажу что в таком проекте непонятно абсолютно всё.
А если там ещё какое-нибудь Immutable.js (никогда не пользуйтесь этим, кстати, очень медленная либа) то придётся ещё и изучать map/reduce, и на эти фокусы и пинг-понг во время код-ревью уйдёт ещё одна неделя.
Это не про джунов, а про разрабов в целом) И нет, неправильно. Смысл был в том, что те, кто уходят, уходят не из-за з/п, а потому что их увольняют из-за несоответствия должности.
Лояльность компании не совсем так работает. Пока твоя работа даёт тебе всё, что тебе нужно, ты на ней останешься чисто по привычке. Многие люди даже остаются на заведомо невыгодных работах просто потому, что боятся уйти в неизвестность. Чаще всего это происходит с первой-второй работой как раз, как у джунов.
А эти мифические люди, которые по мановению брови уходят к конкуренту, который больше заплатил... они как суслики, вроде бы существуют и все о них пишут, но я ни разу не видел их вживую.
90% текучки у нас — это люди, не справлявшиеся с задачами.
Если рассматривать ситуацию с нуля, то смысла нет. Но джун-то уже есть, почему нельзя ему повысить зарплату? Это что-то из серии эффективного менеджмента класса "за что нанимался, за столько и паши" и "никогда не обсуждай зарплату с коллегами"?
А вообще ощутимый плюс в том, что не нужно посвящать нового человека в корпоративные секреты, выдавать доступы, забирать их потом, проверять насколько хорошо человек понимает задачи... нанять плохого разработчика очень легко, а если джун продержался достаточно времени, чтобы обоснованно просить повышения, то он скорее всего не плохой разработчик.
То есть повышая зарплату бывшему джуниору, который явно себя перерос, мы имеем явный плюс в его мотивации и лояльности. А увольняя его и нанимая другого человека мы имеем геморрой и неизвестность.
В нашей компании у ментора в такой ситуации нет права быть раздражённым, потому что "помочь новичку" — это конкретная задача, на которую выделяется время. Более того, это не для джунов, это для любого человека, который пришёл в компанию "только вчера". Как часть т.н. onboarding. Если я скажу начальству, что задача задерживается, т.к. я помогал новому разработчику, он поймёт и будет только рад, т.к. в его понимании — это освобождает от тупых вопросов его самого. Обратная сторона — если время будет тратиться очень часто, то нового разработчика всё-таки уволят, потому что мы джунов не нанимаем и об этом во второй половине поста.
А уж если заранее известно, что вы нанимаете человека без опыта, но при этом освоиться ему люди должны помогать в своё свободное время, никак не прописанное в распорядке дня, то что-то пошло серьёзно не так.
А ещё есть чудесная практика парного программирования через зум, когда один человек пишет, а другой на ходу делает ревью. Это хорошо работает даже для опытных программистов, например если ты фуллстэк и въезжаешь в какую-то принципиально новую для себя технологию, гораздо удобнее будет если тебя в неё посвятит человек для которого это главное или вообще единственное направление. У меня так было например со стэком Elixir+Ecto+LiveView.
В общем, это было о хорошем, а теперь о плохом.
У нас джунов не хотят брать не потому, что они чего-то не знают, а потому, что по определению начальства, джун — это человек, который думает о выполняемой задаче на принципиально неправильном уровне. То есть, он думает не о том, что делает (бизнес-логику и внешний вид), а о том, как пишет код. Это те самые джинны, которые выполняют желания слишком буквально, порождая недоработки и баги. Они не думают о том, как выглядит и работает существующая логика, бывшая до них. Честно говоря это может прозвучать грубо, но по-моему иногда они не думают вообще.
На случай, если этот коммент каким-то чудом будет читать человек, которому это когда-нибудь пригодится в работе, приведу парочку примеров типичных косяков джуниора в моём понимании (на самом деле эти косяки в нашей компании допускали люди, которые формально джуниорами не являлись и получали з/п от условных 2000$). Некоторые существенные, некоторые нет, но все из них отнимают время команды на фидбек от QA+заказчика, открытие багов, переоткрытие задач и т.п.
Кастомный кликабельный UI-элемент, в котором не будет прописано user-select: none или cursor: pointer, даже если во всей остальной платформе в подобных случаях оно прописано.
Отсутствующий эффект ховера или нажатия, если его нет в дизайне.
(Большинству дизайнеров пофиг с большой колокольни на ховеры, это не их уровень высоты художественного видения, так сказать)
Невнимательное чтение чужого кода при рефакторинге или переписывании, отсутствие тестирования совместимости с предыдущим кодом на всех промежуточных этапах. Конкретно этот пункт связан с записью JSON-данных в БД, но может произойти где угодно, где есть какие-то исторические вещи, с которыми нужно сохранять совместимость.
Цельный пулл реквест, содержащий одну фичу с нуля, которая не работает end-to-end. Например, фича регистрации через емейл, где емейл тупо не приходит или приходит в сильно поломанном виде. Или фича входа через OAuth, которая падает в 500 при попытке залогиниться через гугл. Это как правило указывает на то, что человек работает в режиме райт-онли и даже отдалённо не пытается свою логику тестировать, и ему норм.
Подпункт: реализация REST API условного микросервиса по спеку, по которому в этот API будут обращаться другие сервисы. Почему пункт здесь? А потому, что реализовано было абсолютно не по спеку, а по какому-то внутреннему пониманию программиста, и этого никто не замечал пока не пришли ко мне с "ничего не работает".
Боязнь задавать вопросы заказчику, дизайнеру и т.п. при явных несхождениях каких-то новых фич со старыми. Например, если заказчик скинул иконку, которая ни к селу ни к городу, она будет воткнута прям в таком виде, несмотря на то, что на самом деле имелось в виду что её надо использовать как референс и найти что-то похожее, но более уместное.
В посте ж написано что железо десктопное.
Ну и да, тот же аимбот таким образом не фиксится. Самый близкий «фикс» это не делиться с клиентом информацией о коллизии, отдельных сущностях (т.е. чтобы с точки зрения клиента не было разницы между моделью игрока и двери/стены).
Но я уверен что человек который достаточно сильно задастся целью продать чит — сможет эту информацию добыть хоть из положения пикселей на экране. Не говоря уже о перехватывании положения моделек непосредственно по идентификатору модели и т.п.
Это уже обфускация идёт, классическая криптографическая гонка между сложностью защиты и атаки. Причём в отличие от античита такой подход ещё и должен быть изначально интегрирован в сервер и клиент, а значит этим не смогут заниматься какие-нибудь индусы за 5 баксов, это придётся тратить время реальных разработчиков реальной игры.
И на фига, если можно воткнуть античит ценой возможного (не всегда ломается) отвала WINE? В общем, я бы тоже так сделал.
Ну я бы порешал, если бы денег было достаточно. После определённого порога уже +- пофиг, работаешь на интерес, а не на выживание.
Уточню. Вот если у меня не хватает денег пожрать вечером, тогда и работать не хочется. А если у меня не хватает денег купить дом через пару лет, или скажем на стартовый бюджет собственной компании, то это вообще не так воспринимается уже, и послать заказчика в лес по дрова не хочется.
Даже если бы мне резко стало не хватать на еду, ну или там резко деньги понадобились, я скорее тихо мирно буду искать новую работу где платят больше. А не филонить на этой. Ибо смысла в этом ноль вообще.
Фокус в том, что откуда-то берутся люди, живущие в Украине, получающие от 2-5 тысяч $ и всё равно имеющие позицию «ни малейшей мысли сверх джиры, ни строчки кода сверх оговоренного». Я таких видел. Не очень понравилось, для стартапа такая позиция подходит наихудшим образом, плохо было всем.
По-моему это самая классическая практика которая есть везде.
И применяется ровно с целью уменьшения затрат у клиента на разработчиков.
Хотя ни разу не видев кода пинбола (даже в дизасме), но зная что это игра из 90-х, могу предположить что раз не нашли, то там могло быть какое-нибудь извращение с экономией памяти битмаской, которое резко перестало работать из-за изменения размера int/long.
Но это конечно с потолка взято. Уверен, что в инете уже кто-то это разобрал нормально чисто из интереса :)
Выкладывание исходников даст две вещи, во-первых будет возможность просто допилить существующую игру до исправления багов и совместимости с Win10, а во-вторых если это будет нецелесообразно (всё же это исходники 1999 года под реалии 1999 года) как минимум будет возможно потырить оттуда алгоритмы, которые ещё не потырены.
Всё же русская игра 1999 года это не то место, где можно ожидать использования существующих лицензированных движков.
Но может конечно и да.
Осторожно, много букв.
Я работаю в стартапе на удалёнке, уровней абстракции между мной и заказчиком — ноль. То есть он мне пишет в скайп что он хочет видеть, мы где-то полчасика беседуем если я чего-то не понял, после чего он уходит на какие-то свои митинги. К концу дня он возвращается и обычно видит всё, что хотел.
Бывают конечно ещё сложносоставные задачи, которые разбиваются на «спринт» по тематике — то есть создаём эпик, начинаем делать первую задачу в понедельник, в пятницу всё работает и деплоится на прод (иногда деплоится в следующий понедельник). Спринт в кавычках, т.к. методологиями по понятной причине никто не заморачивается.
Поначалу меня очень смущало, когда он внезапно с описания задачи переходил на описание своего бизнеса и пересказывания митингов. Но потом я понял, что в общем-то это позволяет мне одному выполнять задачи не менее эффективно, чем это делала команда из пяти человек до меня (полусуществующий БА, два фронтенда, два бекенда). При том что этих пять человек заказчику приходилось микроменеджить лично (вплоть до описания полей в БД для бекенда — как написано, так и сделают, даже если это было набросано за пару секунд и является примером, а так откровенным бредом). Потому их и уволили, собственно, а я плавно перешёл из QA-автоматизации в разработку — сначала вынужденно (пока искал работу), а потом з/п подняли и таки остался.
Самое главное, что эти разработчики не были куплены у галеры, они просто привыкли работать на большом продукте, где между ними и непосредственно заказчиком находится пара слоёв менеджеров, аналитиков, дизайнеров и прочих, которые разжуют всё.
В заключение хочется сказать, что существует два совершенно разных типа людей. Оба называют себя программистами, но при этом одни могут и хотят видеть картину в целом, а для других «за мкадом жизни нет» (то есть за их областью ответственности).
Они нужны в совершенно разных ситуациях, но при этом у первых есть преимущество: любой может целенаправленно абстрагироваться от целей проекта и прогать по джире, но очень сложно научить «марширующего» программиста мыслить более высокоуровнево.
А про отношение вида «состояние проекта в джире важнее, чем в реальности»…
Ну тут вообще уже нечего сказать. Воспитывавшие меня люди такое называли «подстава». Чисто по-человечески так делать нехорошо, если конечно заказчик со своей стороны поводов не давал.
P.S. По работе программирую на трёх языках стабильно и ещё около четырёх знаю по верхам на уровне «увязать вместе чтобы работало» и «понять шо ж там сломалось и почему». Также имею опыт работы с библиотеками, по которым документации нет и не будет, зато есть высокоуровневый диздок или вообще научная публикация в PDF с кучей матана внутри. Но собеседование на разработку скорее всего не пройду, потому что людям нужно, чтобы я на бумажке по памяти прогал с использованием новейших фреймворков :)
И именно такие требования на собеседованиях и появляются из-за засилья аутстафферов, умеющих проходить собесы и концентрирующихся на знании фреймворков, а не на поставленной задаче.
А потом — открытие/закрытие двери это глобальное действие посылающееся всем клиентам. Учитывая что дверей на уровне не очень много, и открываются/закрываются они не все сразу одновременно 60 раз в секунду, это решается отправкой пакета по reliable каналу в момент изменения состояния. (а конкретно в названном порте Дума таким же образом посылаются все эффекты анимации секторов (статических частей геометрии уровня), и даже так траффик достаточно низкий).
«Можно ли открыть» как правило предсказывается клиентом, т.к. у двери есть конкретный набор характеристик, прописанный в уровне. Есть конечно заскриптованные, но задержка 50-250мс не очень заметна пользователю, а если движок свой, то даже заскриптованные двери можно предсказывать в клиенте.