Как стать автором
Обновить
46
2.5

Пользователь

Отправить сообщение

А в чём вообще проблема?

Проблема в том, что рассказ был про бинарность и ригидность мышления, нежелание понимать и принимать другие точки зрения, про разделение общества. Про то, что во всём этом нет никакого смысла. Нет смысла в спорах Windows vs Linux, Intel vs AMD, 1 vs 4, эльфы vs орков и т.д. Если человек придерживается иной точки зрения по любому вопросу, то можно оставить ему право "заблуждаться" или, если очень хочется, то попробовать разобраться почему он думает иначе. На мой субъективный взгляд это важная проблема, я надеялся этим рассказом сделать мир немного лучше.

Ещё хотелось насыпать немного кринжа про ежедневную рутину, когда условные коммиты в Git или любая другая работа съедают всё время человека. И только в выходные у него появляется возможность задуматься о действительно важных для него вещах. Но он этого не делает, потому что вокруг то чума, то война, то санкции, то голые вечеринки, то Пугачёва разводится с Галкиным, то ещё что-то. На мой субъективный взгляд, эта проблема особенно актуальна для ИТ, когда вся жизнь превращается в работу. Плюс СМИ ежедневно поддерживают информационный фон абсолютной жести и ада. И при всём этом гораздо комфортнее плыть по течению, закопаться в работу, строительство дачи и т.п. Очень страшно остаться наедине со своими мыслями, внутренней пустотой.

Но похоже никому не зашло. В следующий раз попробую подобрать более интересную тему, типа удаления WordPad из Windows или как лучше проходить собесы :)

Это подходит, если зп - основной приоритет. А если работа даёт самореализацию, у тебя интересный проект, то так просто не начнёшь ходить по собеседованиям. Иногда бывают разные предложения и я думаю какая минимальная сумма за которую я перешел бы к ним. Наверное я начал бы задумываться только при предложении x2 - x3 относительно текущей зп и то не факт. Понятно что никто столько и не предложит, поэтому какой смысл вообще идти на собеседование. Что самое смешное в некоторых компаниях наотрез отказываются рассказывать о твоём будущем проекте пока ты не пройдёшь 7 кругов собеседований. Ради чего? Чтобы просто попасть в вашу компанию и заниматься чем угодно?

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

В целом деньги наверное не такой плохой ориентир. Если ты просил повысить зп и тебе отказали, то может действительно ты не на столько нужен на этом проекте или проект не на столько востребован и перспективен.

Я иногда чувствую себя ChatGPT, у меня в каждом комментарии запускается бесконечный поток рефлексии. Основное отличие от искусственной нейронной сети наверное в том, что я отвечаю не на любой промпт, а на то, что триггерит лично меня и опираюсь преимущественно на личный опыт, а не на усредненный общечеловеческий. Интересная идея для стартапа - создать много разных нейронных сетей, которые опираются преимущественно на свои прошлые диалоги, могут узнавать собеседников, вспоминать какие-то факты из прошлого, которые те им рассказывали или наоборот могут рассказывать какие-то новые факты, которые будут интересны конкретному собеседнику. Интересно можно ли считать, что у такой нейронной сети будет личность, индивидуальность...

Вот, идея ещё для одного стартапа. В принципе, мой комментарий - это наверное не такой уж безумной поток случайных фактов и ассоциаций как выглядит на первый взгляд. Я очень часто начинаю с того, что пишу что-то совершенно противоположное тому, что пишет собеседник, например, "деньги не главное, интересный проект важнее". Потом путём долгой рефлексии, случайных ассоциаций, кулл стори из жизни я прихожу к тому, что, блин, наверное деньги всё-таки важны и в чём-то мой собеседник прав. Затем пытаюсь всё обобщить и подытожить, что наверное и то, и то важно и вообще в жизни нужен баланс. Потом мне становится душно от собственных пафосных нравоучений. И я начинаю иронизировать над собой "типа я как ChatGPT выдаю потоки безумия только по форме похожие на осмысленный текст". Потом включаются детские травмы и я пытаюсь доказать всем какой я замечательный, уже идею для второго стартапа описываю, хотя вроде ничего не предвещало, а представляете сколько идей я на работе генерю! Возьмите меня пожалуйста кто-нибудь на крутую работу с большой зп, ну, или хотя бы похвалите! Короче, если я не сверну сейчас этот поток саморефлексии, то наверное открою портал в ад (это как если два зеркала друг напротив друга поставить). В общем изначальная идея стартапа была добавить в ответы искусственной нейронной сети подобные паттерны, типа сначала не соглашаемся с собеседником, потом в итоге соглашаемся, а затем всё обобщаем. Хотя, блин, пока я это описывал придумал третий стартап - саморефлексирующий ИИ. И четвертый - ИИ, иронизирующий над разными вещами, например, над стартапами... Ой, минуту, у меня в комнате почему-то заиграла музыка Мика Гордона, в полу появилась полупрозрачная вибрирующая мембрана и кто-то см...

Теоретически наверное есть, но практически это почти полностью зависит от того сколько человек сам попросит. Нет никакого смысла надеяться, что кто-то поймёт и оценит вашу способность решать сложные задачи. Более того, лично у меня на всех работах корреляция зарплаты с масштабностью проектов была обратная, потому что я и так был замотивирован ей заниматься. Плюс если проект интересный, то сложнее от него отказаться и сменить работу с повышением зп.

На мой взгляд на 31:47 описан абсолютно типичный подход к оценке труда:

https://www.youtube.com/watch?v=5-8rnwvZv7A&t=1907s

Вольная цитата: "Допустим, на проекте есть два человека, которые одинаково работают. Одному из них платишь мало, но ему хватает на еду, его прёт от работы и т.п. А если другому, нужно в 2 раза больше на отпуск на Бали 4 раза в год, новую машину и т.д., ну, просто у него такие потребности и он о них сообщает, то совершенно норм платить ему больше. Какая разница, если всех всё устраивает?.. А всех всё устраивает пока они не знают зп друг друга."

Например, я видел проекты, где техлид делает самые сложные задачи, работает больше всех и при этом получает в 2 раза меньше, чем рядовой разработчик, который за полгода самостоятельно закрывает ноль задач. При этом последнему не повышают зп, только переводят на ещё более простые задачи, он капец как недоволен этим и уходит в следующую компанию с повышением зп опять ничего не делать. А техлиду единственному на проекте даже годовую премию не выплачивают и он всё равно продолжает работать.

Да-да-да, конечно он сам дурак, просто у него не прокачены софтскилы и вообще возможно он не так хорош, обычный джун случайно попавший на позицию техлида - на мой взгляд всё это очередная пачка штампов распространенных в ИТ. У человека могут быть прекрасно прокачены софт-скилы, он понимает процесс разработки в целом, очень быстро разрешает любые вопросы с аналитиками и разработчиками, у него может быть отличное понимание создаваемого продукта, он разбирается в этой предметной области, легко декомпозирует сложные задачи, точно оценивает сроки, не боится браться за исследовательские задачи, менторит других разработчиков и т.д.

Но умение просить повышение зп, вовремя менять компании, понимание рынка, адекватная оценка себя и т.д. - на мой взгляд это совершенно отдельный навык, который не имеет отношения ни к хард, ни к софт скилам.

В общем, если подытожить всё это излияние, то на мой взгляд нужно концентрироваться не только на своих хард и софт скилах и ждать что кто-то их оценит. Нет, никто и никогда их не оценит, ровно наоборот, все будут абсолютно уверены, что вам и так норм, вам не нужен отпуск, а нужно ещё подкинуть работы, потому что вы прётесь от неё. А если хочется какого-то баланса в жизни, адекватной оценки своего труда, то это совершенно отдельный скилл. И если для человека это действительно важно, то наверное есть смысл осознать это, а не тупо отмахиваться: 1) о, да, просто у тебя компания плохая, в нормальных компаниях зп сама повышается 2) да наверное ты просто не так хорош как думаешь, был бы хорош получал бы больше. Меня триггерит от таких установок, я считаю их капец вредными.

Если Teams открыт и на компе, и на телефоне, то уведомления о новых сообщениях всегда приходят на телефон, даже если уже прочитаны на компе. Это выглядит совершенно базовой функциональностью, в телеграме почему-то работает. Чтобы включить эти уведомления тоже понадобились дополнительные настройки на телефоне, хотя в телеграме всё работало из коробки. Это на столько раздражает, что я отключил звук уведомлений на телефоне и вообще хочу удалить это приложение. С одной стороны, это плюс, потому что после удаления мобильного Teams станет только лучше. Но с другой стороны удивительно как можно сделать на столько раздражающее приложение... Может я единственный, человек, кто установил Teams и на комп, и на телефон? В моём рейтинге самых плохих приложений Skype и Teams делят первое место.

После звонка не отключается микрофон - это видно по значку микрофона в области уведомлений. Немного напрягает.

Нет полнофункционального клиента для Linux, например, чтобы поменять фон при видео-звонке. И в целом ощущение, что клиент для Linux не особо обновляется, хотя может в нём на самом деле используется обычный веб-клиент, поэтому нечего обновлять. И в веб-клиенте вроде тоже нельзя поменять фон. Не понимаю, почему на разных платформах возможности отличаются.

На Linux нельзя кликнуть по ссылке в письме и открыть звонок в десктопном приложении, открывается только в браузере. Раньше это работало, сейчас перестало. Может у меня что-то не так настроено, но почему с телеграмом нет таких проблем?

На Windows некоторые коллеги говорят, что из-за глюков перешли на веб-клиент. И у меня тоже иногда бывают баги, на днях шарил экран, попытался в чат отправить сообщение, Teams полностью завис, пришлось перезапускать.

При первом запуске часто не видны чаты, приходится перезапускать.

Команды - это какой-то неудобный ад, приходится пользоваться обычными чатами.

Мобильное приложение почему-то занимает в 3 раза больше, чем телеграм.

В целом работает ощутимо медленнее, чем телеграм.

Поиск в чатах и прокрутка - это какая-то жесть, всё перескакивает. Хотя, проверил сейчас, вроде стало нормально, ура! Ещё недавно этим было невозможно пользоваться.

Ради интереса посчитал свою статистику :)

Для большого количества задач фактическое время совпадает с оценкой с точностью до дня. В целом я обычно завышаю оценку на 1-2 дня:

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

В сумме у меня получилась перестраховка на 42% - я реально посчитал, а не взял это число из Автостопом по галактике :). Правда это по мелким задачам. Возможна ситуация, что задачу завершили раньше, но завели по ней ещё несколько багов, которые тоже исправили раньше. Но если посмотреть в сумме за год, то эта перестраховка в итоге выходит примерно в ноль.

Кстати, что интересно я от разных людей слышал про коэффициент риска равный квадратному корню из двух - sqrt(2) = 1.41, что удивительно близко к моей интуитивной перестраховке.

  1. Спасибо за ссылку! Когда-то давно краем глаза видел, но я не фуллтайм фронтендер, поэтому не отложилось в памяти. При написании кода это клево, но читать тяжело. Особенно если на проекте много людей которые только иногда заглядывают во фронт. Я имел в виду такие сокращения https://mui.com/system/getting-started/the-sx-prop/#spacing типа pt (который есть в Emmet), my (которого нет в Emmet), ... А потом MUI перейдёт на StyleX и опять переделывать все стили...

  1. Мне привычнее и проще это сделать в браузере. Для меня один из больших плюсов веб-разработки в том, что она практически ничего не требует кроме браузера и любого текстового редактора. Очень легко и просто делается минимальный пример, прямо в браузере можно его поправить, сразу виден результат. Для реальных проектов, наверное, да, без сложного тулинга не обойтись, но иногда ощущение что люди искусственно делают простые вещи сложными. А потом в какой-то момент начинают писать статьи, что мы тут подумали и решили отказаться от TypeScript. Я не удивлюсь если через какое-то время фб откажется от StyleX в пользу обычного CSS.

  2. Обычные переменные в CSS да, но когда всё это замешивается с JavaScript-кодом, то люди начинают там реализовывать просто лютейшую логику с кучей функций разбросанных по всему проекту. А в CSS у них такой возможности нет, приходится напрягать мозг, чтобы описать стили проще. Если в CSS-in-JS писать простые стили с простыми переменными без JavaScript-кода наверное это норм, но чем это лучше обычного CSS с переменными?..

Для меня минусы этой штуки и вообще CSS-in-JS вполне понятны:

  1. Вместо понятного и распространенного CSS добавляется лишняя абстракция. Нужно дополнительно напрягать мозг при написании и чтении стилей. И глядя на какой-нибудь `p: 10` пытаться понять что это значит. Не знаю есть ли конкретно в StyleX такие сокращения, но зачем мне изучать ещё один язык, если я уже знаю CSS?

  2. Изредка хочется использовать относительно сложные селекторы. В StyleX они видимо вообще не поддерживаются?

  3. Информации по CSS просто на много-много порядков больше, чем по очередному CSS-in-JS. Когда находишь какой-нибудь CSS-рецепт каждый раз нужно его транслировать в StyleX или наоборот если у тебя проблемы со стилями, то чтобы задать вопрос их нужно сначала перевести на CSS.

  4. Нельзя за 2 минуты создать HTML+CSS файлик в "блокноте" и по-быстрому отладить стили в браузере. Или поправить стиль в браузере и скопировать обратно

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

  6. Эти фреймвоки бесконечно меняются и запаришься каждый раз мигрировать стили

  7. Генерятся классы с рандомными названиями - их нельзя использовать для какой-нибудь логики на JS, для тестов

  8. В чем вообще смысл всё запихивать в один большой файл? С двумя маленькими файлами проще работать чем с одним большим

Пытаюсь понять плюсы:

  1. Возможно лет 15 назад, когда было много разных браузеров, CSS в них работал по-разному и вообще был очень ограниченный, был какой-то смысл в этих абстракциях, но сейчас зачем это

  2. Решение проблем с наложением стилей, специфичностью. У меня обычно этих проблем не возникает, я просто придерживаюсь единой схемы описания стилей. Но ещё есть же всякие CSS layer, scope, shadow DOM. Они не решают эту проблему?

  3. Людям сложно изучить CSS, а JS они уже знают. Непонятно что StyleX здесь упрощает, CSS всё равно придётся изучить, плюс добавится сложностей по постоянной трансляции стилей между CSS и StyleX в уме

  4. Уменьшение суммарного размера CSS, ускорение загрузки и отрисовки за счет удаления неиспользуемых стилей при сборке, за счет динамической подгрузки стилей. Я в принципе не понимаю как можно написать стилей на десятки мегабайт, но для проекта масштаба фб наверное это возможно... Вообще конечно было бы интересно посмотреть что это за стили, почему их так много

  5. Поддержка стилей не только в браузере, но и в нативных приложениях. В какой доле проектов это требуется?

В общем, к каким проблемам приведет StyleX я понимаю совершенно отчетливо, а преимущества как-то вообще не очевидны.

Мне эта тема очень близка. Я сам работал разработчиком, потом аналитиком, сейчас архитектором, техлидом (по факту одновременно и разработчиком, и аналитиком). На мой взгляд аналитические навыки важны для любого ИТшника. Лично у меня такой топ навыков:

1) Аналитический склад ума - это буквально способность раскладывать сложную задачу на более простые. Это полезно не только для аналитиков, но и для разработчиков, тестировщиков, РП. Например, мне как разработчику нужно реализовать что-то очень сложное. Прежде чем браться за это мне нужно разложить задачу на понятные шаги, выделить какие-то крупные модули будущего приложения. Или, например, есть несколько вариантов реализации задачи, человек с аналитическими навыками достаточно легко перечислит эти варианты, определит критерии для их сравнения и выберет оптимальный вариант. Такой выбор часто встаёт не только перед аналитиками, но и перед разработчиками.

2) Понимание процесса разработки в целом. Какая бы специализация у человека ни была, очень хорошо если он понимает через какие этапы проходит задача:

а) бизнес-анализ - когда задача максимально размыта, непонятно что делать и нужно преимущество собирать информацию, заниматься НИР

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

в) разработка

г) тестирование

д) демонстрация заказчику, сдача в эксплуатацию

Например, для разработчиков важно понимать какие этапы задача должна была пройти до того как попала к ним. Если она недостаточно проработана с точки зрения аналитики, то можно не тупо реализовывать как написано, а пойти обсудить спорные вещи с аналитиками. Или если аналитиков на проекте нет, то самому написать и согласовать какой-нибудь минимальный дизайн-документ. Или предупредить заказчика, что реализация может быть не такой как он ожидает или что сроки неопределенные. Также полезно понимать какие этапы будут после того как ты реализовал свою задачу. Можно заранее поставить себя на место тестировщика или пользователя и прикинуть на сколько удобная и понятная получилась реализация. Что человеку будет удобнее - нажать десять кнопок или одну.

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

3) Затем идёт основной навык специалиста.

Для разработчиков - это безусловно умение описывать и реализовывать алгоритмы. Конечно далеко не на всех проектах требуются сложные алгоритмы. Но, блин, даже в самых простых задачах условно "по перекладыванию JSONов" я часто вижу какой-нибудь поиск по массиву с квадратичной сложностью, какой-то безумный код, в котором просто невозможно ничего понять. Хотя бы базовое знание структур данных, алгоритмов нужно. Но заметьте, что я поставил это на третье место!

Для аналитиков - это умение собирать и обобщать информацию, в сжатом и понятном виде (текстом или голосом) доносить её до остальных участников проекта. Если аналитику приходится что-то объяснять, спорить, предлагать посмотреть ещё какие-то варианты и т.д., то работать тяжело - на мой взгляд это аналитик должен максимально быстро и легко воспринимать любую информацию и складывать её в соответствующую коробочку. Лично я ожидаю от аналитика что-то типа: да, я понимаю о чём ты говоришь, я об этом уже подумал, но это частный случай такой-то ситуации, мы его сможем реализовать потом. А если аналитик наоборот всё усложняет, находит какой-нибудь специфический сценарий, который в реальности не нужен, и выстраивает всё вокруг него, то тяжело.

Для тестировщиков и РП мне лень писать. Иначе этот комментарий рискует превратиться в монографию. Хотя, блин, я не могу удержаться, знания переполняют меня, я на столько преисполнился понимаем этого мира, что просто не могу не поделиться своей мудростью (и наверное во многом болью) с человечеством (по крайней мере с той его частью, которая читает хабр).

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

Для РП на мой взгляд важно фокусироваться на приоритетах и сроках. Я считаю, что любая задача должна оцениваться по двум простым критериям: важность и сложность. В первую очередь делаются важные и простые задачи. Всё остальное делается потом. Я часто сталкивался с ситуациями когда в первую очередь по какой-то неведомой причине делаются самые ненужные и сложные задачи, а под конец в панике и срочно-срочно начинают делаться важные задачи и хорошо если простые, тогда есть шанс успеть хоть что-то. Хотя на мой взгляд этот навык важен не только для РП, но и для всех ИТшников.

Да, на самом деле, все эти навыки важны для всех ИТшников, просто каждый специализируется в первую очередь на своём.

4) Общие технические знания. Мне лень подробно на этом останавливаться. Но для всех не лишне иметь какое-то представление о базах данных и нормализации данных, о форматах данных (чтобы отличать XML от JSON), о протоколах передачи данных, многослойной архитектуре, API и т.д.

5) Специфические навыки, которые появляются с годами задрачивания чего-нибудь. Например, умение дебажить какой-нибудь лютый сторонний код. Когда ты видишь ошибку, понимаешь что она не в нашем коде, а в чужом фреймвоке и ты в отладчике проваливаешься на несколько десятков вызовов вглубь. И понимаешь, ага, понятно почему всё работает так, просто мы неправильно используем этот фреймвок. Или, ага, тут баг, нужно отправить им пуллреквест.

6) Знание конкретных языков и фреймвоков. С одной стороны, конечно если ты раньше использовал C# и Entiy Framework, а на проекте требуется Java и Hibernate с его безумными только запутывающими исключениями, то не получится сразу начать быстро работать, много времени будет уходить на копание во всём этом бессмысленном бреде. Но с другой стороны, я вообще не понимаю зачем на собеседованиях делать основной и единственный акцент на знании какой-то специфической хрени. Типа для JavaScript разработчика написать лапшу из промисов, setTimeout(), queueMicrotask() и спрашивать что будет. Да, инсульт ж...пы будет у любого нормального разработчика, если он увидит такое в коде!

Короче, к чему я всё это пишу. Возможно вам есть смысл ориентироваться не только на аналитиков, но на всех ИТшников. Те же вайтишники наверное не понимают почему так сложно найти работу, они же на курсах капец как прокачали 6-ой пункт, что ещё нужно. Да, блин, первые четыре пункта нужны хоть в каком-то виде. Без них человек может делать только домашки с курсов, когда тебе сначала подробно объяснили как это нужно сделать, показали примеры, и потом ты условно автозаменой превращаешь приложение для управления списком TODO в приложение со списком желаемых подарков на Новый год. Но в реальности задачи другие и даже для джуна недостаточно писать код по шаблону.

В общем это просто идея. Обычно анализ воспринимается как какая-то очень специфическая область деятельности и иногда даже недостойная для труЪ программистов. Но на мой взгляд без этого даже джуну тяжело работать, не говоря уже о росте до сеньоров, лидов, архитекторов. И в реальности эти навыки нужны всем ИТшникам.

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

Ещё смысл в том, чтобы сразу выявить и решить какие-нибудь проблемы. Чтобы люди не уходили в себя на неделю. У нас очень редкие митинги, когда все просто говорят "я всё сделал, занимаюсь тестированием" - такие митинги занимают 3 минуты. Часто люди говорят о проблемах, которые на митинге достаточно быстро решаются.

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

За 15 или в редких случаях 30 минут всё это вполне решается. А если два человека между собой начинают обсуждать какие-то детали, которые другим десяти людям на митинге непонятны и наверное не очень интересны, то лучше сразу предложить им обсудить это отдельно и не тратить время других людей.

Если есть какая-то общая проблема с качеством кода, типовыми ошибками, которые выявляются на ревью, ... и за 15 минут это не обсудить, то можно отдельную встречу сделать.

Нет, не догадываюсь :) А вы же догадываетесь, что нашей планетой управляют рептилоиды?.. Я думаю, что уровень пассивной агрессии и аргументации в моём комментарии вполне достаточен и соответствует вашему ;) Но мне всё-таки стало интересно, решил посмотреть статистику.

1,3 млрд. в месяц - это в среднем 30 тыс. запросов в секунду. В пике наверное бывает и больше. Можно сравнить с другими проектами (источники этой статистики не самые достоверные, но я и не научно-исследовательскую работу здесь провожу):

Google - 8,5 млрд. запросов в сутки или 6 млн. запросов в секунду

Яндекс - 1,6 млрд. запросов в сутки или 1 млн. запросов в секунду

Авито - 384 млн. наверное всё-таки просмотров, а не пользователей в месяц или 9 тыс. запросов в секунду

По сравнению с Google и Яндекс, да, не очень много, но у них и инфраструктура совершенно другого порядка. Кстати, интересно через какое количество микросервисов проходит каждый поисковый запрос, на сколько сложные там распределенные транзакции...

У Авито, на сколько я понимаю, как-раз всё на микросервисах. На 5:20 прикольный момент: если вы не хотите быть маленькой компанией, видите стратегический рост, хотите быть как Авито, то делайте труЪ микросервисы. Хотя цитата конечно вырвана из контекста, и наверное спикер не имел в виду, что всем срочно нужно переходить на микросервисы, а высказывался против shared database, но тем не менее прикольный момент.

Возвращаясь к исходной теме. Да, я считаю, что 30 тыс. запросов в секунду - это достаточно много. И подавляющему большинству проектов такая нагрузка даже близко не светит. Было бы интересно увидеть проект на труЪ микросервисах с распределенными транзакциями, Сагой и этим всем, у которого нагрузка выше. Возможно Amazon, но они пишут достаточно интересные статьи:

Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%

The move from a distributed microservices architecture to a monolith application helped achieve higher scale, resilience, and reduce costs.

разные части логики находятся в разных "монолитных приложениях"

У них не разные части логики запущены на разных серверах, там одинаковая логика. Просто stackoverflow самый крупный из их проектов, поэтому для него выделен отдельный сервер. Скорее всего, на втором сервере у них запущены десятки экземпляров этого же приложения (для каждого проекта - math.stackexchange.com, cs.stackexchange.com, ...). Но это всё монолиты, они особо не взаимодействуют между собой.

Например, мы делаем инструмент моделирования. Масштабируется он очень просто - для каждого заказчика или для каждого подразделения или даже для каждого большого репозитория моделей можно тупо запустить отдельный экземпляр приложения на отдельном сервере. Но это не делает архитектуру микросервисной. Обычный монолит. Одна и та же бизнес-логика просто реплицируется на множестве серверов. Вот, если дробить бизнес-логику на части: раздел моделирования, раздел анализа моделей, сервис генерации отчетов и т.д. и они как-то взаимодействуют между собой, то это уже можно назвать микросервисной архитектурой.

Более того, некоторые модули для части заказчиков не нужны. Их можно просто не включать в сборку. Т.е. разные экземпляры этого монолита могут включать разный набор модулей. А чтобы архитектура стала микросервисной нужно сделать очень простую вещь - каждый модуль должен запускаться отдельно. У нас много всего запускается отдельно - СУБД, Keycloak, Grafana и т.д., но это не модули приложения.

Иначе большинство приложений можно назвать микросервисными, практически везде есть СУБД, фронт и бэк запускаются отдельно, для аутентификации, мониторинга и т.д. тоже используются отдельные системы - но это тупо отдельные приложения с разным назначением, разрабатываемые разными компаниями.

На мой взгляд критерий микросервисной архитектуры очень простой - если данные, транзакции, пользовательские сценарии распределены по отдельно запущенным службам и чтобы всё это работало требуется координировать транзакции, то значит это микросервисы. А в stackoverflow все запросы обрабатываются одним монолитным приложением.

И вообще чем дольше я пишу этот комментарий, тем больше прихожу к тому что эта тема "монолит vs микросервисы" - просто высосанный из пальца маркетинговый булшит. Потому что не существует ни монолитов в чистом виде, ни микросервисов, в которых каждая функция запускается отдельно. У меня граница между этими двумя архитектурами проходит по наличию или отсутствию распределенных транзакций. Хотя и в монолитах они бывают.

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

Я думаю, что для монолита гораздо проще контролировать зависимости между модулями. Если каждый модуль - это отдельный проект, то зависимости между проектами явно прописаны. Уже в design-time видно что от чего зависит. Ещё можно всё это покрыть архитектурными тестами, чтобы проект просто не собирался при появлении лишних зависимостей. А для микросервисов фиг знает куда какие запросы они отправляют - нужно или запросы анализировать или код, так сходу за минуту не разберешься что от чего реально зависит.

Возможно для микросервиса заранее не знаешь где он будет использоваться и стараешься спроектировать хорошее API. Но то же самое верно и для модулей в монолите.

На мой взгляд, никаких микросервисов не существует, земля плоская, рептилоиды и масоны управляют нами, инопланетяне уже давно посещают нашу планету... Ой, ChatGPT выдал какую-то ересь на мой промпт, ну, ок, не буду удалять ради рофла. Короче, я думаю, что микросервисы - это тупо отдельные приложения со своим назначением, своей командой разработки и своими накладными расходами по интеграции всего этого.

Если у компании несколько автономных команд разработки, которые вольны в своих микросервисах делать что угодно, если есть ресурсы на интеграцию всего этого, то наверное микросервисы ок. А если команда разработки одна или если решения по используемым технологиям, по схеме данных и т.д. принимаются централизованно, то хз на сколько все эти накладные расходы на обеспечение целостности данных, на сопровождение этого дайверсити, использующего разные ЯП, СУБД и т.д. оправданы.

Это не микросервисы, а разные инстансы одного монолитного приложения.

Картинка оттуда:

На сколько я понимаю, у них одна база данных для stackoverflow + одна резервная. И одна база для всего остального + одна резервная. Это уже сомнительный подход по меркам микросервисной архитектуры. Redis, Elastic Search тоже не сделают монолитное приложение микросервисным, всё таки в них нет никакой бизнес-логики.

Монолитное приложение ведь не означает, что в нём должно быть всё реализовано с нуля и запускаться как одно приложение. Например, у нас на одном проекте приложение включает: фронт, бэк, БД, API gateway, Keycloak, БД Keycloak, Apache Directory, Prometheus, Grafana. Но это всё равно монолит. Скука лютая, здесь даже Сагу некуда прикрутить.

Всё-таки для микросервисов нужно именно бизнес-логику пилить на части. 1) Микросервис просмотра ответов на stackoverflow отправляет 2) в микросервис личного кабинета пользователей информацию о голосах за вопросы и ответы этого пользователя, 3) отправляет это в микросервис определения баджиков, 4) который в свою очередь отправляет информацию о баджиках в микросервис личного кабинета 5) если у вопроса слишком много голосов против, то отправляется запрос в микросервис анализа отрицательных оценок, 6) который отправляет запрос в микросервис модерации, 7) который отправляет запрос в микросервис подбора наиболее подходящих модераторов, 8) всё это отправляет запросы в микросервис рассылки push-уведомлений и 9) в микросервис рассылки уведомлений по email.

И всё по фэншую, каждый микросервис пилит отдельная команда. Если какие-то микросервисы отвалились, ну, остальные-то работают. Баджики, например, перестали отображаться или push-уведомления приходить, ну и фиг с ними, вопросы всё равно можно просматривать. Или те же базы данных, сейчас у них 4 жалких MS SQL сервера, два из которых резервные - это просто смешно. А могло бы быть штук 20 или 30 разных серверов! Монго там всякие и т.д. Это бред для всего приложения использовать одну СУБД. Хотя у них и не одна: Redis, видимо у Tag Engine и Elastic Search тоже свои базы. Значит не всё потеряно, хотя, блин, работай я в stackoverflow, чувствовал бы свои права ущемленными, я думаю, что для многих задач графовая база данных или Монго зашли бы гораздо лучше, или допустим я в файлах хочу хранить какие-нибудь вещи. Хмм... эти данные могут понадобиться кому-нибудь ещё за пределами моего микросервиса? - Ну напишу им апишечку для доступа к этим данным, в чем проблема, какая им разница как они у меня хранятся. У данных странная структура и они вообще не бьются с данными в других микросервисах? - Ну, во-первых, Сага должна была гарантировать целостность данных, во-вторых, что мешает создать отдел базистов, пусть пишут ETL-процедуры, мне удобнее хранить данные в графовой базе, почему я должен подстраиваться под разработчиков из других команд. И вообще мне нужно фичи поставлять в прод, а не схему данных согласовывать.

Если учесть что у них там ещё всякие компании, вакансии, какие-то команды, дискуссии, опросы, рекомендации похожих ответов и т.д. ну блин, ладно не стали делать полсотни микросервисов, но штук 5 можно было сделать хотя бы ради дайверсити, аджалити, скейлабилити?!! Это в принципе не такое маленькое приложение как выглядит на первый взгляд. Можно было бы создать столько независимых команд разработки, такую инфраструктуру развернуть! А текущая инфраструктура вызывает просто смех.

Потому что все заказчики спят и видят что если год назад у них был 1 пользователь, а сейчас 100, то через год будет 10к, а через два 1М. И требуют масштабируемое решение.

Есть один проект с миллиардом просмотров в месяц. Похоже его создатели всё это время были в анабиозе и не слышали про микросервисы. А если бы добавили хотя бы десяток-другой микросервисов, сагу и это всё, то наверное вообще всё летало бы.

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

"У меня все всегда хорошо. Следующий"

Это 10 секунд на человека, 2 минуты всего. А за 15 минут вполне можно решить большую часть проблем.

А если у коллег вопрос возник?

Обычно вопрос к 1-2 людям, они вполне могут собраться отдельно обсудить.

Даже 15 минут на 12 человек - это 180 минут = 3 человеко-часа. Если полчаса посидеть, то это уже 6 часов - почти рабочий день. Я думаю, что частые долгие митинги на большое количество человек - зло. Чем больше людей, тем быстрее должен быть митинг или тем реже.

Мне сложно придумать такой пример. Если это только что-то связанное с гостайной, какими-то ноу-хау или чем-то не очень законным. Я ни разу не встречал таких людей. В любом случае я думаю, что нет никакого секрета в том как на проекте был организован процесс разработки, были ли аналитики, тестировщики, как велась работа с ветками в Git, как декомпозировались задачи, на сколько сложным было приложение (сколько сущностей в схеме данных, сервисов, модулей и т.д.), как была реализована аутентификация, авторизация и куча других технически вопросов, на которые вполне можно ответить, не раскрывая секретов. Или просто отказаться отвечать, это вообще не проблема.

Лично я думаю, что лайвкодинг используется в следующих ситуациях:

  1. Если в компании очень большой поток кандидатов и нужно максимально просто и эффективно их отсеивать. Если отсеяли хорошего кандидата, ну, ничего страшного, завтра будет ещё десяток.

  2. Если у самого интервьюера небольшой опыт или вообще нет опыта и он не может оценить кандидата, просто беседуя с ним.

  3. Если собеседование на джуниорскую позицию без опыта.

  4. Если нет времени, сил, желания запариваться с интервью, то гораздо проще дать очередному кандидату очередную задачку, чем думать, напрягаться, задавать какие-то вопросы.

  5. Если хочется сделать интервью максимально объективным. Решил задачу за полчаса - ставим плюсик. Успел оптимизировать алгоритм - ставим два плюсика. Не сделал задачу - ставим минусик. В итоге суммируем оценки и превращаем кандидата в число. Сортируем этот массив, получаем N лучших кандидатов, делаем им оффер. Хотя у меня есть смутное ощущение, что при этом упускается что-то важное. У каждого кандидата свой уникальный опыт, свои уникальные качества, которые в итоговую сумму не попали, потому что мы даже не спрашивали соискателя о его проектах, интересах.

Вообще я наверное не против лайвкодинга и сам время от времени решаю какие-то задачки, что-то изучаю. И алгоритмическая секция наверное не сильно оскорбила бы мои чувства :) Но на текущем проекте я вообще не вижу никакого смысла давать людям алгоритмические задачи, для меня важнее на сколько человек может работать самостоятельно, декомпозировать сложные задачи, соотносить важность фичи и сложность её реализации, писать понятный код, который потом не нужно переписывать, что-то обсуждать, если задачу непонятно как делать или есть много вариантов решения.

И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше, как готовил поверхность, какие электроды использовал, какое оборудование, что если был нужен широкий или длинный шов (он варил их в один проход или в несколько), просто вел электродом по прямой или зигзагом, какая была техника безопасности, варил ли он швы в каких-то сложных условиях (на трубе под большим давлением, на большой высоте, в замкнутом помещении, в угольной шахте, ... - если такое требуется на объекте), как проверял качество шва, бывало ли такое что он сварил шов, а потом всё развалилось нафиг. Причём на эти вопросы нет правильного и неправильного ответа. Они просто показывают на сколько человек погружен в эту тему или хочет в неё погружаться.

Практические задачи - это наверное тоже хорошо. Но, блин, всё-таки между ИТ и сваркой есть разница. Сварщик на работе будет реально варить швы и если он не смог сварить тестовый шов, наверное не сможет сварить и реальный - возможно они не сильно отличаются.

А в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего. Алгоритмические задачи просто проверяют как человек готовился к интервью. Если не готовился, то он его не пройдет, каким бы гением разработки он ни был. А если готовился, то скорее всего пройдёт независимо от того на сколько отстойный он разработчик. И вопрос нафига такое интервью вообще, что оно проверяет? Знание алгоритмов - это безусловно бонус, возможно более полезный чем знание английского на уровне upper-intermediate, умение вышивать крестиком, водительские права категории Б и т.д. И я считаю, что разработчикам очень полезно прокачиваться в алгоритмах. Но это никак не основной скилл разработчика.

Информация

В рейтинге
970-й
Зарегистрирован
Активность