Pull to refresh
2
0.2
Дмитрий @LbISS

Руководитель отдела разработки .net

Send message

Как страшно жить! Понимаешь, не выбрасывают функции! Всё легаси! Раздутый функционал!

А вот не так однозначно. Обратная совместимость у Windows за счёт этого сильно лучше. Не, если поставить голый Центось и с него отдавать статику в инет - спору нет, Центось будет в сотни раз стабильнее. Но вот на реальной домашней системе с кучей разностороннего железа и софта... Обновил Винду с 10 до 11-ой - что отломалось? Ничего. ВСЁ работает.

Обновил Убунту с 20.хх до 22.хх. ОпенВПН перестал работать? Почему? Похерили обратную совместимость - зайди в репозиторий, поправь пару строчек, пересобери либу. Внешняя аудиокарта в Сонаре перестала нормально выводить звук, появился лаг. Почему? Потому. Зайди, скачай, поправь пару строчек, пересобери дрова. Миди клава? Домашний кинотеатр 7.1 через HDMI и + 2 доп. вывода звука? Циско? Шаринг видео в Тимс? Ну вы поняли. Зайди, найди проблему, скачай исходники, поправь, пересобери. А ещё есть и минорные обновления ОС почаще...

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

Сейчас в компании наблюдаю похожий процесс. Только тут нет выделенных аналитиков, вместо них в данном процессе выступает тимлид или делегированный на фичу разработчик. У них достаточно экспертизы, чтобы сказать "это вот надо делать не так, а иначе". В итоге процесс выглядит так:

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

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

В конце собираются ещё раз опять, уже с точными мокапами, вносят минорные правки, если ещё есть и мокапы уходят в работу.

Многое, что делали с языком после С#6-7 - это порча хорошего и стройного языка и превращение его в джаваскрипт. Жабаскрипт такой только по историческим причинам, а тут сознательно портят язык.

Для верхнеуровневых языков скорость разработки зависит не от количества синтаксического сахара или того, пишешь ты конструктор за 30 символов или за 40, а от простоты и наглядности кода, возможностей выражать понятия доменной модели в коде наиболее близким способом, не увеличения, а лимитирования способов сделать одно и то же, ограничения возможностей "писать, что попало" и структурирование всего кода в определённые рамки, близость к натуральным языкам ддя простоты понятия и оперирования...

Основной тех. долг, который несёт косты для бизнеса это ошибки в проектировании доменной модели, макаронный код, проблемы времени жизни объектов и т.п., а не лишняя строка для определения пропсы.

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

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

И это класс. Если мне надо поставить одну аватарку, я не хочу чтобы приложение имело доступ ко всему архиву home video и пересланных в переписках файлов.

Лучше, но на сервере можно себе позволить загрузить две либы разных версий в память. А вот на фронте - это уже совсем другие расходы - сеть, объём кэша, cpu на парсинг - всё это сильно дороже. Оттуда и вылез этот ужасный формат семантической версионности с кучей проблем совместимости - из попыток не грузить одинаковые подзависимости.

Очередной "визионер" вида "все кругом тупые, всё общество заблуждается, а вот я сейчас расскажу как правильно". Вот прям все миллионы сидят, работают годами в области, развиваются, учатся и не понимают очевидной вещи, их очень надо просветить.

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

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

Почему фреймворки весят мегабайты и гигабайты, не задумывались? Потому что это не то, что надо экономить. Всем пофиг, жрёт ли фреймворк 10кб на машине разработчика или 10гб. Аналогично, с текущим каналом в большинстве своём на массовых задачах всем примерно пофиг, весит web-CRM (вы как раз упоминали веб приложения) 10кб или 100кб. А то, что является проблемой - это когнитивная сложность поддержки, стабильность и скорость внедрения фичей. И вот эту проблему решают фреймворки. По вашему подходу вы можете набрать команду из сплошных Principal Engineer-s и она прекрасно будет его держать. Остальные повалятся. А на проект на фреймворке можно посадить кучу мидлов и одного принципала и они будут в 3 раза дешевле, в 20 раз проще в найме и менеджменте и делать то же самое со скоростью 80%. И потом пересадить на соседний проект на том же фреймворке и они продолжат с такой же скоростью, без необходимости онбординга в полгода. И да, у каждого будет SSD на терабайт под фреймворки, это всё равно дешевле.

Вы гугол или нанимаете джунов? Где тот эльдорадо, откуда берутся 15 крепких профи в день на рядовую должность?

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

По итогу на следующем этапе имеем как минимум двух человек, округляющих глаза друг на друга

Терпеть не могу хайринг на аутсорсе. Было такое на прошлой неделе, кстати. Я обычно первые 7-8 минут трачу, чтобы рассказать о проекте, чтобы человек понимал, почему дальше будут те или иные вопросы. Рассказываю, вижу чем дальше, тем больше недоумения в глазах. Спрашиваю - что не так? Выясняется, что человек ищет вакансию только под Ангуляр и ничего больше не рассматривает, а у нас Ангуляр ни на одном из 150 проектов не используется и в описании вакансии не упоминается. Извинился, разошлись. HR объяснить мне, где у него голова, так и не смог. Видимо её нет.

Зачем задавать вопрос «что такое цикл» человеку с десяткой лет профильного опыта?

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

Отвечая на вопрос "заяем задавать базовые вопросы?". Потому что у кандидата 10 лет может быть в смежном стеке, а написать в cv он забыл. Потому что, может быть он занимался однотипными задачами и знает только один фреймворк, а на любой вопрос про базовое строение языка плывёт. Потому что он 10 лет сидел и занимался одним и тем же или просто его работа в компании не была никому интересна и он не развивался. Потому что резюме может быть в конце-концов чужим (было и такое в практике). Поэтому базовые навыки проверяются всегда. Знаешь - молодец, потратили на это 5 минут, пошли дальше. Опять же, случай из недавних, у человека 11 лет опыта, причём по резюме выглядит солидно. Но ответы на вопросы про процессы или архитектуру - ноль (ответы вида "я не знаю") и при попытке посмотреть навыки кодинга человек не может написать нормально перебор коллекции. Неожиданно, но бывает и такое.

Но если типовую задачку для оценки навыка кодинга нельзя заменить парой актуальных и живых репозиториев из github кандидата – это опять звоночек про гибкость процессов.

Во-первых, мы опять же не знаем историю появления этого репозитория - чужой он, свой, написан самим человеком или с помощью, всё равно придётся по нему разговаривать. Поэтому оффлайн это не заменит. Во-вторых, оффлайн задача это проверка умения работать самостоятельно - вот тебе гугл, вот задача, которой нет в гугле в прямом виде, составь из всех производных нужное решение. Если человек в оффлайн не способен решить базовые задачи - нагуглить и синтезировать - то как он будет дальше работать? В-третьих, это экономия времени нанимающего (да, извините, это так). Чтобы просто открыть репо- нужно 5 минут, да. За них вы успеет увидеть кодстайл конкретного одного проекта и всё. А вот чтобы сделать выводы о качестве решения, нужно будет перешерстить несколько репо (обычно шлют ещё и несколько ссылок), найти более-менее сложный, разобраться в задаче, которую решает это приложение, понять архитектурные решение, прикинуть узкие места, пройтись по коду, найти эти узкие места, понять как человек это решил, наметить вопросы... Полчаса на репо. А у тебя 15 таких резюме в день, и в каждом n репосов. Сорри, но нереально.

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

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

Мне одному Composition Api кажется порочной технологией?

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

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

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

Собственно да. По сути это тот же монолит, но гораздо легче масштабируется и решает большую часть проблем. Интересно, увидим ли в "микросервисном" подходе кучу квадратов 200*200 разделённых железкой, что является вторым типичным масштабируемым решением.

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

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

Мне кажется одна из больших "болей" в микросервисах - это версионирование, жаль, что в статье это не затронули. По rest уже есть некие стандартные приёмы, библиотеки, типа делаешь /v2/ и дальше двухшаговая миграция. А как это работает с gRPC и protobuf? Есть какой-то стандарт, что делать с контрактом при необходимости сделать несовместимые изменения? Просто генерим второй контракт и дублируем все затронутые классы? Есть ли набор ошибок передающих статус deprecated?

Blazor wasm сразу вызывает 2 опасения - 1) как на это искать людей 2) как это диагностировать, если что-то отвалилось вне девелоперской сети. Всё в бинарке и wasm, и код - и запросы.

А так, конечно, всегда соблазнительно вместо js перетянуть какой-то "более правильный" язык на фронт.

Согласен. Отвечать таким образом, как представитель компании рекруту - нельзя. Но по сути правда.

Код весь выполнен в угоду микрооптимизациям. Такое оправдано в нескольких случаях: у вас стомиллионов RPS на функцию и она плохо масштабируется горизонтально или же вы программируете микроконтроллеры и у вас 20кб памяти (условно).

Более того, если у вас такой кейс скорее всего у вас инструментом будет не c#. А в прикладных задачах в миллионы раз ценней читаемость и структурность кода (т.е. экономия времени разработчиков), чем микро- и не очень оптимизации. Этот код может быть короче минимум в три раза с явно выделенным семантическими блоками, без повторения и адского ветвления.

Я думаю это просто разница ожиданий. Автор задания плюхнул про оптимизацию имея в виду "юзай стрингбилдер и не делай 20 классов". А кандидат услышал "выжми из этого кода всё, что можно". Бывает.

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

Total Anihilation — лучшая игра 97 года по версии Е3… Или уже только на винду?

Ох какой песец… Как вы читали Голдратта если потом пытаетесь "увеличить коэффициент использования энергии" в общем, хотя до этого говорили что метод "бутылочного горлышка" состоит как раз в противоположном — улучшение малыми затратами одного места, а не попыток улучшить везде и всё?
Заголовок — желтуха, как вот эта хрень связана с agile и lean вообще непонятно. Изобрели очередное громкое слово для недоруководителей.
Что потом подкрепляется словами "Нет необходимости «внедрения методологии и философии»". Т.е. вы натянули рефлексы собаки Павлова на человека и утверждаете что решили все проблемы, моментально, без побочных эффектов и без необходимости помочь и научить людей думать по-другому? Трешачок.

Information

Rating
2,091-st
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity