Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

А ти точно senior?

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному12
LinkedIn

Найкращі коментарі пропустити

Это какой-то бред честно говоря.
Это не сеньйор получится а какой-то супер-фул-стек. Чего только стоит требование понимания ограничения РАЗНЫХ баз данных. Вы еще напишите «всех».
Это скорее таблица как завалить любого кандидата. Мне не попадалися даже техлиды хотя бы с половиной требований.

Отак все і є. Спочатку одні складають таблички, а потім інші лікують синдром самозванця.)

НА САМОМ ДЕЛЕ, senior — это человек, который обладает адекватным опытом, более-менее знаком с доменной областью, и базируясь на этом, может самостоятельно проанализировать бизнес-проблему, адекватно оценить время на ее решение, и решить ее в срок согласно своей оценке с приемлемым качеством кода, на уровне обычного middle-программиста. Все.

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

Вспоминается фрагмент (примерно) из цикла «Молот и Крест» Гарри Гаррисона:

— что надо сделать чтобы стать королем?
— стань в центре каждого селения и объяви себя королем. Если ты обойдешь так всю страну и выживешь то, стало быть, ты и есть король.

Если ты прошел на синьора и другие синьоры считают тебя синьором и тебе платят как синьору, то ты и есть синьор.

слишком много обмазывания паттернами в пункте про архитектуру
хороший коммент по этому поводу с другого дев ресурса на похожую тему -

«Паттерны Головного Мозга.
Ситуация когда субъект воспринимает рисунок из стрелочек и прямоугольничков, как дарованное с небес откровение о мироустройстве. И пользуясь напильником и топором пытается впихнуть любую ситуацию в рамки одной или нескольких таких картинок, забывая об особенностях предметной области и уже существующей кодовой базы.»

отсюда выплывают абстрактные фабрики для создания абстрактных фабрик, адаптеры для фасада адаптеров, 20 классов на 2 строки только из-за того чтобы быть по солиду и прочие извращения, проверять способности в архитектуру по кол-ву заученных паттернов и знанию магических аббревиатур это совок

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Senior может, senior может все, что угодно...

Пересмотрпел буквально только что внутренний документ Engineering Career Ladder американской продуктовой конторы, где работаю контрактором. Вспомнил эту табличку, также хабровскую, и её абсурдность относительно американского документа.

Если вкратце, то во внутреннем документе есть Engineer R1, Engineer R2, Senior Engineer R1, Senior Engineer R2. Также есть длинный список компетенций, сгруппированных по типам: технические, коммуникационные и лидерские. Нет там 80%-90% содержания таблицы выше, типа знает и как хорошо знает ту или иную технологию, знание/выбор алгоритмов, структур данных, сложностей O-нотации. Таблица выше — она скорее про фаллометрию и академические, в лучшем случае — поверхностные технические знания/навыки, как быстро и по дешёвке сляпать одноразовый заказ внешнему заказчику, для которого ПО — это статья затрат.

так на хабре ж вроде высер похожий был

Очень субъективная табличка, в колонке синьора больше похоже на изложение всего что автор знает, не удивлюсь если из резюме :)

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

Чему должен соответствовать синьор с точки зрения индустрии в целом и собственного кодекса воина это более интересный вопрос. Можно разделить на затасканое понятие soft skills и hard skills.

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

Из технических навыков, писать простой, эффективный и поддерживамемый код. Автоматизировать все что можно автоматизировать и тестировать end to end. Быть ответственным за работоспособность своего кода 24/7/365 в продакшине и быстро реагировать на дефекты и изменения спецификаций в процессе эксплуатации.

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

понимать доменную область

Какого именно домена?

Бизнесс домена. Для booking.com — hospitality, для Twilio — телеком и конверсионный маркетинг. В зависимости от того какому бизнесу помогаете нужно работать с экспертами в этой области и понимать как рационально решать задачи в данном секторе

Если я за год успеваю поработать с 2-3 доменными областями, мне нужно разбираться в каждой?
И чем отличается специфика решения задачи по разработки мобильного приложения для hospitality от приложения для конверсионного маркетинга, если и там и там приложение будет представлять собой по сути юай, REST и опционально, локальные базы?

Если я за год успеваю поработать с 2-3 доменными областями, мне нужно разбираться в каждой?

вы ж мобильщик. и спрашивали уже. уже объясняли вам, что
у вас там, если верить — выше мидла по таким таблицам компетенций и критериям — не вырасти.

Серьёзно?
А мой тайтл не смущает?
Или может, критерии сениорности для веба не нужно натягивать на всё остальное?
Программист — это технический специалист. Что и как он должен делать — описывается в юзер-стори и спецификациях. Если чего-то из этого нет, или там неполная информация и кому-то приходится носить знание в голове — менеджмент нужно просто уволить, он не умеет организовывать процесс разработки.

А мой тайтл не смущает?

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

как думает человек, что знает — это важно.
а тайтлы в конкретной компании то такое.

Программист — это технический специалист

у всех специалистов, в любой области существует градация

Что и как он должен делать — описывается в юзер-стори и спецификациях

а чем отличается джуниор, мидл и синьор — описано во тьме источников.

я и другие вам об этом писали стопицот раз.

вы — классический, хрестомайтиный мидл.
и что там у вас в компании с тайтлами — пусть хоть генералисимуса дадут — дело десятое.

менеджмент нужно просто уволить

увольняйте, кто ж запрещает?

ничуть. я не учитываю тайтлы. как и опыт работы в годах, и т.п.

Я тоже. Но гонять на собеседовании человека по предметной области бизнеса — это сюр. Нет?

и что там у вас в компании с тайтлами — пусть хоть генералисимуса дадут — дело десятое.

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

увольняйте, кто ж запрещает?

Уволить их может только вышестоящее начальство. Я же предпочитаю с ними просто не работать. На любом собеседовании подробно распрашиваю о процессах разработки всегда.

Но гонять на собеседовании человека по предметной области бизнеса — это сюр. Нет?

если на синьорскую позицию — то норм.

на мидловую да, незачем.

мобильщика, как понял от вас — тоже незачем.
да и брать в штат особо незачем. временщик, контрактор — достаточно.

Да как бы, это в большинстве компаний так.

в большинстве аутсорсовых компаний — может быть.
там и просто кодерам мидлов раздают.

Я же предпочитаю с ними просто не работать

не работайте, ваше право :)

На любом собеседовании подробно распрашиваю о процессах разработки всегда

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

если на синьорскую позицию — то норм

А если никто из команды не работал в его предметной области?

да и брать в штат особо незачем. временщик, контрактор — достаточно.

В штат? В Украине?
Все давно работают по контракту по ФОП, не только мобильщики.

в большинстве аутсорсовых компаний — может быть.

Кстати, 2 из 3-х офферов, полученных мной на прошлой неделе — из продуктов. Один из них даже принял.

в маленький минус записываю

Маленький?
По-моему, это много чего о кандидате говорит. Я бы такого не аппрувнул.

Про ФОП забавно :) вы ещё скажите что не в курсе что этот вид регистрации по факту — принятие в штат в Украине :)

Остальное — честно, утомили. Вам уже все давно объяснили.

вы ещё скажите что не в курсе что этот вид регистрации по факту — принятие в штат в Украине :)

Ну в таком случае, я последние лет 7 работаю исключительно «в штате». Кстати, при переезде от прошлой галеры в США я там вполне формально в штате числился. И официальную зарплату получал.

Я тоже. Но гонять на собеседовании человека по предметной области бизнеса — это сюр. Нет?

Не то чтобы прям гонять.

Просто когда я слышу в ответ на свой вопрос на собеседовании «расскажите про свой проект и что вы именно делали» — ответ «ну делали работу. ставили там таски и я их делал», у меня сразу складывается соответствующее мнение о человеке, причем далеко не в лучшую сторону.

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

ответ «ну делали работу. ставили там таски и я их делал», у меня сразу складывается соответствующее мнение о человеке, причем далеко не в лучшую сторону.

да у всех такая реакция :)
но у чела проблема ж — он мобильщик, им и не дают ничего кроме как сделать буква в букву.

мы разрабатывали модуль оценки кредитных рисков.

он не разрабатывал этот модуль :)
он по спеке написал UI к ендпойнтам. и все.
примерно как приглашают верстальщика на месяцок — никакого модуля он не разрабатывал.

я себе на будущее «записал» — мобильщики — вне правил, у них такая специфика.

Мне кажется, то, о чём пишет Семухин — справедливо для временного контрактора или аутстаффа. Аутстаффера пригласили в команду заказчика — но он там на младших ролях и ничего по сути не решает выше кодерских задач. На то и нанимали контрактора — загружать рутинными задачами.

А то, что выше обсуждается по предметной области — очень похоже на продуктовую разработку на многолетнем проекте. Или чем-то вроде сопровождения типовой конфигурации 1С:Предприятие.

Я ожидаю услышать минимально два-три коротких предложения вида «мы разрабатывали модуль оценки кредитных рисков. моя команда отвечала за интеграцию с бюро кредитных историй для ... XXX »

Это о проекте, а не о предметной области.
Вот если бы вы его начали по экономической теории гонять — вот это проверка знаний в доменной области.

ответ «ну делали работу. ставили там таски и я их делал»

Это уже сюр. То есть, человек даже не понимал, что и зачем делает?:)

Это уже сюр. То есть, человек даже не понимал, что и зачем делает?:)

Ты не поверишь ... Встречал процентов 20-25, когда активно занимался собеседованиями, еще в Украине. Вроде и резюме адекватное, и опыта вроде как лет 5-7-10, но вот такое вот ...

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

Это вы себе понапридумали :)

А знания домена подразумевают совсем не это.

Но вы да, продолжайте догадываться что они означают :)

Мобильная разработка это специфика. Но даже для мобильного приложения имеет смысл понимать что такое Ubiquitous Language, Bounded Contexts и т.п., если вы конечно создаете что-то более сложное чем визитки. Не все приложения живут в вакууме, а как часть/расширение некоторой платформы. Шарить между другими слоями/компонентами/системами общие конвеншны и схемы БД для консистенси нормальная практика. Конечно, больше это все имеет смысл для бэк-енд разработчиков. Например вышеперечисленные компании это платформы с кучей кастомеров. Чтобы эффективно решать их задачи нужно понимать их проблемы и как трансформировать их в конкурентные преимущества.

понимать что такое Ubiquitous Language, Bounded Contexts и т.п., если вы конечно создаете что-то более сложное чем визитки. Не все приложения живут в вакууме, а как часть/расширение некоторой платформы. Шарить между другими слоями/компонентами/системами общие конвеншны и схемы БД для консистенси нормальная практика.

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

Не только данные, важен и codebase: как именуете нэймспейсы, модели, компоненты. Как структурируете солюшн и описываете поведение и т.д. Я не говорю про детальное понимание предметной области, но нужно иметь представление в общих чертах о сущностях и контексте, чтобы не быть оторванным от остальных разработчиков (UI, back-end) и чтобы все были на одной волне

Если тебе не надо знать домен, то ты явно в серьезных проектах на позиции выше слабого сидела не был. Вообще 2 проекта за год звучит как клепание туду листов

Вообще 2 проекта за год звучит как клепание туду листов

он мобильщик, он и 12 в год может — по месяцу на один клиент, аля туду лист.

даже самый самый крудошлеп делает более сложные UI
кому придет в голову запихивать грид с фильтрами, в мобилку?
формат экрана не подразумевает сложной работы с данными.

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

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

Вообще 2 проекта за год звучит как клепание туду листов

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

1 человек и полгода работы? Боюсь у нас разные понятия слова полнофункциональный

Боюсь у нас разные понятия слова полнофункциональный

Какого функционала, по вашему мнению, там не было? Например?

полнофункциональный интернет-магазин на мобильной платформе

Що це таке розшифруєш? Про яку функціональність йдеться та на якій мобільній платформі.

Про яку функціональність йдеться та на якій мобільній платформі.

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

Це ж просто мобільний клієнт. Чи ти дійсно віриш, що магазин реалізовано як андроїд додаток і він працює у когось на телефоні? І якщо вимкнути телефон то магазин припинить працювати — так ти собі уявляєш як інтернет-магазини працюють?

Це ж просто мобільний клієнт.

Да. И что?
Сервер без клиента нафиг никому не нужен.

Да. И что?

А те, що на андроїді не магазин, а клієнт для сервісу магазину. Тобто те що ти написав вище

полнофункциональный интернет-магазин на мобильной платформе

просто невірно.

А те, що на андроїді не магазин

Все операции делал Андроид-клиент.
Сервер просто хранил их результаты.

Нет, сервер был. Но всё взаимодействие с ним было разбито на элементарные операции. Типа «добавить товар в корзину», «получить текущую корзину», «получить текущую сумму корзины». Эти 3 операции нужно было выполнить для добавления товара в корзину, например. И так — каждое действие пользователя — набор операций по получению-обновлению и т.п.
Сам сервер просто предоставлял круды для разных сущностей. Не фаербейс (тогда его ещё не было), но нечто похожее.

ведь его как-то наполняют, у него есть какая-то админка

Которая могла только наполнять контент.

главный модуль — это сервер.

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

полнофункциональный гемблинг сервис

Сервис — это то, что на сервере. Ты делал — мобильный клиент. «Толщина» этого клиента — штука, которая может сильно варьироваться. В приложении может быть как довольно много логики, так и вообще не быть. В ставках на спорт основное происходит за пределами приложения, телефон там не является источником основных значимых для бизнеса событий. Кроме, разве что, ставок.
В интернет магазине пользователь делает натурально всё — просматривает товар, ищет товар, добавляет товар в корзину, убирает его из корзины, процессит заказ. Сервер только возвращает ему запрошенные данные и сохраняет его данные в нужных таблицах. Плюс, делает рутинную работу, которая не касается приложения — типа бухгалтерии и просчёта скидок.

Т.е. сервер не решает что именно показать этому клиенту, какие товары (на основе его предпочтений)?

Нет, отдавал товары скопом по категориям и сабкатегориям.

Какие предложить скидки и специальные предложения для этого клиента?

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

Не выставляет скидку автоматически

По-моему там была скидка начиная с определённого количества единиц некоторых товаров.

Не хранит платежные данные, nonce от кредитных карт?

Да, тут он работал как база. Хранил.

В интернет магазине пользователь делает натурально всё — просматривает товар, ищет товар

Абсолютно усі товари з сервера завантажені на клієнт?

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

Це дуже показове нерозуміння того як працюють інтернет-покупки та інтернет-магазини.

Абсолютно усі товари з сервера завантажені на клієнт?

Из запрошенной категории.

Це дуже показове нерозуміння того як працюють інтернет-покупки та інтернет-магазини.

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

Из запрошенной категории.

Навіть у категорії це може бути така кількість даних яка буде переватися мінімум кілька хвилин та не влізе у пам’ять мобільного пристрою.

Как работает мобильный клиент интернет-магазина я знаю

Ну так я і кажу, що це клієнт, а не магазин сам по собі. Магазин реалізовано на сервері, клієнт просто дає спобіб його використання.

Навіть у категорії це може бути така кількість даних яка буде переватися мінімум кілька хвилин та не влізе у пам’ять мобільного пристрою.

Только если это что-то типа Амазона.
Локальный магазин выпивки просто не имеет такого ассортимента.

Ну так я і кажу, що це клієнт, а не магазин сам по собі

Ну ясен пень, что не телефон сам у себя покупает. База товаров, пользователей, заказов, хранятся «в облаке».

Ну ясен пень, что не телефон сам у себя покупает. База товаров, пользователей, заказов, хранятся «в облаке».

Магазин реалізовано в клауді, на телефоні клієнт для нього. Усе те що робить магазин магазином (каталог, ціни, знижки, акції, купони, екаунти користувачів, методи оплати та те що потрібно для роботи платіжних систем, сама реалізація оплати, повернення і відіна замовлень, підписки і так далі) — все це на сервері. Клієнт на мобільному телеофні абстрагує користувача від цього надаючи йому зручний UI та спрощені споби ініціювати покупку та оплатити її.

Клієнт на мобільному телеофні абстрагує користувача від цього надаючи йому зручний UI та спрощені споби ініціювати покупку та оплатити її.

И что?

І те, що на смартфоні клієнт інтернет-магазину, а не сам інтернет-магазин.

Те що ось це

полнофункциональный интернет-магазин на мобильной платформе

просто неправда.

просто неправда

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

Локальный магазин выпивки просто не имеет такого ассортимента.

а кто, откуда берет эту выпивку чтобы ваш полнофункциональный магазин позволил ее — купить?

А на каком поле выращивают пшеницу, с которой то бухло в гонят? Меня это должно волновать?:)

все уже все поняли — тебе платят твои 4,5к, тебе от этого хорошо — будь счастлив и не парься

никто ничего никому не должен

вы тоже. поэтому можете и дальше смело рассказывать про то как вы делали «полнофункциональный эл магазин»

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

как у них там бизнес построен — вообще не моё дело.

понятно.

но вы уверенно при этом заявляете что вы делали

полнофункциональный интернет-магазин на мобильной платформе

?

как вы могли его сделать, если это «вообще не моё дело»?

выбор товаров и корзину сделали нативным клиентом?
да, великое дело, любой вменяемый фрилансер на аджаксе, сверстает для мобильного устройства.

Коментар порушує правила спільноти і видалений модераторами.

и сохраняет его данные в нужных таблицах

как обеспечивается защита от читерства?

всё — просматривает товар

сколько характеристик у товара?
кто контролирует эти наборы характеристик?

процессит заказ

пользователь оплатил — кто контролирует что он оплатил?
кто контролирует что деньги пришли?
кто контролирует что товар на момент их прихода — есть?
кто формирует команды на их отгрузку?
кто контролирует этапы доставки?

делает рутинную работу, которая не касается приложения

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

так что продавали — доступ на просмотр контента?

типа бухгалтерии

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

Если в первичке вранье — то бухгалтерия бессмысленна.
И собственно требования к хранению байтиков в таблицах когда

Сервер только ... сохраняет его данные в нужных таблицах.

вызваны как раз требованиями бухгалтерии, которая не сможет потом выполнять свои функции.

так что продавали то?

Все операции делал Андроид-клиент.

Це був би найдурніший дизайн інтернет-магазину в світі.

Сервер просто хранил их результаты.

Тобто сервер — це просто БД?

Швидкість імплементації POC — так, це є. Але дуже швидко такий клієнт загнеться під вагою каталогу, методів оплати та їх комбінацій, відмін і повернень покупок, скидок, підписок, купонів/ваучерів. Крім того необхідність ледь не щогодини заливати оновлення на клієнт повність паралізують додавання нового функціоналу та виправлень. Ще й необхідність дублювати все це в інших клієнтах (нативних, веб, на смарт-телевізорах і так далі).

Це був би найдурніший дизайн інтернет-магазину в світі.

Почему?

Тобто сервер — це просто БД?

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

Почему?

Тому що робити web-клієнта для того ж магазину — писати все заново ще раз. І нативний клієн — знову заново писати той самий «магазин». І якісь суттєві зміни робити у всіх варіаціях клієнтів і запихувати їх на усі пристрої одночасно.

Плюс ще якесь API, варіації для різних ринків, виправлення критичних багів і таке інше.

На нём была логика финансовых транзакций

Я не знаю, що це словосполучення означає.

логика предоставления скидок

Ох, тобто щоб отримувати скидки треба було поковирятися у додатку на пристрої? Оце так дизайн!

логика подсчёта тотала корзины

Це що за «логіка» — сумування цін за товарит в корзині?

Як щодо способів оплати (метод, тип, валюта) — все це на девайсі? Як працює відміна покупки, refund та повернення — теж реалізовано у клієнті?

Бо з таким «дизайном» нічого не заважає повертати сотні одиниць не купленого товару.

І якісь суттєві зміни робити у всіх варіаціях клієнтів і запихувати їх на усі пристрої одночасно.

Так захотел заказчик, меня мало беспокоят связанные с этим его проблемы.

Плюс ще якесь API, варіації для різних ринків

В Андроиде есть локализация. В разных странах приложение можно заставить работать совершенно по-разному.

Я не знаю, що це словосполучення означає.

На сервер отправлялся запрос с заказом в боди. Что он с ним дальше делал — как выставлял счёт, как процессил доставку на заданный адрес — я вообще без понятия.

Як щодо способів оплати (метод, тип, валюта) — все це на девайсі? Як працює відміна покупки, refund та повернення — теж реалізовано у клієнті?

Ничего этого не было на устройстве.

Как работает мобильный клиент интернет-магазина я знаю

Теоретично таке можливо, але в реальності навряд чи хто буде вкладатися в подібне не залучивши експертів. Більш імовірно, що ти просто не знаєш як воно реалізовано.

В Андроиде есть локализация. В разных странах приложение можно заставить работать совершенно по-разному.

В одному додатку мати усі можливі локалізації (валюта, метод та тип оплати і таке інше) для всіх ринків?

На сервер отправлялся запрос с заказом в боди. Что он с ним дальше делал — как выставлял счёт, как процессил доставку на заданный адрес — я вообще без понятия.

Правильно, тому що на телефоні просто клієнт для магазину.

Ничего этого не было на устройстве.

А це лише одна з небагатьох речей потрібних для інтернет-магазину.

На сервер отправлялся запрос с заказом в боди. Что он с ним дальше делал — как выставлял счёт, как процессил доставку на заданный адрес — я вообще без понятия.

правильно. о том и речь — вы без понятия что такое простенький эл магазин, не говоря о «полнофункциональном»

может, ещё что-то.

без чего говорить о полнофункциональном эл магазине — невозможно.

а вот без нативных клиентов на смарте — полнофункциональных эл магазинов — большинство.

Звичайно, пробігтися по основних технологіях, базових поняттях — потрібно, але — не більше.
Питатися про розуміння SOLIDa приблизно те саме, що питатися про плавання батерфляєм.. Якщо шукається сеньйор — найкраще просто поговорити з кандидатом про проект, проблеми проекту, запитатися, що порадити може кандидат, а найголовніше — питання, котрі кандидат сформує. В більшості випадків цього — досить для інтерв’юера достатньої підготовки. Стосовно мідла — поговоріть про конкретну фічу, його бачення, питання, уточнення. Джун — просто про інструменти якими він володіє.
До речі, попросити кандидата прочитати 1-2 сторінки тексту (якоїсь проблематики) і попросити переказати з власними зауваженнями — чудовий тест, принаймні стосовно сеньйорів.

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

А не проще посмотреть на проекты над которыми работал данный специалист

а как вы на них посмотрите? кто ж вам даст смотреть
и как вы узнаете какую роль выполнял специалист на проекте?

в Германии слышал что да, практически решающая вещь
у нас...
народный телеграф работает конечно,
но выпросить рекомендацию «когда ты мерзавец бросил проект в трудную минуту, мы на тебя тааак расчитывали, а ты ...»

но выпросить рекомендацию «когда ты мерзавец бросил проект в трудную минуту, мы на тебя тааак расчитывали, а ты ...»

Они и правильно. Нет у чела рекомендации от счастливого клиента — нахер такой чел нужен?

Он и твой проект точно так же кинет, сбежав как только станет сложно «на +500».

Нет у чела рекомендации от счастливого клиента — нахер такой чел нужен?

клиент и имени его не знает
рекомендацию дает бывший начальник.
в Германии, пишут и на доу — что дают вполне объективные
у нас — изменнику Родины??? уж я дам, уж такую напишу,

но, вполне может быть что уже тоже, дают вполне объективные.

Он и твой проект точно так же кинет, сбежав как только станет сложно «на +500».

не вопрос. каждый ищет где ему лучше — его право.
станет мне неинтересен — и я кину, и без доплаты в +500

в Германии, пишут и на доу — что дают вполне объективные
у нас — изменнику Родины??? уж я дам, уж такую напишу,

В Германии контракторам (т.е. тем, кто зарабатывает реальное бабло) — рекомендацию не обязаны давать. Так же, как и в Украине.

В итоге, у кого рекомендации есть — тот спец. У кого нет — мутный тип, от которого неясно чего ожидать.

В итоге, у кого рекомендации есть — тот спец. У кого нет — мутный тип, от которого неясно чего ожидать.

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

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

а так да, обычно вообще мимо собеседований, по — прямой рекомендации. на нынешний проект тоже.

но правда, не знал что у нас в Украине репутационный институт уже значим, как в Европе.

но правда, не знал что у нас в Украине репутационный институт уже значим, как в Европе.

Надо ведь когда-нибудь начинать. Почему бы не сейчас? :)

Правда, я пишу о спецах, запрашивающих и получающих от хотя бы 60-80/час (не в Украине). А на ваши киндергеьды, уровня 2-3к/мес — можно вообще брать людей с закрытыми глазами и дальше смотреть, как оно пойдёт.

Правда, я пишу о спецах, запрашивающих и получающих от хотя бы 60-80/час (не в Украине)

а, все же не об Украине речь :)

Надо ведь когда-нибудь начинать

тогда начинайте, зачем ждать Украину :)

А на ваши киндергеьды, уровня 2-3к/мес — можно вообще брать людей с закрытыми глазами и дальше смотреть, как оно пойдёт.

ну, тоже — хозяин барин, берите с закрытыми глазами :)

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

В эмбедеде часто на новый проект подгребают всех знакомых.

достатньо десять пальців, щоб їх перебрати

То зазвичай і місця не більше)
Вот я чатик следал если что t.me/embeddedkyiv

у нас — изменнику Родины??? уж я дам, уж такую напишу,

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

а как вы на них посмотрите?

А спрашивать пробовали, на каких проектах работал человек и какие задачи эти проекты решали/на каких технологиях и подходах построены были?

и как вы узнаете какую роль выполнял специалист на проекте?

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

А спрашивать пробовали, на каких проектах работал человек и какие задачи эти проекты решали/на каких технологиях и подходах построены были?

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

А спросить у человека не пробовали?

всегда.

Прям как будто никогда не собеседовал людей на проект

конечно никогда. вам телепату все видать :)

У нас похожа на вот эту, как у CircleCI docs.google.com/...​feFZJsEo/edit?usp=sharing

жесть, у нас на работе третья табличка — это 3й уровень из 6...

здесь вот очень похоже www.quora.com/...​tware-engineers-at-Google, правда у нас 1й уровень — это интерн, а 3й миддл.

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

Сеньор способен сам затащить проект/фичу с нуля. При чем задача будет стоять как-то так «пойди туда, не знаю куда...». Ресерч, дизайн документ, команда, тест-план, деливери, кастомер суппорт — сеньор это вот все может

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

Саннивейл, Калифорния, Соединенные Штаты Америки

Неее, ну вы не сравнивайте =)
Но думаю типичный аутсорс проект в Украине в соло напишет даже мидл, и с большой вероятностью он даже будет устраивать заказчика=)

Мне кажется, обсуждаемая табличка в прицнипе будет разная для разных типов контор:

— для сайтиков-визиток, веб-макакинга верхняя табличка вообще малорелевантна;
— для автоматизации бизнеса, ИМХО, достаточно умений из колонки «Middle»;
— для продуктовой разработки — нужно хорошо разбираться в специфических технологиях на рынке конкретного продукта.

Во всех остальных случаях такая табличка — просто инструмент чмырения кандидатов во всяких аутсорсингах/аутстаффингах и обоснования копеечной компенсации в $2k-$3k месяц после собора 5% государством.

Тут речь идёт не о каком-то лично моём опыте, а по результатам просмотра свежего обзора зарплат в украинском ИТ. Где $2500 — это медиана найма. И для того, чтобы выйти на хоть какие-то вменяемые деньги — нужно долго стоять в очереди кандидатов в немногочисленные нанимаемые синьоры. В основном, конечно же, речь идёт о «дутых» синьорах. Это где все участники цепочки — клиент, посредник и специалист — все друг друга рады обманывать и обманываться.

В нормальных же странах, судя хотя бы dou.ua/...​ps-about-visa-l1-and-usa — не нужно стремиться прыгнуть выше головы, в какой-то Фаанг. Потому как средняя компенсация — не нищенская.

У меня, если честно, несколько подгорает от недавнего обсуждения в СНГ-шной «курилке», что якобы уже в соседней стране в типичный бодишоп с долларовыми зарплатами сложно нанять серверных джавистов. Так как просто обычные банки той соседней страны скупили их в последние год-два на зарплаты, перебивающие жлобские предложения посредников. (

$15 в годину мінімалка в США,
так що $2500 в місяць на аутсорс, ну не знаю, мабуть забагато і стоїть черга

$15 в годину мінімалка в США,

вообще-то $8 с копейками т.е. с центами и всё остальное такой же ж бред как и обычно пишет этот чувак «за америку за европку» а потом если его начать ловить и зажимать он съезжает на «за азию» и т.д. и т.п.

ЗЫ: скажем взять меня я эксперт как подтверждение тому обладающий полным уровнем классического даннинга крюгера а потом сразу же ж засомневавшись в собственных словах и таки проверив и оказывается таки не прав и оказывается

Employers subject to the Fair Labor Standards Act must pay the current Federal minimum wage of $7.25 per hour.

вынужден признать что многие годы лично я считал эту цифру $8+ а оказывается вот оно как

более того согласно этому

www.dol.gov/...​es/whd/minimum-wage/state

в некоторых штатах могут быть условия когда минимальная з.п. даже ниже «федеральных» $7.25 что впрочем должно быть очевидно исходя из

Employers subject to the Fair Labor Standards Act ...

и надо понимать что есть и другие кто не есть subject to the Fair Labor Standards Act

ну и пройдя весь список перечислить штаты в которых «минималка» $15 это легко ))

их всего 2 причём оба два даже не «штаты» и это DC и NYC

не читайте советских газет и полезных идиотов ))

там в Бідена новий акт про мінімалку в пятнашку
www.washingtonpost.com/...​en-minimum-wage-stimulus
думаю пропихнуть, так що я вважаю це як здійснившийся факт

думаю пропихнуть, так що я вважаю це як здійснившийся факт

думаю всё не так однозначно )) (к) (тм)

піднімати рейти на 30% для «нових доларів»,
а що робити з «старими доларами», то вже кожен вирішує сам: маринувати в банках чи купляти коени чи м2

вообще-то $8 с копейками

В WA більше. Було колись $12, зараз може і $15.

Насправді от би тему де фаангові сіньйори міряються з укр аутсорсними.

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

С другой стороны, разрабатывать с нуля идею украинскому сеньору вряд ли дадут

а он сможет? ))

Если раньше уже такое видел на другой конторе — то почему нет?
ЗЫ Юбик скедюлер или вот мои радиотелефоны

на это у меня уже есть отличный тест ну ок «отличным» я его сам считаю правда справедливости ради я его у кого-то украл )) в качестве теста «почему нет» я предлагаю разработать приготовление яичницы «делай раз делай два» а потом его ещё и масштабировать

... и тут оказывается что одна толпа вообще не привыкла ничего разрабатывать на уровне «погуглю решение» а другая толпа вообще не привыкла как-либо свою «разработку» формализировать на уровне «ну тут главное начать а там как-то само пойдёт»

Это значит, что вы старательно именно таких на собеседования отбираете и зовете.

не поверишь эту историю за «плохое окружение как отражение тебя самого» я слушаю уже годами в разных контекстах и тут ясное дело клоуна в президенты тоже я пригласил )) лично

Какое отношение имеют американцы к украинцам?

а в американцах софт пишут понятно великий светлые эльфы и искусные горные гномы

дядя витя пойди на ком-то другом потренируйся не задрачивай дедушку дедушка воевал ))

Если раньше уже такое видел на другой конторе — то почему нет?

так идея она на то и идея, что в другой конторе ее до этого не было

А шо не так с сео в веганском спа? 😄

фотопруф или не было! ))

А шо не так с сео в веганском спа?

Как минимум, что на нормальной работе программист не будет бегать и выяснять требования, а просто будет делать то, что в джире. Если в джире будут непонятки, задаст вопрос в комментах к тикету, чтобы у того, кому потом, возможно менеджер кинет делать эту таску, была полная картина.
Тест план — это вообще работа куа.
Нормальная работа отличается от стартапа, что на ней каждый может сконцентрироваться на своём участке работы и достигнуть высот именно в нём. Потому что это именно то, что можно продать потом на рынке труда, а не то как ты лихо запорол 8 дел одновременно из 5 разных ролей в стратапе, который закрылся год назад.

Вот гипотетический пример. Пусть разрабатывается какая-то система по работе с автомобилями. В джире написано что-то типа создать БД, «первичный ключ — государственный регистрационный номер автомобиля». Вроде бы все достаточно ясно и четко написано.

Но вот только гос. номер имеет свойство изменяться после продаж и перерегистраций по разным причинам. VIN — нет ( переваренные случаи не рассматриваем ). Может это и Ок в рамках конкретной задачи, типа там для страховой, где данные обрабатываются в разрезе регистрации, но вряд ли Ок для автосервиса. Или может система будет мультимодульная.
Вот нормальный программист хотя бы поднимет этот вопрос и уточнит. А не возьмет под козырек, не думая закодит, и потом когда глобальный потребуется рефакторинг через полгода, будет тыкать в Джиру.

При этом же, понятно что вникать «почему для такой категории именно скидка в 16%, а для такой в 24%» — тут уже не сильно стОит.

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

например врядли мобильщик будет решать и подобия указанной вами задачи
ему как скажут с этим номером работать — так и будет.

да и вот если представить

разрабатывается какая-то система по работе с автомобилями.

наверняка функционал в webUI будет куда развесистей чем в мобильном клиенте, даже для office user, не говоря о home. так что все будет расписано, даже когда

потом когда глобальный потребуется рефакторинг через полгода
В джире написано что-то типа создать БД, «первичный ключ — государственный регистрационный номер автомобиля».

Такая незадача может разве что на бэкенде возникнуть. В приложении мне придёт джсон с полем «айди» в котором будет то уникальное значение, по которому я буду запрашивать подробную инфу о данном автомобиле. Что будет этим айдишником — решат без меня.
А если у меня даже и будет на клиенте логика расшифровки vin-номера, она будет сделана строго по документации и все неясные моменты будут выяснены у бизнеса в письменной форме прямо в комментах под тикетом.

О, теоретики поднянулись :)

он не теоретик, он мидл к которому нужна обвязка синьоров, пиэмов, аналитиков, которая ему почти все и закодит, а он буква в букву напишет клиентскую часть.
иначе он всех их уволит :)

Теоретический сеньор 😂

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

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

такая у них обособленная от разработки продукта специализация.

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

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

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

Наш похоже доволен позицией «копать от забора до обеда», но это не значит что везде в мобильной разработке так

не знаю, думаю что конечно бывает и по другому.

но он очень убедителен, что не бывает по другому :)

Он просто спорит о вкусе устриц, не имея о них ни малейшего представления :)

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

У меня к бэкендерам было всегда только одно требование. Ребята, присылайте что и как хотите. Только нормально это документируйте. Пример запроса, пример ответа, Вики по структурам запроса и ответа. Примеры ошибок.

А что, openApi или Swagger — это табу?

Каким образом будет предоставлена эта документация, напишут они её сами, или её сгенерит модный сервис — мне, как разработчику мобильного клиента вообще не интересно. У меня хватает своего интересного :)

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

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

Для кого-то это теория «где-то там», для кого-то — практика «где-то здесь».

Дада, у меня точно так же было на моей первой работе, когда джуном на $300 взяли

было на моей первой работе, когда джуном на $300 взяли

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

есть разница между «сеньорной медианой» и «бодишопной сеньорской медианой». Вторую не жалко, вот тебе и платили

По данным доу, сениорская медиана в аутстаффе не отличается от таковой в продуктах. В стартапах аж на 12% больше.
dou.ua/...​-report-devs-winter-2021
Я, короче, не согласен за 12% бегать за всеми и выяснять требования.

Удачи тебе чувак, те же 7к тебе не видать

те же 7к тебе не видать

При медиане 4,5К их не видеть абсолютному большинству стартапных сениоров

Продолжай так думать, и оставайся на своих 4,5к

Целая половина, больше.

Если посмотреть на график распределения Гаусса, то становится понятно, что из этой половины 90% получает больше в пределах +500. Что при таких суммах уже несущественно.

Блин, я была уверена что ты в штатах. Тогда расслабься, да

Я и в бытность свою в штатах ни за кем не бегал

Moжно здесь рассказать почему после Штатов из Свитлы в Автодок перешёл?

почему после Штатов из Свитлы в Автодок перешёл?

Всё банально и просто. В Свитле клиент переформатировал команду, увеличив численность бэкенда и сократив численность мобайла сообразно текущей своей ситуации.
Другие клиенты Свитлы ничего интересного на данный момент не предложили. Автодок — предложил.

Скільки багато необхідних умов для того, щоб бути сеніором викладено і зовсім не згадано про одну єдину достатню умову щоб бути сеніором.

ГОТОВНІСТЬ брати на себе відповідальність.

ПРАКТИКА... вона необхідна, але в регуляра вона може бути більшою...

ЗНАННЯ... вони потрібні, але в джуна їх може бути більше... І що???
Джун тільки-но вийшов з виша. Його пам’ять там форматували та оптимізували і заливали усім, що є «в тренді»... І що???

Про що забув автор? МИ першим чином ІНЖЕНЕРИ.

Не знаю як ваші виші, але мій — МВТУ ім. Баумана, найкращий виш часів СРСР — формалізував наступне:
--- Інженером людину робить системний підхід та вміння користуватися довідниковою літературою...

Ми ж як в «Матриці»: «—Ти вмієш керувати гелікоптером? — Ще ні...»
Знання потрібні тоді, коли потрібні. Не раніше і не пізніше.
От мені, як тім ліду, нащо в команді офлайн версія гугля з голосовим інтерфейсом?

А от вміння зробити аргументовано правильний вибір між можливими варіантами, оцінити плюси і мінуси, оцінити ризики і головне — брати на себе відповідальність за цей вибір — от оце сеніор.

Сьогодні на ринку, нажаль, під лейбою «сеніор» по більшості ховаються гарно освідчені джуни з гарний досвідом копіювання гугля та рекурсивного копіювання самих себе... Але ще гірше, коли такі джуни починають проводити ТІ і плодити собі подібних....

Що з тим робити? А нічого. Економіка Знань — економіка теперішнього часу — легко розставляє все на свої місця! :) :) :)

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

да уж конечно всё так

Очень с вами согласен.
Экспертиза по опыту это последнее средство.
Ищут *синьера касира* спрашивают как с бухгалтера высшей категории. Или задают вопросы *раскажите что вы знаете о технологии термопечати*. И само собой синьер-касир должен быть в курсе технологии на уровне сервис-инженера по обслуживанию термо-принтеров.
А на самом деле, многие проэцируют свои синдромы самозванца. Причем в самом негативном ключе — требуют того, в чем сами имеют — поверхностные знания.
Потому, что эксперт, не видит сложностей в решении частного случая. И в курсе что решения класифицированной проблемы может быть больше одного(того что он сам знает).
И вообще, *если я не понимаю сути, значит: это ничего не стоит* рулит все больше и больше, и чем больше впихнули модных буз-вордов в вакансию тем круче. Как еще зарабатывать бонусы? :)

Скажу зі свого досвіду.
Для мене сеньйор визначається досвідом (роками) і складністю вирішення завдань на проекті.
Тобто він наприклад, може не знати про NoSQL, якщо раніше не мав з ним справи. І в свій проект, де потрібен NoSQL, я його швидше за все не візьму, але це не означає, що він не сеньйор.
Але якщо я його візьму, то він набагато швидше освоїть NoSQL і сам проект, ніж той же миддл.

Але якщо я його візьму, то він набагато швидше освоїть NoSQL і сам проект, ніж той же миддл.

бо ключовий момент досвіду сіньора це здатність працювати автономно тут «автономно» у тому ключі що сіньору можна поставити задачу «набагато швидше освоїть NoSQL» і просто отримувати періодичні короткі і місткі звіти по процесу і більше на те не витрачати власного часу хіба що на конкретні питяння

і так зокрема добра навичка сіньора це ставити _конкретні_ питання ))

Тобто він наприклад, може не знати про NoSQL, якщо раніше не мав з ним справи. І в свій проект, де потрібен NoSQL, я його швидше за все не візьму

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

Но. Вы написали дословно

не знати про NoSQL

Не троллинга ради, и не сочтите, пожалуйста, за докапывание к словам от нечего делать — но я правда не понимаю. Этот наш гипотетический senior что, последние десять лет просидел в бункере? Можно не иметь практического опыта, можно не иметь глубоких практических знаний — но неужели человек ни разу вообще не поинтересовался, что такое этот ваш NoSQL и с чем его едят? Не сделал даже ни одного простенького pet-проекта, или хотя бы не поигрался с той же Монгой, о которой уже который год пишут чуть ли не на каждом заборе? Ни в одном интернет-сраче не поучаствовал, пусть даже «топя» за классические реляционки?

у меня важный вопрос. как жабе выйти замуж, если вокруг одни крокодилы? или, иными словами, соткудова человек получит «боевой» опыт, если для попасть на прожэкт нужен боевой опыт? гражданин может пройти курс, прочитать учебник, понаделать сто задач, но в вашей деформированной картине мира про боевой опыт это нашему пациенту аж никак не поможет.

в вашей деформированной картине мира

Боевой опыт можно получить, попав на проект, где уже есть кто-то опытный по тем же NoSQL базам, путём постепенной разгрузки этого человека вначале от самых простых, а потом всё более сложных задач.

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

где уже есть кто-то опытный по тем же NoSQL базам,

рекурсия

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

Во втором сценарии — правда, не с NoSQL — довелось поучаствовать лично мне. Нужно было разработать расширение под Visual Studio Code, этого в компании никто не умел. Технологически там TypeScript / NodeJS, и, если с первым я ещё имел дело на уровне прототипов для front-end, то со вторым — вот вообще нет. Забегая вперёд, скажу, что всё закончилось успешно.

либо нанимать такого эксперта с рынка / привлекать part-time у партнёрских компаний

опять рекурсия

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

единственный не рекурсионный вариант

на самом деле «эксперт» внутренний или с рынка, может быть в разы хуже «просто толкового», и кстати это попсовое явление

и ваш второй вариант очередное тому свидетельство

"не знать про NoSq«l и «не иметь опыта в крупномасштабном высоконагруженном на этот самый ноэскуэль проекте» — две большие разницы

У меня вот уже 10 лет опыта, и фронт и бэк писал, были проекты и с одним программистом и с десятками...Ни разу не писал/работал ноусиквел базу.
Работал с фулл текст серчь(там есть документы но это свосем другое), дата процессинг/ETL, вебграфикой, несколько закрытых и самописных фреемверков от компаниий в которых работал, немножко nHibernate/EF но почти всегда это был самописный DAL на хранимках в MS SQL.
В будущем прочие ноусиквел базы все также пох, надо будет разберусь.
И я не проецирую свой опыт как всеобщепр нятое и то что другие сидят в бункере если не работали с чем я работал.

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

А можно поинтересоваться, с чем связан «пох»? Ну вот, правда, никогда даже любопытства не возникало?

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

С тем что топиков для изучения тьма, если мне за это не платят сейчас и/или не заплатят в перспективе, то нахиба тратить время? Чтобы кому-то доказать что я тру сеньор? Ну вот если этот кто-то будет мне платить тру сеньорскую зп, тогда и погворим.

А можно поинтересоваться, с чем связан «пох»?

З тим, що є більш цікаві для когось конкретно теми.

Отлично! Главное — что они есть

вопрос — сможешь примерно сказать как в документо-ориентированной БД хранить order (классический кейс many to many)?

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

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

ну вот видишь, а говоришь что ничего не знаешь :)

Это то, за что нифига не заплатят и скужут что я джун и мне надо поучиться. Как на перформанс ревью так и на собеседовании.

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

Прошедший марафон собесов показывает что таких собесов еще ооочень много, но да, не все конечно.

Що, і навіть Редіс? Повноцінний key-value storage, тобто NoSQL, там пречудово зберігаються агрегати (DDD)

Але ви ж розумієте, що у вашому тексті NoSQL можна замінити будь-кого технологією.
І знайдеться сеньйор, який ніколи не працював з Kafka, ElasticSearch, Docker або навіть Spring. Хоча він прекрасний фахівець і добре розбирається в тому, з чим працював.
Скільки разів я освоював нові технології на льоту, уживаючи в новий проект. І нічого, адже головне в розробника зараз, як мені здається, не знання ВСЬОГО (бо це все швидко застаріває), а вміння освоїти нове.

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

знайдеться сеньйор, який ніколи не працював з Kafka, ElasticSearch, Docker або навіть Spring

Сергей, но ведь есть же известная разница между «никогда не работал с» (во что я охотно поверю) и «не интересовался, что это вообще такое»?

Я сам из вышеперечисленного на коммерческих проектах сталкивался только с ElasticSearch, и то немного. Ну ОК, ещё Docker по чуть-чуть сейчас использую для одной внутренней системы.

Но, вместе с тем, по всему остальному из вашего списка есть представление о том, что это такое и для чего нужно.

або навіть Spring
сталкивался только с ElasticSearch, и то немного. Ну ОК, ещё Docker

Т.е. у вас скорее всего Java-стек в компании далеко не основной, так?

Скорее, лично я с Java стеком плотно никогда не работал. А так он один из основных.

С другой стороны, интересно, почему такие далекоидущие выводы? Из списка выше специфичен для Java только Spring, да и то... а если мы, например, микросервисы пишем на каком-нибудь Micronaut или VertX? :)

а если мы, например, микросервисы пишем на каком-нибудь Micronaut или VertX? :)

Вполне может быть, просто Spring Boot, де-факто, самый распространенный фреймворк на сейчас ( дабы не начинать потенциальных холиваров, специально подчеркиваю — «распространенный», а не «самый лучший»)

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

Я же о другом говорил — если у меня лично не было опыта со Spring, то это ещё не значит, что в компании не распространён Java стек. В крупной компании CTO не во всех же проектах участвует лично; а в Java проектах мне участвовать и вовсе нет большого смысла, так как я исторически из противоположного лагеря :) (хотя, вот Jenkins pipelines и расширения для них доводилось писать на Groovy, но это другое)

Опять же, что хотел подчеркнуть — даже будучи исторически Microsoft guy, мне было интересно, а что там делается в Java мире, как и на чём там сейчас пишут.

Неплохо... но в первом приближении...

Ведь знание Mongo, и даже Cassandra — не есть знание NoSQL....

NoSQL — это идея. Идея простоя и четкая настолько, чтобы можно было тупому и технически неграмотному клиенту обьяснить почему он должен выкинуть свой Oracle на дорогих exadata и поставить что-то, что не имеет цены и потому бесценно...

..но людей идейных сейчас мало...

изи -) я за последние 4 года бд вообще ни разу не трогала (если конечно не считать etcd базой данных)

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

Тем более, что базы данных — это просто пример. Если взять вашу специфику, то, вполне вероятно, кроме etcd вы смотрели на Consul и ZooKeeper, и хорошо понимаете плюсы/минусы каждого из этих решений.

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

Але якщо я його візьму, то він набагато швидше освоїть NoSQL і сам проект, ніж той же миддл.

А если он переубедит в пользу использования SQL своим синьорским авторитетом?

Будто что-то плохое!

...и вдруг просто так окажется правым???

NoSQL — это идея. И это паттерн. И как любой паттерн решает группу определенных проблем.
И если таковых проблем нету, то это уже будет антипаттерн...

Вот же например одна из проблем решаемых == озвучена CAP теоремой... а что, там нет места SQL??? ЕСТЬ. Потому как раз пониманиє NoSQL может иметь результатом переход на SQL...

Хотя для многих «знание NoSQL» — это «я сидел возле компа, на котором кто-то установил MongoDB»...

Ноускл это маркетинг так как под него попадает широкий и в корне разных бд с разными моделями — key-value, graph, document oriented и даже распределённая файловая система (привет хадуп) — какой это паттерн или идея? Или идея просто не юзать скл? Это идея на уровне подростков которые бунтуют ибо гормоны бьют, а тут вроде как взрослые итищники...

В большинстве случаев NoSQL стоило бы реализовывать поверх SQL структур. Где части данных МОЖНО быть неструктурированной нетипизированной и лежать грубо говоря в одной куче. Но чтобы по этой куче можно было строить индекс по абсолютно любому извлекаемому из поля содержимому. А там — хоть в архив эти данные суй.

Что в целом решается написанием плагина под базу. Поля специальных типов не запрещены.

Это именно так и реализовано в PostgreSQL, и в современных редакциях MS SQL, если не ошибаюсь, тоже.

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

С другой стороны, NoSQL — это не только про неструктурированные данные, но и про различные комбинации «два из трёх» в рамках CAP-теоремы, которые не могли предложить классические реляционные БД эпохи хайпа на NoSQL. Собственно, NoSQL базы своей популярности должны быть обязаны не столько необходимости хранить неструктурированные данные, сколько тому факту, что традиционные реляционные БД плохо масштабировались горизонтально.

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

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

Но камень преткновения — индексы. База данных это в принципе не столько про данные, сколько про индексы. И вот они-то далеки от SQL как Украина от вхождения в Евросоюз. И вот собственно индексы (и оптимизатор запросов) и решают всё. И в общем случае реляционная база не даёт построить индекс по недекларированному полю, а NoSQL база не обладает инструментарием разделения данных на ключевые и второстепенные иначе как разделением их физически.

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

А вот с хранимыми процедурами, я так понимаю, по прежнему тяжко в NoSQL базах? Как впрочем и в SQL, но там маразм в принципе в отсутствии адекватного языка их написания. Но в NoSQL в лучшем случае триггеры. А собственный скриптовый механизм без потери ништяков (в плане разделения таблиц) им бы ой-как не помешал.

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

А вот с хранимыми процедурами, я так понимаю, по прежнему тяжко в NoSQL базах?

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

На уровне базы хватает constraint’ов, а если нужна более сложная бизнес-логика — её уже обеспечивает само приложение.

Ну и, потом, вот в той же Монге есть
docs.mongodb.com/...​l/core/schema-validation

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

постоянно вижу :) и сам использую, потому что — это проверенная десятилетиями практика, надежно.

И кода на SQL получается куда меньше, чем на ЯП приложения.

На уровне базы хватает constraint’ов,

не хватит. только для примитивных проверок.
а есть еще — обновление доп данных.

а если нужна более сложная бизнес-логика — её уже обеспечивает само приложение.

возлагать на приложение это
— увеличить количество гоняемых данных между БД и приложением (самый яркий пример что видел — когда офисное приложение-клиент на дельфи, уже в количестве 4 штук клало на лопатки локальную сеть — проверки в клиенте, которые естественно требуют данных, а для ускорения — предварительное чтение требуемых для проверок данных. 3ех звенка конечно сняла бы частично проблему, в датацентре сеть помощнее между стойками ;)
— добавить риски порчи данных при сбое в приложении, или в результате рефакторинга новыми программистами. Это нередко обнаружится уже на продакшене, через пару недель работы обновленной версии, при нетипичном сценарии.
— при появлении дополнительных приложений — придется копипастить эту логику между ними, например основное приложение на php, вынесли несколько простых но нагруженных частей на Go — дублируйте теперь. и — поддерживайте одну и ту же логику — в двух системах. Более классический случай — разработка АРМа для конкретного отдела, или роли офисного пользователя. Не всегда имеет смысл усложнять обрезанным функционалом для них — основное приложение. Хотя бы потому что это — временный АРМ, и объявлено что через полгода его использования — будет выброшен, после предстоящей реорганизации.

Вопрос при выборе подхода должен ставится так:
Что ценнее в этой системе — данные ИЛИ алгоритмы?

«Удивительно», но например у системы гугл поиска или фейсбука — ценнее алгоритмы, чем данные: неверное ранжировании, пропуск какого-то источника попадающего на сотую страницу; пропавшие посты, лайки — да пофик вопли этого одного пострадавшего.

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

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

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

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

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

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

отличаются. тем что они рядом с данными.
и что эти алгоритмы — отделены от приложения, а являются собственно — кастомизацией БД под потребности конкретного проекта.

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

уже писал — если цель проекта — обеспечить удобство программистам — то да, двайте выбирать подходы для достижения этой цели

но я в таких проектах не участвовал. мой скромный опыт — что цели у систем для бизнеса — совсем не в обеспечении удобства разработчиков.

Под такую писанину — уже и толковых спецов последние лет 15 не найдёшь. T

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

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

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

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

В написании хранимых процедур? Весь этот хлам, в западном энтерпрайзе уже давно переписали на жабе — ещё лет 15 как.

Остались, может, (как и КОБОЛ) разве что в системах — которые никакой модификации уже не подлежат.

Весь этот хлам, в западном энтерпрайзе уже давно переписали на жабе — ещё лет 15 как.

как раз в Джаве мире и слышал шутку
Странно, устроился работать Джава программистом, а кода пишу больше на Pl/SQL

Но ладно, будем считать что времена изменились, а я не заметил.
Непонятно правда почему все более дивными фичами обрастает троица Oracle DB, MS SQL, и Postgress — как раз направленными на обработку данных на стороне сервера БД
видать просто для легаси проектов, а так — все на джаве уже переписано 15 лет как, и современная разработка ни в чем таком уже не нуждается.

Непонятно правда почему все более дивными фичами обрастает троица Oracle DB, MS SQL, и Postgress — как раз направленными на обработку данных на стороне сервера БД

Последняя версия PL/SQL (9.2) — датируется примерно 2002-м годом.
Последний стандарт от SQL/PSM ( ISO standard mainly defining an extension of SQL with a procedural language for use in stored procedures) — датируется 99-м годом.
Такое вот «развитие».

У других (мелкомягкие, постгресс) — думаю, похоже.

SQL:2016 / December 2016; 4 years ago

Причём тут SQL? SQL-то — живее всех живых. :)

Це ж теж кодити можна на цьому?

Там, похоже, расширили SQL фичами, типа паттерн-матчига, итп.
Но никаких процедур и прочей функциональщины.

PostgreSQL 13 PL/pgSQL

Improve performance of simple PL/pgSQL expressions (Tom Lane, Amit Langote)

Improve performance of PL/pgSQL functions that use immutable expressions (Konstantin Knizhnik)

на кой, кому это надо?...

У других (мелкомягкие, постгресс) — думаю, похоже.

вы профессионал, думаете.
вместо погуглить

Changes in This Release for Oracle Database PL/SQL Language Reference
Changes in Oracle Database Release 19c
docs.oracle.com/...​DB-496E-BCCF-4585C7E064AF

А що ти хочеш розвивати в SQL ? В тому, що завершено і самодостатньо.

Скажем, в SQL тоже есть функции. Можно добавлять новые/расширять имеющиеся (на уровне стандарта языка и реализации внутри СУБД движков).

От таких функций есть смысл — т.к. они-то (в отличии от хранимых процедур) — работают действительно существенно эффективнее, чем если бы выполнялись вне запросов/вне СУБД.

Розвитком SQL є написання саме процедур НЕ на SQL, а на нормальній мові програмування. Яка вже буде за необхідності робити SQL-запити. А потім вже за класикою, як в нормальному коді, можна обробити локальні дані без написання для цього дибільних UPDATE чи SELECT, та спроб вгадати як то буде оптимізовано, і яка зі змінних зміниться першою, і що станеться коли запити потрапять в колізію конкурентним виконанням цієї процедури.

Ну на самом деле еще дохиба проектов с логикой в хранимках, но везде где встречал это переписывается (последние два проекта именно такие) бизнесс логика в хранимках это днище.
Можно конечно и так но оно того не стоит и все крайне геморно становится а главное что толку от этого ноль на палочке. Сиквел должне хранить\собирать\агрегировать данные но никак не изменять и боже упаси — знать что-то о UI.

потому что — это проверенная десятилетиями практика, надежно.
И кода на SQL получается куда меньше

Вот только этот код невозможно покрыть юнит-тестами. Не говоря уже о боли с контролем версий и отладкой SQL скриптов.

увеличить количество гоняемых данных между БД и приложением

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

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

Так мы о современном состоянии дел говорим, или о подходах двадцатипятилетней давности? :)

при появлении дополнительных приложений — придется копипастить эту логику между ними, например основное приложение на php, вынесли несколько простых но нагруженных частей на Go — дублируйте теперь

Это, надеюсь, такой тонкий троллинг? Иначе, какое, к чертям, копипастить?! :) Делается один сервис, которые отвечает за определённую часть предметной области, и вся бизнес-логика строго только в этом сервисе.

разработка АРМа для конкретного отдела, или роли офисного пользователя. Не всегда имеет смысл усложнять обрезанным функционалом для них — основное приложение

Опять же, решение «здорового человека» в таком случае — это общий сервис с Web API (по желанию, можно какой-нибудь Thrift / Protobuf, если сервис не планируется использовать напрямую из Web front-end).

через полгода его работы — будет выброшен, после предстоящей реорганизации

Можно выбросить UI / уровень application services, специфичный для этого временного АРМ. А вот операции над предметной областью (уровень domain entities / business domain services), скорее всего, останутся.

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

Я не знаю, возможно, в каких-нибудь банках или процессинговых системах типа Visa такое, действительно, до сих пор применяется. Тут ничего не могу сказать — опыта работы в серьёзном финтехе у меня нет. Но, в других отраслях, активного использования хранимок и даже check constraints сложнее NOT NULL на уровне БД не видел эдак с самого начала нулевых.

Вот только этот код невозможно покрыть юнит-тестами

покройте интергациоными тестами

и даже check constraints сложнее NOT NULL на уровне БД не видел эдак с самого начала нулевых.

то есть нет unique index? нет enum tables? нет foreign key? это все — constraints

то есть нет unique index? нет enum tables? нет foreign key? это все — constraints

Просто оставлю это здесь:
en.wikipedia.org/wiki/Check_constraint

Вот только этот код невозможно покрыть юнит-тестами
покройте интергациоными тестами

Как насчет разницы во временнЫх затратах в пересчете на простейшее изменение?

простейшее изменение?

которое и приводит к багу.
а юнит-тесты зеленые.
как так?

Вот только этот код невозможно покрыть юнит-тестами

да, юнит-тестами не получится.

если для проекта наличие юнит-тестов критичнее остальных характеристик конечного продукта — то да, нельзя использовать серьезные возможности БД. лучше всего работать с любой БД как с key-value storage. Ради юнит-тестов

Так же как если планируется «каждые полгода» менять БД — нельзя использовать специфические возможности конкретной БД, а писать только для самого примитивного варианта БД такого типа.

Все зависит от целей и условий проекта

Делается один сервис, которые отвечает за определённую часть предметной области

или — не делается. потому что выйдет намного дороже, чем возложить эту проверку — на БД.

Опять же, решение «здорового человека» в таком случае — это общий сервис с Web API (по желанию, можно какой-нибудь Thrift / Protobuf, если сервис не планируется использовать напрямую из Web front-end).

Это решение не здорового человека — а идеалиста. Как по мне.
Потому что это решение, или любой другое — выбирается не по принципу «здорового человека», а по совокупности факторов разработки.

А вот операции над предметной областью (уровень domain entities / business domain services), скорее всего, останутся.

которые суть — операции над данными.
смысла в никаких domain entities — без данных нет. и если в данных будет косоплет — то юниттестами вы его не отловите.

Но, в других отраслях, активного использования хранимок и даже check constraints сложнее NOT NULL на уровне БД не видел эдак с самого начала нулевых.

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

если для проекта наличие юнит-тестов критичнее остальных характеристик конечного продукта — то да, нельзя использовать серьезные возможности БД. лучше всего работать с любой БД как с key-value storage.

С БД работают, как с БД. Чем хороша реляционная БД/приличная СУБД? Cледить за целостностью данных + возможностью выполнять SQL запросы.
Это СУБД/БД и поручают.

А то, что производители затащили под крышу СУБД/БД ещё и коденье (в очень убогом варианте) — так на то челу и мозги, чтобы убогим не пользоваться. Предпочитая для коденья хороший инструментарий, с возможностями отладки/тестирования.

Эти дискуссии (насчёт хранимые процедуры против внешнего кода бизнес-логики) — закончились ещё 20 лет назад. Тогда был выработан конcенсус и с тех пор, пользовать хранимые процедуры — это один из признаков непрофессионализма. Т.к. это пользование не даёт проекту никаких плюсов — зато делает кучу минусов.

Cледить за целостностью данных + возможностью выполнять SQL запросы.
Это СУБД/БД и поручают.

да, это и поручают.
вот и следим, используя возможности — БД. есть там тригеры, есть ХП? замечательно, используем. Нет? Выбираем другую БД.

Эти дискуссии (насчёт хранимые процедуры против внешнего кода бизнес-логики) — закончились ещё 20 лет назад. Тогда был выработан конcенсус и с тех пор, пользовать хранимые процедуры — это один из признаков непрофессионализма.

принято. возразить на такое невозможно.

есть там тригеры, есть ХП? замечательно, используем. Нет? Выбираем другую БД.

«Триггеры» плохая практика тоже — т.к. с ними проблемы подобные хранимым процедурам, но ещё и усугyблённые их невидимостью/неявностью.

ясно. понятно.
кусаю локти от своего непрофессионализма и провала собеседования.

ясно. понятно.
кусаю локти от своего непрофессионализма и провала собеседования.

Помотрел твоё резюме на линкедин — сплошной 1С, с последующим ПХП. Чувствуется профессиональная деформация.

На 1С и ПХП, вероятно, юнит-тесты действительно не особо нужны (т.к. что там тестировать в паре-тройке ХТМЛных форм?).
А кодить бизнес-логику, возможно, ещё сложнее — чем кодить хранимые процедуры внутри СУБД (при невозможности дебажить и покрывать юнит-тестами).

Но такое, лишь для простых формошлёпских поделок при работе за еду (потолок ПХП), катит.

Помотрел твоё резюме на линкедин — сплошной 1С

там не резюме — а что-то типа трудовой книжки
там еще и геймдев есть, и Джава. и рук проекта внедрения и «зам нач отдела АСУ».
и MUMPS даже есть.

но вы увидели что хотели :)

с последующим ПХП

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

т.к. что там тестировать в паре-тройке ХТМЛных форм?

действительно, что там тестировать кроме хтмлных форм?
открываешь любой сайт — там формы, вебщина.
что там тестируют то?

Но такое, лишь для простых формошлёпских поделок при работе за еду

если верить зарплатным опросникам на доу, то вроде и не за еду.
но ладно, вы мое резюме на линкедин видели — все поняли. правды от вас не утаить...

А как же

(самый яркий пример что видел — когда офисное приложение-клиент на дельфи, уже в количестве 4 штук клало на лопатки локальную сеть
Аргумент блондинки: «А вот я знаю случай!»
не обсуждаю.

Будьте последовательны, что ли

Будьте последовательны, что ли

я последователен. это просто яркий случай — обычной ситуации избыточного чтения из БД, потому что — «логика должна быть в приложении»
у другого случая «логики в приложениях» есть даже название проблемы — SELECT N+1

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

Это проблема когда не понимают как работать с базой,

естественно. компетенции должны быть.
нельзя брать джависта в команду эмбедщиков разрабатывающих ПО для автомобиля.

Тот кто не понимает селект плюс один

тот кто умеет только в ORM — и не увидит даже. Пока в реальном использовании не выяснится, а не «юнит-тесты у нас работают быстро!»

если б я не видел этого удивления от Hibernate — то конечно бы поверил что мне в этой теме прогружают :)
или адепты DDD :)

напишет тебе таких хранимок что сам офигеешь.

конечно. нубиот на чем угодно тааакое в состояние написать, что офигеешь.
не верите? «индусский код» видели? я видел, и фиксал. на Джаве.
давайте Джаву запретим!

про код нубиотов на js и php я упоминать не буду. это и в «индию» заглядывать не нужно.

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

В частности, генераторы всякие. Ведь это вопрос времени, когда неверно введённые данные полезут править корявыми лапками, в частности, удалять, наплевав на «хвосты».

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

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

логика не сложная, но которую не хочется доверять разработчикам приложений от слова «совсем»

А те, кто пишут хранимые процедуры, это что — «белая кость»? «Высшая каста»? :)
Почему им доверять можно, а разработчикам приложений — нельзя?

Нет, если, конечно, бизнес-модель предполагает найм одного DBA-гуру и кучи, прости Господи, формошлёпов — то, наверное, в таком подходе есть рациональное зерно.

Но я бы не хотел работать в компании, где практикуют подобное.

А те, кто пишут хранимые процедуры, это что — «белая кость»?

уже ответили

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

потому и не встретимся — я бы не хотел работать в компании где надо писать кучу хрупкого кода, хотя на стороне сервера БД это делается в три строки.
при том что этот хрупкий код придется переписывать, тормозить он будет дико на реальных данных. и лезть в кишки ORMу (даже нынешнему, ActiveRecord ORMу пришлось лезть, тупит на реальных объемах)

непрофессионал я, что уж тут таиться...

Якщо є складна логіка і в ній помилка, то я на джаві швидко знайду цю помилку дебагаючи код навіть бібліотек які я використовую. Дебагати сторед процедури ще те задоволення.
Але для мене основна причина не писати сторед процедур і тригерів в тому, що бізнес логіка має бути написа в одному місці. Тоді будь хто може швидко зрозуміти що програма робить. Код треба писати так, щоб його розуміли інші люди, а не компілятор.

то я на джаві швидко знайду цю помилку дебагаючи код

так, так, героі вони такі, швидко знаходять
то невігласи на доу пишуть бува, що не один день шукають баг — на джаві.

що бізнес логіка має бути написа в одному місці.

тобто ви пишите — один клас, і вся бізнес-логіка у вас там, в одному класі. ну ок.

Код треба писати так, щоб його розуміли інші люди

так, так, щоб кожен джун зрозумів, без зайвих питань — прочитав код, і все зрозумів. і бізнес-логіку теж, вона ж ось, в одому місці написана.

так, так, героі вони такі, швидко знаходять

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

тобто ви пишите — один клас, і вся бізнес-логіка у вас там, в одному класі. ну ок.

Разбивается по респонсибилити и функциональности и еще даже тестами легко кроется.

так, так, щоб кожен джун зрозумів, без зайвих питань

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

Для этого есть юнит тесты, и они будут у прогера под рукой, бегают быстро

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

А также будет дебагер и куча тулзовин анализаторов кода которые упрощают поиск багов

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

но у вас анализаторы кода и юнит-тесты это отловят, да :)
например что заинжекчен был не тот сервис, потому что в конфиге DI ачепятка.

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

Разбивается по респонсибилити и функциональности и еще даже тестами легко кроется.

то есть будет — не в одном месте.

от сиквела от вообще убежит.

никто ж неволит, конечно пусть бежит :)

В общем, если вам нравится писать логику в хранимках

мне нравится писать ее там — где удобнее и надежнее будет
а джуны да, пусть бегут туда где им нравится.
удобнее — это когда скорость разработки выше
надежнее — устойчивей к багам

попутно обычно еще и проблемы с быстродействием решаются.

но если цель проекта — написание юнит-тестов, и чтобы они быстро бегали, то да, берем key-value хранилище, пишем юниттесты, — сдаем их заказчику, и все довольны.

только предупреждаете программистов сразу о ваших предпочтениях.

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

так что никакого обмана — просто не проходит чел собеседование, и идет дальше. вакансий полно, найдет себе что он хочет, может.

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

Такую чушь написал что ппц, еще и лид лычка.

«Если один считает другого кретином, то один из них точно кретин»

еще и лид лычка.

какую дали, такая и лычка=уровень ответственности. это вообще не ко мне, а к тем кто мне платит.
а за время текущего проекта они уже перевидели, «23 летних сеньоров».

Теперь я понимаю почему некоторых за 45, не хотят брать на работу

в большинстве случаев не берут тех кому 23 а он не синьор :D

но вам виднее конечно

увольте меня, да и все :D

с токсичными лидами так и поступают ведь — просто увольняют!
главное ж — чтобы джуны были счастливы :)
и чтобы им легко было юнит-тесты писать.

Конечно виднее, потому как я греб и энтерпрайз и с нуля проекты и ETL проект был, и большие и маленькие, опта у меня уже 10 лет, так что 23 летний senior это точно не ко мне, но ты продолжай рассказывать про хранимки.

но ты продолжай рассказывать про хранимки.

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

но я уже услышал что — тригеры и хранимки это — непрофессионализм.
времена меняются, да.

мне нравится писать ее там — где удобнее и надежнее будет
а джуны да, пусть бегут туда где им нравится.

Классический паттерн поведения разработчиков\администраторов legacy систем, сталкивался не раз.
— «10 лет так делаю и проблем не было»
— «Mне юнит тесты не нужны, я и так свою систему знаю»
— «То у вас просто требования к системе неправильные»

10 лет так делаю и проблем не было

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

Mне юнит тесты не нужны, я и так свою систему знаю

предпочитаю просто функциональные и интеграционные.

потому что юнит-тесты мало что отлавливают. А процент покрытия да, создает иллюзию что все ок. менеджеры среднего звена любят.

да, юнит-тестами не получится.
предпочитаю просто функциональные и интеграционные.

Что вполне объяснимо.

менеджеры среднего звена любят.

Более того, еще и полиси продавливают, которые фэйлят попытки мержей из фича-бранчей при недостаточном покрытии. Менеджеры- вредители, как бы сказали в 30-х годах

Что вполне объяснимо.

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

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

Более того, еще и полиси продавливают, которые фэйлят попытки мержей из фича-бранчей при недостаточном покрытии

это пусть бизнес с ними разбирается.

понятно что из правила — чтобы создать надежную систему из ненадежных элементов нужно увеличить количество элементов и связей между ними следует

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

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

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

понятно что из правила — чтобы создать надежную систему из ненадежных элементов нужно увеличить количество элементов и связей между ними

В этом месте теория надежности нервно курит в стороне взатяг.

это правило встречал столько раз, что странно что оно объявляется ересью :)

погуглил, все его варианты что нашлись, отсылают как и помню к Нейману, к

The complete system must be organized in such a manner, that a malfunction of the whole automaton cannot be caused by the malfunctioning of a single component, or of a small number of components, but only by the malfunctioning of a large number of them.
в
PROBABILISTIC LOGICS AND THE SYNTHESIS OF RELIABLE ORGANISMS FROM UNRELIABLE COMPONENTS
delivered by PROFESSOR J. von NEUMANN
static.ias.edu/...​/Probabilistic_Logics.pdf

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

но ок, пес с ним, выкидываем дублирующие системы.

вместе с тестами — есть код, надежный, писан опытными, отревьюван еще более опытными.
зачем еще код писать какой-то для тестирования?

Системы с резервированием
Работоспособность систем без резервирования требует работоспособности всех элементов системы.
В сложных технических устройствах без резервирования никогда не удается достичь высокой надежности даже, если использовать элементы с высокими показателями безотказности.
Система с резервированием — это система с избыточностью элементов, т. е. с резервными составляющими, избыточными по отношению к минимально необходимой (основной) структуре и выполняющими те же функции, что и основные элементы.
По виду резервирование подразделяют на нагруженное («горячее», пассивное) и ненагруженное («холодное», активное):
•нагруженное — резервные элементы функционируют наравне с основными (постоянно включены в работу);
•ненагруженное — резервные элементы вводятся в работу только после отказа основных элементов (резервирование замещением).
НАДЕЖНОСТЬ И ДИАГНОСТИКА ПРИБОРОВ И СИСТЕМ
Учебное пособиеРекомендовано Методическим советом НТУУ «КПИ»

В области разработки программного обеспечения bus factor (либо truck factor) проекта — это мера сосредоточения информации среди отдельных членов проекта. Bus factor показывает количество разработчиков команды программистов, после потери которых проект не может быть дальше продолжен. Проект будет содержать такую информацию, с которой оставшиеся разработчики не смогут разобраться. Высокий bus factor проекта означает, что проект будет устойчиво развиваться, если его покинет даже большое количество программистов.
википедия

Вот это

The complete system must be organized in such a manner, that a malfunction of the whole automaton cannot be caused by the malfunctioning of a single component, or of a small number of components, but only by the malfunctioning of a large number of them.

и вот это

понятно что из правила — чтобы создать надежную систему из ненадежных элементов нужно увеличить количество элементов и связей между ними

совершенно разные утверждения.
В неймановской формулировке оно действительно соответствует общим формулировкам из теории надежности. Но никак не в вашей.

это правило встречал столько раз, что странно что оно объявляется ересью

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

есть код, надежный, писан опытными, отревьюван еще более опытными.
зачем еще код писать какой-то для тестирования?

В той же теории надежности, вероятность отказа элементов принимающих решение при резервировании обычно берут == 0. Тесты должны выдавать один и тот же результат, если их код и окружение в котором запускаются, не менялся. А опытные и сверхопытные тоже могут лажать. Так что можете рассматривать тесты как один из элементов, принимающий решение уйдет система в опасный отказ или нет.

совершенно разные утверждения.
В неймановской формулировке оно действительно соответствует общим формулировкам из теории надежности. Но никак не в вашей.

покажите чем же они разные :)

Если в системе из ненадежных элементов увеличить количество этих элементов и связей между ними, то время наработки на отказ уменьшится

ах вот вы о чем :)
естественно что вид, тип связей играет роль, а не просто увеличение. «толпа мужиков с автоматами еще не взвод»

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

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

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

Вы говорите о методах оценки надежности
А я о «правиле» изготовления надежных изделий

Не путайте, метрики и аспекты действительности что они отражают. По кругам на воде вы многое можете сказать о причине. Но цвет предмета — вы не узнаете.

Тесты должны выдавать один и тот же результат, если их код и окружение в котором запускаются, не менялся.

На одних и тех же данных — пропустили.

А опытные и сверхопытные тоже могут лажать

естественно. лажают и будут лажать. люди ж.

Так что можете рассматривать тесты как один из элементов, принимающий решение уйдет система в опасный отказ или нет.

речь была только об одном виде тестов — юнит.

на что я ответил уже — предпочитаю функциональные, интеграционные, приемочные.

но вернемся к правилу которое вызвало возмущение переворотом основ «теории надежности»:

какими методами обеспечивается уменьшение рисков от бас фактора?
какими методами достигается стабильность и предсказуемость разработки ПО?

«увеличением числа (исполнительных) элементов и связей(коммуникации) между ними» вам и Oleksandr Bereziuk категорически не понравилось

Тогда — какие предложите вы?

покажите чем же они разные :)

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

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

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

но вернемся к правилу которое вызвало возмущение переворотом основ «теории надежности»

Слово «правило» в кавычки взять надо. Я в начале этого сообщения даже перевод привел. Как видим, не очень эти высказывания и одинаковы.

То есть для вас эти высказывания одинаковы

по форме конечно разные.
просто поставьте вопрос после

Система должна быть организована таким образом

каким именно способом, какие есть способы чтобы обеспечить:

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

далее я там привел еще пару цитат.

Странно что вы не рассматриваете процесс изготовление софта как работу системы

так и рассматриваю, и написал об этом уже.

А тестирование — один из методов этот отказ выявить.

тестирование — это уже очень много, это куча процессов.
фокус группа, группа бета-тестеров добровольцев — тоже часть этого процесса.

Как видим, не очень эти высказывания и одинаковы.

по количеству букв да, не совпадают.

но вы лучше ответьте на вопросы

какими методами обеспечивается уменьшение рисков от бас фактора?
какими методами достигается стабильность и предсказуемость разработки ПО?

интересно как вы обойдетесь без

«правило» в кавычки взять надо

Код ревью например — кто должен делать, сам себе программист, или уже надо добавлять еще в систему?

На одних и тех же данных — пропустили.
речь была только об одном виде тестов — юнит.

Скажите, вы вообще в принципе понимаете что такое юнит тесты?
Как у юнит тестов могут быть разные данные на входе?

какими методами обеспечивается уменьшение рисков от бас фактора?

1. Начиная с документирования. Как дизайна всего приложения, так и специфичных модулей
2. Писать, ВНЕЗАПНО, понятный код с минимумом неявных вызовов (ОСОБЕННО, каскадов триггеров). Чтобы попытка понять, что же должно происходить в рамках конкретного процесса для нового бойца не превращалась в два дня реверс-инжиниринга с тремя аудиенциями у местного гуру. Который обычно и становится таким вот бас-фактором.

какими методами достигается стабильность и предсказуемость разработки ПО?

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

Если есть N программистов, то количество пар программистов равно N(N—1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
Начиная с документирования

документ есть — вы уверены что он хотя бы просто прочитан?
как проверяете?

Писать, ВНЕЗАПНО, понятный код с минимумом неявных вызовов (ОСОБЕННО, каскадов триггеров).

Внезапно отказаться от обсерверов, евент басов, декораторов, АОП обвесок, аннотаций, слушателей событий, ..., ...
ну ок.

в рамках конкретного процесса для нового бойца

какого именно бойца? который с грехом пополам паттерны ООП вызубрил? под такого бойца — писать код?
а может сразу под уровень трейни?

Если я бы знал исчерпывающий ответ на этот вопрос

я тоже не знаю.

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

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

да, правильно.

А теперь добавим из Факты и заблуждения проф программирования Гласса
Это еще один постулат, такой же старый, как и сама отрасль ПО. Такое ощущение, что этот фундаментальный факт известен нам так хорошо и так давно, что как бы ускользает из нашей памяти без всяких усилий.
Но это факт чрезвычайной важности. Если учесть, насколько лучше некоторые программисты, чем другие (а речь идет о 5 — 28:кратном превосходстве), .... Именно самые лучшие, в 28 раз, (которым платят значительно меньше, чем вдвое, по сравнению с их посредственными коллегами) представляют собой самое выгодное вложение в сфере программирования. (Если уж на то пошло, то и о тех, кто лучше в 5 раз, можно сказать то же самое.)
(конец цитаты)

и вспомним что там было прилагательное

«ненадежных»
и опять добавим про «нового бойца»

то как вы хотя бы избежите издержек по управлению 5ю джунами вместо 1го синьора?

или вы считаете что все равны, и Гласс хрень написал,
времена изменились, книга устарела?

документ есть — вы уверены что он хотя бы просто прочитан?

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

Если учесть, насколько лучше некоторые программисты, чем другие (а речь идет о 5 — 28:кратном превосходстве), ..

28кратное, это уже что-то совсем запредельное, но в несколько раз — да.

то как вы хотя бы избежите издержек по управлению 5ю джунами вместо 1го синьора?

Это тоже корректно. Простите, но я не улавливаю ход вашей мыслей в целом. Много джунов — плохо, ибо несамостоятельные дебилы. Мало сениоров — плохо ибо бас фактор.

трактовка работы фон Неймана

Фон Нейман, насколько я помню, был про разработку железа. Это не маппится 1:1 на разработку софта, по крайней мере на процесс так уж точно

Ну все-таки надеюсь что новые товарищи не прямиком с ясельной группы приходят

поговорите об этом с ейчарами.

Учебное пособиеРекомендовано Методическим советом НТУУ «КПИ»

Спасибо, конечно, за дополнение к основному сообщению. Только к чему это?

Только к чему это?

ну там просто по русски ересь написана.
которая

В этом месте теория надежности нервно курит в стороне взатяг.

Ага, теперь понятно. То есть вы нагуглили кусок методички и привели его как аргумент к

понятно что из правила — чтобы создать надежную систему из ненадежных элементов нужно увеличить количество элементов и связей между ними

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

понятно что из правила — чтобы создать надежную систему из ненадежных элементов нужно увеличить количество элементов и связей между ними
Загуглить как рассчитывается наработка на отказ

вы опять о метриках :)

То есть вы нагуглили кусок методички

я нагуглил потому что знал что гуглю.
а там и про расчет метрик есть.
могу еще нагуглить, чтобы вы им всем написали, что они сами себе противоречат, потому что там же пишут:

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

пусть хотя бы «никогда» вычеркнут, а то портят мозги студентам ересью, вместе с фон Нейманом.

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

мне то понятно почему всплыла :)
я вам и предлагаю подумать — почему она всплыла :)

я нагуглил потому что знал что гуглю.

ну да, ну да

а там и про расчет метрик есть.

Конечно есть, если бы студентам этих основ не давали, я бы сильно удивился.

могу еще нагуглить, чтобы вы им всем написали, что они сами себе противоречат

Они-то как раз не противоречат и используют точные формулировки. Поэтому им не приходится прикрываться авторитетом фон Неймана (argumentum ad verecundiam, ну кто бы мог подумать), который, как оказалось при переводе, писал немного о другом.

мне то понятно почему всплыла

Ну вот, хорошо что вы наконец-то разобрались )).

который, как оказалось при переводе, писал немного о другом.

я вам предложил подумать о чем он писал :)

хорошо что вы наконец-то разобрались )).

да понятно зачем — вы не смогли пройти мимо кретина, пребывающем в глубоком эф Д-К :)

Признание проблемы — половина успеха в её разрешении. Хорошо что вы это понимаете.

спасибо.
я хотя бы на полпути, а вы пока и не сдвинулись ;)

Я слышал что глубокий Д-К, заставляющий определять проблемы других с точностью 146% по паре сообщений на форуме, ослабевает ко второй половине пути. Так что держите нас в курсе, проверим правда это или нет. ))

Я слышал что глубокий Д-К, заставляющий определять проблемы других с точностью 146%

ну вы ж смогли :)
чем я хужее :D

ну вы ж смогли :)

Ну что вы так скромничаете и приписывате свои целиком и полностью заслуженные достижения мне. Я не претендую на ваши лавры ))

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

Это ж все на лурке описано — с чего чел начинает, и как потом будет продолжать, и почему.

Могу ещё только добавить что начетчики и зубрилы, со школы ещё, на меня так реагируют :)

Но вы не отходите от предписанного вам сценария. А то ещё удивите,и мне придётся думать.

значит первое замечание было не по делу, а под впечатлением.

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

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

Пфф. Я понимаю что вы большой любитель погенерить тонны текста в ответ на каждый тезис, размазывая это все тонким слоем в 100500 предложений и задавая открытые вопросы, ответы на которые породят новые тонны текста. Но сорян, играйте в эти игры без меня, мне мое время дорого.

Это ж все на лурке описано — с чего чел начинает, и как потом будет продолжать, и почему.

Могу ещё только добавить что начетчики и зубрилы, со школы ещё, на меня так реагируют :)

Бгг, а что, в вашем окружении до сих пор ведутся на столь дешевые манипуляции, что вы их по привычке и на доу используете?

Бгг, а что, в вашем окружении до сих пор ведутся на столь дешевые манипуляции,

Вы ж повелись. И продолжаете по упомянутому сценарию ;)

допускает только такую трактовку

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

Но вы зашли сразу «с козырей» :)
И дальше ничего удивительного -все по выбранной себе роли :)

Ну вот видите, всего пару моих фраз порождает текстовое недержание. Представляете что случится, если я, не приведи Ктулху, начну на открытые вопросы отвечать? ))

Вы ж повелись.

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

Представляете что случится, если я, не приведи Ктулху, начну на открытые вопросы отвечать?

Не представляю. Потому что вы выйдете из роли :)
Да и если б могли — уже ответили б.

Например вот из этой:
УН0. Оскорбления
Это низший уровень несогласия и, пожалуй, самый распространенный. Мы все видели комментарии вроде
«Вот же ты козлина!!!!!!»
Важно также осознавать, что более многословное оскорбление имеет такой же вес. Комментарий вроде
«Это написал дилетант с завышенной самооценкой»
— просто пафосный способ сказать «Вот же ты козлина!»
Пол Грэм. Как правильно возражать

По простому — вы начали как обычный гавнюк — продолжили и закончили как обычный интернет гавнюк :)

Ну ніхто ж не довів теорему про те, що наявність юніт-тестів підвищує шанс проекту на успішне завершення

а кого цікавить успішне завершення, в тому ж аутсорсі?

там же треба показувати — метрики. а покриття — то дуже зручна метрика. середній менеджмент з обох боків — дуже задоволений.

а успіх проекту, то такє. гроші ж отримуються не за успіх — а за працю. праця була — плати!

понятно что из правила — чтобы создать надежную систему из ненадежных элементов нужно увеличить количество элементов и связей между ними следует

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

там же треба показувати — метрики. а покриття — то дуже зручна метрика. ... а успіх проекту, то такє

Хорошо. Вот у вас есть условный проект. Ну, не знаю там, 10 модулей, 5000 строк кода, или 20 модулей и 20000 строк, не принципиально. Каким образом вы можете хотя бы очень примерно оценить качество кода? Желательно в измеримом виде, а не «я ревьювил, все Ок, отвечаю». Или эта информация тоже НЕ НУЖНА ?

P.S. Ну и без демагогии на тему «видел проект с хорошим покрытием, но внутри ужасный» — такие случаи тоже бывают. Но их много меньше обратных. Хотя бы потому, что при достаточном количестве нормально написанных юнит тестов, стуктура проекта скорее всего будет более-менее вменяемой, с минимумом функций с запредельной цикломатической сложностью и гвоздями прибитых зависимостей. Иначе написать нормальные тесты либо очень трудозатратно, либо просто невозможно. Вот именно это и есть главный плюс, а не абстрактное число в 63.5% на выходе

Первый раз слышу о таком правиле.

Это было от Д. фон Неймана

Это просто переворот в теории надежности.

фон Нейман да, кретин.

Каким образом вы можете хотя бы очень примерно оценить качество кода?

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

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

Есть измеримая оценка качества кода, а есть надежность системы в действительности
И это — не одно и тоже. Косвенная связь есть, да.
Когда у среднего менеджмента нет возможности выяснить второй вид надежности — он прибегает к первому.

Увлечение метриками — анализом кругов на воде — это ж и есть работа менеджера :)

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

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

Грубо говоря, такого кода <0.01%, и потому так просто забыть о его существовании. А потом кусать локти, когда окажется что какую-нить неочевидную логику убрали при рефакторинге, потому что «проще было с нуля переписать».

когда окажется что какую-нить неочевидную логику убрали при рефакторинге, потому что «проще было с нуля переписать».

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

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

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

Чем ближе код находится к его сущностям, тем меньше нужно объяснять в документации и тем понятнее что он делает, и на порядок ниже риск что к его редактированию допустят человека, не разбирающегося в алгоритме и даже не имеющего задачи разобраться.

В этом весь смысл ООП. Но почему-то в коде это уже три десятилетия канон, равно как и традиция работать через get и set функции, а в базах данных по-прежнему через жопу.

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

А вот писать связи на коде, особенно если код распределён по нескольким серверам — ой, проблемно. Рано или поздно нарисуется коллизия. Скорее рано, но узнают поздно.

Их-то снесут первыми, чтобы не мешали

...случай знаю. недавно общался с приятелем в реале. джавистом.
он в компании имеющей свой внутренний продукт. Компания с США, система на Джаве, что-то там с домами, арендами. федерального уровня кажется.
Давно написана.
спросил для порядку о тестах. Не, смеется, нету. Были, и сейчас болтаются. но поломаны давно, и никто и не пытается их чинить.
А зачем? бизнес стабильно и неспеша растет. Фичи не спеша и аккуратно добавляем. как и баги — находим, и фиксаем.
— и тестировщики проверяют?, спрашиваю я
— не, отдел тестирования у нас есть, но он толком не знаю чем занимается. сами все и тестим. проджекты — американцы в основном.
все всех устраивает.

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

А когда это внутренний продукт самой компании — будут считать трудозатраты.
и «экономический эффект» от наличия/отсутствия тестов.

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

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

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

да, очень часто бывает.

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

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

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

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

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

1. Правильные тесты — пишутся не по коду, а по спецификации/требованиям. Соответственно, за снос таких тестов — больно бьют по рукам.

2. Какой критерий «правильности» кода? Его работоспособность. Что определяет работоспособность кода? То, что его кто-то протeстировал (автоматический тест, сам кодерок, мануальный тестер, клиент в ходе работы с программой).
Когда этот «правильный» код меняется — что будет показателем работоспособности этого изменённого кода?

Ты им не объяснишь :(

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

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

Беда только в том, что этот подход плохо (если вообще) масштабируется.

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

Сложно. Вносишь изменения в существующй код — и вуаля. Либо тесты, либо мануальщикам ручками переклацывать через UI всю связанную с этим функциональность.

А иначе, тестерами выступят клиенты (и им такое не понравится).

И иного — не дано.

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

Пример: в базе есть неудаляемые данные. Хочешь написать тест, способный работать на боевой базе — либо пиши процедуру удаления, либо процедуру обхода безопасности. И то и другое могут заэксплотить.

Хочешь написать тест, способный работать на боевой базе

Что есть «боевая» в данном контексте? Потому как присутствие в одном предложении слов «тест» и «боевая» несколько смущает

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

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

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

То есть тебе не давали писать проектов, в которых есть серии тестов, прогоняемые на боевом экземпляре?

Ддя этого есть staging энв-ы. Иначе, пардон, это называется «слабоумие и отвага». И да, процесс управления тестовыми данными должен быть на нормальном проекте. Все вот эти вот тестовые датасеты, обфусцированная копия реальных данных и т.п.

Вот-вот, отсюда и пляшем, что из примитивной по сути задачи требуется уже ПРОЦЕСС, а это и денежка, и геморой, и требование кому-то сильно в теме отслеживать ИЗМЕНЕНИЯ в проекте и переносить их в процесс. Замечаешь слабое звено?

А задача-то простая: в реальном приложении что-то сломалось. Понять что, понять быстро, и починить. И практически 100% что на стейдже это всё отработало на ура.

А теперь, внимание, вопрос: а кто именно и как готовит стейдж, кто держит его актуальным? Часто это руками, но для процессов с серьёзной нагрузкой и вовлечением людей для этого нужны ПРОЦЕДУРЫ. Грубо говоря, пачка скриптов, которые раз в какое-то время будут вливать свежие данные в стэйдж. И которые будут проверять, чтобы соблюдались процедуры защиты данных (но это уже в код лучше перенести). А ещё, подготовить стэйдж нужно максимально быстро, если нужно срочно решить проблему — и желательно не убив существующий, на котором всё ещё работает.

То есть по сути всё равно требуется солидный объём работы. Или не требуется? Вот в чём вопрос. Можно ли поверх существующего процесса прокладывать тестовые пути? В случае АВРАЛА так и делают. Разумеется, с косяками. Так вот, чтобы этих косяков не было, и чтобы авралов избежать, и нужны встроенные тестовые процедуры как СИСТЕМА.

Хорошо, когда в боевую систему есть доступ. Или плохо, с позиции безопасности? А вот как быть, когда у тебя из доступа только разъярённый человек на другом конце трубки? Когда проблему прятали под ковёр неделю, дав накопиться ошибкам и пролиться в бэкапы? А ты понятия не имеешь, что там сломали. По описаниям же... «ой, выскочило окошко, там было что-то написано, но я его закрыло, красьненькое такое».

Часто это руками, но для процессов с серьёзной нагрузкой и вовлечением людей для этого нужны ПРОЦЕДУРЫ

Совершенно верно.

В случае АВРАЛА так и делают. Разумеется, с косяками.

В результате — хрестоматийный пример — кто-то пытается максимально быстро что-то пофиксить, в нервной обстановке аврала, пишет UPDATE ... WHERE с опечаткой в условии. Или передает некорректный параметр в хранимку. И просто проблема превращается в большую проблему.

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

Поверь, гораздо легче звонить начальству, отвечающему за конкретное звено процесса, когда есть логи работы теста. И знать, что отвечать, когда попробует от**здеться.

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

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

Так что бюрократия только в её параллельном мире есть добро. А в реальности это песец, которого надо обходить десятой дорогой.

В то время как ни с пользователем системы, ни с её кодером, никто нихера не согласовывал — а зачем.

при том что все логические неувязки придется разруливать простому программисту, когда начинает:
if (

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

А теперь угадай, есть ли у программера, который ПОНИМАЕТ логику в деталях — права менять спецификацию, писанные мальчиками с большими яйцами должностями, согласованную между собой за кружкой виски.

Нельзя и не нужно. Т.к. не кодерское это (как правило) дело — спецификации писать/самостоятельно изменять.

Впрочем, бывает такое, что кодер хорошо понимает, о чём в спецификации идёт речь — т.к. такое понимание полезно, для написания кода по ней. Это не означает, что такой кодер понимает все бизнес-триггеры, «подводные камни», реалии предметной области (то, что необходимо для написания/изменения спецификации) — но по крайней мере может найти в спецификации явные баги и о них сообщить.

Впрочем, к хранимым процедурам всё это не имеет никакого отношения. Само наличие хранимых процедур — это дефект кода.

Само наличие хранимых процедур — это дефект кода.

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

Там, где он будет понятен.

Там, где с ним невозможно ничего делать. Тестировать, отлаживать, изменять, вести контроль версий, повторно использовать ...

Там, где с ним невозможно ничего делать. Тестировать, отлаживать, изменять, вести контроль версий, повторно использовать ...

ВОТ ИМЕННО! Работает — и не трогай! Ровно до тех пор, пока не понадобится вскрывать модель данных, менять те самые спецификации. Там и будет прописано наличие процедур.

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

Т.к. не кодерское это (как правило) дело — спецификации писать/самостоятельно изменять.

золотые слова!

я так всегда и говорю, это и есть одно из качественых различий кодера и программиста
програмист — может написать спеку (ведущий, и т.п. может еще изменения внести=взять на себя ответственность, потому что обладает продакт-ориентированным майндсетом, и т.п.)
кодер — не может.

Само наличие хранимых процедур — это баг кода.

мнение кодеров конечно нужно учитывать.

и делать так как считают нужным — программисты на проекте.

програмист — может написать спеку (ведущий, и т.п. может еще изменения внести=взять на себя ответственность)

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

Отсюда и твои суждения, о разработке, тестировании, спецификациях...

это да, на доу мы детсадовцы в меньшинстве

как и в жизни :)

это да, на доу мы детсадовцы в меньшинстве

Здесь в таблице «Difference between System Engineer and Software Engineer :» - примерно то, о чём я тебе пытаюсь сказать:
www.geeksforgeeks.org/...​eer-and-software-engineer

В сложных системах — кодерки не в курсе всех деталей реализации системы (на разных уровнях) — но это от них и не требуется, т.к. на такое естъ сборище системных инженеров (для кадого уровня системы или разных подсистем одного уровня, свой).

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

Да, если ты пишешъ программу, уровня сложности «показать 3 формы пхп» — ты сам и закодишь, и спецификацию составишь, и тесты тебе не нужны. Но есть немало куда более сложных и крупных задач.

П.С. Системные инженеры это из технических проектов. Примерно тем же занимаются бизнес-аналитики — в области софта для финансов/банков.

В сложных системах — кодерки не в курсе всех деталей реализации системы

да. естественно.
но поэтому мнение кодерков о технологиях — самое последнее

но это от них и не требуется,

да, естественно.
так и выстраивалась разработка.

Да, если ты пишешъ программу, уровня сложности «показать 3 формы пхп»

не знаю, не писал
но видел, да. обычно это вебремесленники с фриланс биржи

ты сам и закодишь, и спецификацию составишь

воооот тут уже интереснее, и писал уже в этой теме :)

собственно слово то у нас и другое есть
«гребцы на галерах»
правда там тоже есть и кодеры и программисты
кодер — не может составить спеку, да. ему никто никогда не поручал этого. а по его должностным обязанностям ему этого и не нужно.

Примерно тем же занимаются бизнес-аналитики — в области софта для финансов/банков.

есть роль — бизнес-аналитик
а есть вид деятельности — бизнес-анализ.
то же самое с архитектор и — проектирование архитектуры

и да, кодерки с бооольших проектов обычно не занимаются этими видами деятельности

и поэтому их мнение об этих видах деятельности — можно игнорировать. они — нубы в этом, даже в песочнице не пробовали.

Но есть немало куда более сложных и крупных задач.

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

но уровень понимания этих видов деятельности — такой же.

тесты тебе не нужны

нам нужны, и у нас они есть.
планирую еще добавить.
но не для метрик покрытия кода.
в этом то и разница — с нас некому требовать покрытие как критерий надежности разработки.

с кодерка — требуют. ну, так всегда ж
it depends

да. естественно.
но поэтому мнение кодерков о технологиях — самое последнее

Кодер решает в том, что касается кодирования. Скажем, когда мне «системный инженер» настоятельно рекомендует завязать с тестами, т.к. сроки горят — я его шлю нахер. Поскольку он отвечает за дизайн системы, а я отвечаю за работоспособность кода.

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

Кодер решает в том, что касается кодирования.

да и то, правила для линтера, код стайл обычно не он пишет :)

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

бывает и так. от дизайна системы зависит, компетенций, самих задач.

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

Т.к. по мере роста сложности, при внесении изменений — у них отваливается куча функциональности и это они чинят следующине недели.

и так бывает.
it depends

«системный инженер» настоятельно рекомендует завязать с тестами, т.к. сроки горят — я его шлю нахер.

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

вам вот с другой стороны монитора видать о моем текущем проекте куда больше! даже того что я не вижу :D

А у нас всё работает и «зелёное»...

да, верю, у вас багов на проде не бывает.
потому что юнит-тесты проходят

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

Ну, то есть, мы говорим о подходах к разработке в каком-то гараже, в котором о code review и pull request’ах никогда не слышали? Если так, то я на этом моменте откланяюсь, поскольку обсуждать такое неинтересно.

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

«Ой, всё!» ©
Авторы domain-driven design нервно курят в сторонке, слушая речи непризнанного гения.

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

Мне ли тебе рассказывать о том, кто такие реальные люди, и чего они могут творить под давлением сверху?

Слушай, ну скажи, пожалуйста, где ты увидел в моих словах хоть намёк на бюрократию? Или ты называешь оной code review и pull request’ы? Я без всякого троллинга сейчас, хочу просто «карты мира» согласовать.

DDD — тоже ни разу не бюрократия, это же вообще не про процессы.

нанимаются исполнители, работающие «без возражений».

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

Обычно, всё же, между такими исполнителями и теми, кто давит сверху, есть ПМ / тим лид / архитектор. А на такие роли (особенно, две последние) обычно не нанимают исполнителей, работающих «без возражений», разве нет?

Ну, или мне повезло работать в компаниях, где на такие роли не нанимают yes-man’ов.

Не в компаниях, а в проектах. И либо действительно повезло (и вероятность этого не самая малая), либо не твоя обязанность разгребать последствия.

не твоя обязанность разгребать последствия.

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

мне повезло работать в компаниях, где на такие роли не нанимают yes-man’ов.

Коли читаєш коментарі в таких темах на ДОУ, то на жаль, розумієш, що єдине чого з бажанням вчаться наші програмісти — це ненавидіти інших програмістів.

тут можу сказати цей скіл це цілком такий собі інтернаціонал )) і більш того я їх тут цілком розумію

Скорее обесценивать труды других программистов.

Я, чесно кажучи, саме через це тільки віднедавна «видихнув» і став писати більш-менш розслаблено, а до того з самого 2008 (коли я тут зарегався) чекав якихось ударів з-за рогу. Ну і раз чи два то навіть притягнуло анонімного «доброзичливця»...

Та б’ють по якихось слабких місцях у кар’єрі, для цього достатньо щось десь про це чути.

Розумію, але я саме про ДОУ. З кодом у мене все добре.

Какой то бред в таблице... Узнаю галерный подход.

Лично я спрашиваю по технологиям в разброс от вопросов «отсеять дебилов» (что такое в С++ виртуальный деструктор? А виртуальный конструктор?) до вопросов посложнее (нюансы использования динамической памяти в жёстком реал тайме), а в завершение идут open ended questions с продакшена — на поболтать и посмотреть куда мыслит человек и насколько далеко он может зайти в своих размышлениях.

что такое в С++ виртуальный деструктор? А виртуальный конструктор?

Контора С++ компілятор пише?

Контора С++ компілятор пише?

В «плюсах» виртуальных конструкторов не существует. И вызов виртуальных функций из конструкторов — это очень плохая вещь.
И неспроста.

І що? Ну от дізналися чи знає людина про це чи їй доведеться колись 20 секунд витрати щоб дізнатися. А як визначити чи підходить вона компанії/проекту?

Ну от дізналися чи знає людина про це чи їй доведеться колись 20 секунд витрати щоб дізнатися.

Это азы «плюсов». Уровень даже не миддла, а начитанного джуна.

К тому же, если неподготовленный «синьор» поставит «virtual» перед конструктором — компилятор его поправит. А вот насчёт вызова виртуальной функции из конструктора — не уверен (максимум, будет предупреждение, а многие и просто проглотят).
А потом начнутся всякие неприятные и сложно-находимые вещи...

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

Это азы «плюсов». Уровень даже не миддла, а начитанного джуна.

Я з цим не сперечаюся. Моє питання — як знання цього факту який можна дізнатися за кілька секунд показує відповідність кандидата проекту чи компанії в цілому?

за кілька секунд

взнати чи чувак знає базвордс чи зовсім нуб

Ну то правильний сеньйор має сказати «не знаю є вони там чи нема, але якщо проблема саме в цьому то можу їх вам тут на дошці і реалізувати зараз». Щось типу такого?

завдяки цій темі тепер зможу пройти левел

«отсеять дебилов» (что такое в С++ виртуальный деструктор? А виртуальный конструктор?)

uk.wikibooks.org/...​ртуальний_конструктор_С+

а раніше би провалив інтерв"ю на сінйора :)

а раніше би провалив інтерв«ю на сінйора :)

тю та изи )) на что подопытный получает встречный вопрос за фабричный метод против абстрактной фабрики с предложением по рассуждать кого куда совать и своими честными миддл $2500 «по результатам интервью» )) ничего личного просто бизнес

ЗЫ: на самом деле вопросов за виртуальный декструктор и вообще виртуальные функции более чем достаточно для понимания есть ли понимание или же ж есть просто заученное по методичке а реальной практики разбирательства 0.0

фабричный метод против абстрактной фабрики

вилкой в глаз или в жопу раз

Моє питання — як знання цього факту який можна дізнатися за кілька секунд показує відповідність кандидата проекту чи компанії в цілому?

Если чел описывает себя синьором, но не в курсе основ «плюсового» полиморфизма (а это основа «плюсов» — собственно то, что отличает «плюсы» от «си») — что-то тут не так.

Між сеньйором який ніколи не писав на плюсах чи писав дуже давно, і сеньйором який вміє лише в одну технологію (навіть якщо це С++) я виберу не того хто знає на пам’ять про віртуальні деструктори, а того хто вміє розв’язувати задачі і тягти проекти і фічі до завершення. Хіба не логічно?

Для мене ці питання про якісь нюанси наче ми на іспиті на 3-му курсі виглядають дивно — людина потрібна як довідник з С++, чи може щоб робити щось осмислене все ж таки?

Как по мне тут тонкий лед. С одной стороны вопросы типа «порядок, тип и количество аргументов, передаваемый в условный strcpy?» попахивают идиотизмом. С другой стороны — незнание о существовании виртуальных деструкторов может привести к тому, что софт потечет памятью. Потому что при таких раскладах можно договориться до «человеку не обязательно знать, что нужно удалять память после выделения в системах без garbage collector.» Ну или «человеку не обязательно инициализировать переменные»

софт потечет памятью.

дик для цього є Го, або Руст

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

хіба хто проти... це ж можна доїти клієнта роками ...

Угу, в аутсорце. Пойди в продукте расскажи что «а теперь вам нужно переписать весь продукт на Го, который сейчас денег генерит». Вместо того, чтобы этот продукт дальше развивать.

це ж можна доїти клієнта роками ...

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

что отличает «плюсы» от «си»

гетери — сетери, нєа?

нет конечно )) на плюсах есть stl а на си stl нету и без stl плюсы ничто а точнее «плюсовики» просто потому как грубо большая часть 80%+ современных «плюсовиков» это на самом деле «джава стиль на stl»

не в самих плюсах, а в стандарті,
ще буст є, який тепер в стл, тобто в стандарті
а ще темплейти, і метапрограмування...
та мало що там є... ромбічне наслідування ... втаблєс...екзепшени ... РТТІ ... і т.д....але найбільше там UB...

то був натяк одного із трьох китів (приховування даних, яке насправді не є приховуванням) ООП ООД, яких тіпа нема в С

Ну ще скажи що Пітон не Пітон бо усе публічне

self.__priv = «Hello»
А вот protected как в плюсах там реально не хватает

self.__priv = «Hello»

Это фиктивная приватность, т.к. такие функции/поля можно пользовать извне — было бы желание.

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

натяк одного із трьох китів

Главный кит — это полиморфизм, как средство объектно-ориентированности/абстрагирования. Всё остальное (включая "гетeры"/"сетeры«) достаточно легко реализуется средствами «си» (или этому есть «сишные» аналоги) — и незачем лезть в «плюсы».

Впрочем, полиморфизм тоже реализуется на «си» — но сложно. И в принципе, только лишь если он нужен — есть резон пользовать «плюсы». В прочих случаях, от пользования «плюсов» вместо «си» — лишь минусы на многих уровнях.

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

Ну, если честно, то вот со строками в С очень сложно работать. И со списками.

Есть полно сишных контейнеров. Кода при использовании получается несколько больше, чем при аналогичных, скажем, СТЛьных — зато гораздо прозрачнее.

В С и со сборкой мусора сложно работать. Да, да, руками пишем деструкторы, даст ист фанстастиш

В С нет деструкторов и сборки мусора. Деструкторы только к С++ завезли, и это была киллер-фича — остальное спокойно делалось (и делается до сих пор) ручками в С.

Впрочем, полиморфизм тоже реализуется на «си» — но сложно.

не не сложно просто берёшь таблицу «методов» и всё

почти весь линукс так и построен а скажем «файловый дескриптор» или handle в win32 api суть есть всё та же ж «абстракция системного полиморфизма на прикладном уровне»

не не сложно просто берёшь таблицу «методов» и всё

Это я называю «сложно».

Структура с указателями на функции (класс) — это ещё куда ни шло.

Но завязываться на реализацию таблиц виртуальных функций — это уже будет код, непригодный для последующего сопровождения средними (понятно, «сишного» уровня среднести — который высок) спецами.

По-моему, это очевидный подход, на уровне «виртального деструктора» для С++ джунов.

Но завязываться на реализацию таблиц виртуальных функций — это уже будет код, непригодный для последующего сопровождения средними (понятно, «сишного» уровня среднести — который высок) спецами.

А чем тут foo->functions->put(foo, x, y) хуже, чем foo->put(foo, x, y)? Или вы о чём-то другом?

Наприклад ці таблиці можна динамічно модифікувати і тоді простим читанням коду буде дуже складно відстежити які самі методи викликають.

і тоді простим читанням коду буде дуже складно відстежити які самі методи викликають.

ну да але те саме працює і для будь якого «класичного ооп поліморфізму»

І що? Ну от дізналися чи знає людина про це чи їй доведеться колись 20 секунд витрати щоб дізнатися.

Отсеять дурачков которые вписали себе в тайтл — Senior, а по факту сыпятся на глупейших вопросах

А як визначити чи підходить вона компанії/проекту?

А это я узнаю на сессиях с open-ended questions, которых у меня с продакшена за пару лет накопилось вагон и маленькая тележка. Было ж написано:

до вопросов посложнее (нюансы использования динамической памяти в жёстком реал тайме), а в завершение идут open ended questions с продакшена — на поболтать и посмотреть куда мыслит человек и насколько далеко он может зайти в своих размышлениях.

Стек опрашивал я. Но не дотошно — нет смысла. Доучить недостающее уже на месте можно.

Отсеять дурачков которые вписали себе в тайтл — Senior, а по факту сыпятся на глупейших вопросах

А якщо цей сеньйор писав в останнє на С++ 15 років тому і може перевернути список за пару хвилин?

А это я узнаю на сессиях с open-ended questions, которых у меня с продакшена за пару лет накопилось вагон и маленькая тележка

Тоді чому одразу не почати з цих питань?

і може перевернути список за пару хвилин

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

Это как дедовщина, так и здесь, ток дедов в армии замени на преподов в универах, которые задрачивали на экзаменах потому что жизнь не удалась ну или их в также задрачивали.

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

Те же кто сам был туговат и читал лекции с методички — задрачивали теорией.

ЗЫ у меня специальность вообще не прогерская.

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

О, у нас физик такой был, которому весь поток в конце каждого семестра вставал и аплодировал (в буквальном смысле, из года в год).
На экзамене был лимит кажись на 5-10 минут на использование литературы. Типа если знаешь где искать, то найдешь и воспользуешься. А если весь семестр клал на учебу — то и не будешь знать куда смотреть.

Віртуальні конструктори були на Дельфі

В «плюсах» виртуальных конструкторов не существует.

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

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

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

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

Это вопросы уровня детского сада

В чому сенс їх задавати? Можна ще про кольори веселки спитати.

про кольори веселки спитати

цветовая дифференциация штанов

Контора С++ компілятор пише?

Несложный продукт — графика-визуализация на проекторы/мультитач дисплеи.

От і дивно — в такій області має бути повно невеликих задочок на спрощених версіях яких можна оцінити чи підходить людина. Для чого питати про триграфи та інше, що не стосується безпосередніх задач?

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

От і дивно — в такій області має бути повно невеликих задочок на спрощених версіях яких можна оцінити чи підходить людина.

Эти вопросы я тоже задавал, так как проект с рендерингом связан, вот одна из задач — «нам надо отрендерить белую комнату в которую светит солнечный свет через окно и попадает на стол с посудой, как сделать такое что б было красиво и презентабельно? фпс-ом пренебрегаем»

Вопрос был больше о понимании алгоритмов рендеринга. Встречный вопрос (который мне понравился) — «а что означает в этой формулировке <красиво>?» (на то это и был open ended question). Я ввел уточнение — «что б не было пересветов на белых шторах и участках где светит солнце (например видна фактура белой стены), а в темных углах под столом не было шума и пиксели не ушли в ноль по всем каналам». В ответ я услышал разные интересные вещи от HDR до разных форматов float-текстур 16 и 32 битной точности, а так же логарифмических преобразований по яркости (что б правильно свести широченный HDR диапазон с солнечным светом в LDR 0...255 и не потерять данные ни в тенях в углах, ни на ярких подсвеченных прямым светом участках). И данный ответ только один из возможных, можно упомянуть трассировщики лучей, можно рассказать про фотон маппинг, а можно и про лайтмапы статические.

Такие задачи подходят? :)

Возможно в твою компанию надо другого характера вопросы задавать. Все зависит от масштабов и типов задач. У нас маленькая компания, и людей мало работает, и цена ошибки низка и вообще багофиксом можно заниматься по 2 месяца сдвигая релизы. Был бы я в компании уже человек на 50 — скорее всего надо по другому опрашивать кандидатов. Не зря по собеседованиям целые книги написаны.

ясно геймдев, проходим мимо

вообще не угадал

а вот в рендер за 16мс ты похоже не умеешь

Шото поизмельчали «синьёры-помидоры»
sharpc.livejournal.com/67583.html

По ссылке «Теоретический минимум программиста»?

Он самый

Ну и это ж само собой «минимум» — то есть на джуна гдето.......

с такой теорией на практику времени уже не останется

Ты не сеньор, если, например, не умеешь в GoF, а потому и денег (столько сколько ты требуешь) тебе не дадим. На совершенно законных основаниях. Чтоб сеньорить надо ооооочень много знать. Так что сойдемся на мидлознаниях и мидловознаграждениях. Как, ты даже мидло не шаришь? Что значит, я в табличку дописал незаметно? Что значит, раньше это не требовалось? Не, ну если не знаешь, то какой же ты мидл? Вот тебе прибавка джуна к зарплате джуна и все..

Як це ск1льки? Я хочу синтезировать из свинца золото, а у меня нет денег на оборудование... Куда это годится??

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

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

Не стоит заниматься подменой понятий, да еще и настолько неуклюжей. Речь в основном шла о том, что синьор должен ясно представлять бизнес-контекст конкетной задачи с точки зрения реализации и NFR, а не заменять отдел маркетинга и сейлзов у заказчика на полставки.

безупречно тестировать,

У меня в команде синьоры всегда ревьювили интеграционные тесты. Не с точки зрения деталей имплементации, а чтобы удостовериться что неочевидные сценарии не упущены.

архитекторы в конце концов

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

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

Что аж вспомнилось:
Делись со мною тем, что знаешь,
И благодарен буду я.
Но ты мне душу предлагаешь —
На кой мне чёрт душа твоя!..
(Шиллер, пер. Лермонтова)

Вовлеченность это не чуйства а лояльность — это не продажа души :)

Критикувати цю таблицю можна, адже вона виписана через призму досвіду однієї людини. З однієї сторони там є дуже специфічні речі, от як cdn (поки раз-другий не зробиш — знати не будеш... там ой як все не просто), з іншої сторони, можна знайти речі, які тут не згадані (якщо мова про веб, то нехай web socket чи webgl).

Але в цілому, має право на життя.

Мене дивує реакція багатьох коментарів. Адже битий розробник, як мінімум з 80% цього всього мав би бачити на своєму шляху .... і не тільки цього а й ще стільки ж.

Шановні «senior»-и, вважайте цей перелік нижньою планкою. Якщо ви щось вважаєте тут непотрібним знати, можете помігяти на щось рівноцінне (наприклад, той самий cdn на webgl).

На жаль, 90% коментаторів заходять в цю тему, щоб вилити лайно на автора

З усього, що я прочитав тут, як на мене, ми маєм не достатньо інформації для такого висновку.

З іншої сторони ... чим відрізняється досвід зрілого розробника 1 рік технології Х від 5 років? Як на мене, той що 5 років працює буде знати ну від сили на 15-20% більше і то далеко не факт.

Винятки з попереднього є (в основному науковомісткі, чи мож hardware близькі), але точно не у вебі.

То ж стратегія «ходити по верхах» — це дуже навіть виправдано, з розумним підходом і якщо «верхи» є достатніми для того, щоб, наприклад вміти самостійно підняти новий проект на відповідній технології.

Ми стараємось на старті кожного нового проекту робити якесь review технологій/підходів. Саме на таких рейках ми впроваджували dagger (server side), java modules, prometheus, gitlab ci, kotlin (server side), http api на корутинах, так ми перейшли на з java android на flutter, тощо.

Якісь речі/підходи портуються на старих проектах, якісь плануються портувати, якісь ні, якісь проекти «працюють і добре». По технологіях треба ходити ... проекти треба портувати/переписувати ... інакше, дуже швидко стек безапеляційно застаріває і потім і проект підтримувати стає дуже важко (як от в нас є одне java 8 32bit (що вже пару років як треба в deprecated), яке важко кудись зсунути), так і навички залишаються там же.

А працювати коли

Навчатись через роботу, працювати через навчання, навчатись після роботи, жити в проміжках між усім цим). «Вічний студент» — це наше прокляття ))

Звісно, бувають задачі, коли треба взяти і по прокладених рейках зробити шмат роботи. Але практично завжди, мінімум 20% роботи (наприклад, в місячному терміні), можна спланувати так, щоб це було з виходом за межі звичного стеку.

тягнути github ci, якому рік від народженя

В нас був CI на Bamboo до того.
Після нього CI на gitlab — це був ковток свободи і свіжого повітря. Виправдав себе практично через місяць. Тільки що варте білди в контрольованих середовищах в docker контейнерах. Зараз у нас всі білди в контейнерах, крім ios. І коли ми налаштовували на ios runner, я згадав, що то за пекло, коли тобі потрібно обслуговувати runner (то версію чогось міняй, то на диску щось видали, то система якесь оновлення просить).

Щодо нового інструменту ... на self hosted gitlab ми перейшли на початку 2016го, на gitlab ci десь через 11 місяців. ± десь і тоді починали впроваджувати контейнеризацію по серверах. Я вам скажу, в цих всіх «нових» технологіях ми не зіштовхувалися з «непереборними багами». Були відсутність якихось фіч, які б дуже хотілося, але то таке.

скрипти в бранчах

Це одна з основних переваг — проект розвивається скрипти міняються. Завжди можна зробити будь-який білд будь-якої версії і все буде коректно.

VSTS була якась

Я вийшов з microsoft-ського стеку десь в той час, коли тільки цей інструмент випускав свої перші версії. Тому предметно порівняти не зможу.

І скільки людьских місяців праці витратилии на написання екшнів і розмноженя воркфловів по репам ?

Не зовсім зрозумів питання, якщо чесно. Звісно на те, щоб .gitlab-ci.yml + обв’язку до нього зробити знадобився час. Але на той момент нам багато і не треба було. Я б не став міряти місяцями. Та й еволюціонували білд скрипти з проектом. А той час, що ми потратили, був з запасом зекономлений на білдах-тестах-деплоях.

якому рік від народженя

Найбільш ризикованим для нас був не gitlab. Ризикованим був flutter, якому як раз і був рік від першої версії. Тоді і мова нова, архітектура UI ні на що не схожа, купа ліб під одну задачу і майже всі в беті та з github-а з малими community.

Це був дійсно ризик ... але пройшло вже понад рік, і я вам скажу, що кращої платформи для розробки UI я ще не бачив на своєму скромному шляху (якщо порівнювати з Delphi, MFC, Windows Forms, WPF, JavaFx, HTML+CSS+JS, Android, Swift).

чим відрізняється досвід зрілого розробника 1 рік технології Х від 5 років? Як на мене, той що 5 років працює буде знати ну від сили на 15-20% більше і то далеко не факт.

другий має більше набитих шишок і обійшов більше граблів

Це абсолютно вірно ... але суть в тому, що ці шишки та граблі дуже швидко забуваються і через рік-два «десь я таке робив ... треба глянути отой репозиторій», а через 5 ... ну ... 10 років тому я писав на C# ... я зараз, звісно, можу писати на C#, можу поправити щось в старих проектах ... але, щоб по нормальному там щось робити, треба розбиратися заново. Ну і про граблі та шишки я там слабо вже щось пам’ятаю.

Тобто, кінець-кінцем, мілкі граблі «новачком» гугляться на stack overflow за хвилину, а більш важливі тренують в людини відчуття того що є добро чи зло в сфері. З часом це все сильно обезцінюється. Тому я і дав людині з більшим досвідом 15-20% «чогось» більше, хоча на відрізку 2-5 років це може бути і 5-10% а то і менше... По суті, немає чого вчити майже в будь-якій сучасній технології більше року. Решта часу — то збільшення кута зору, просвітлення, війна добра зі злом, прекрасного з огидним, тощо.

суть в тому, що ці шишки та граблі дуже швидко забуваються і через рік-два «десь я таке робив ... треба глянути отой репозиторій»,

це не про то, мова іде більше про підходи щодо вирішення проблем/задач, а не про код.

мілкі граблі «новачком» гугляться на stack overflow

граблі гугляться досвідом чи читанням літератури, а на стековерфло гуглиться «реверс строки»

часом це все сильно обезцінюється. Тому я і дав людині з більшим досвідом 15-20% «чогось» більше, хоча на відрізку 2-5 років це може бути і 5-10% а то і менше... По суті, немає чого вчити майже в будь-якій сучасній технології більше року.

є «фундаменталс» і досвід, який не незнецінюється, на відміну від знання «модних фрейморків».

є «фундаменталс» і досвід, який не незнецінюється, на відміну від знання «модних фрейморків».

Хех ... це вірно, і це та думка, яку я часто намагаюсь донести. Але на фундаментальних знаннях в нас хайп не ловлять, нажаль.

Якщо повернутися по моєї початкової тези, то я говорив про досвід зрілого розробника в якійсь технології.Тобто, вже маючи якийсь фундамент в, наприклад java, можна мати рік досвіду в C#. І теза полягала в тому, що, наприклад, 5 java+1 C# не сильно відрізняється (в знаннях C#) від 5 java + 5 С#.

Ну і, fundamentals та досвід ... то як м’яз .... накачати важко, підтримувати легше але вимагає постійної роботи, а якщо нічого не робити, втратити тонус дуже легко.

якщо ти сам матрицю транспонував в універі, а не списував у сусіда, то як це робиться ти і на пенсії знатимеш,

а якщо тебе цікавили відмінності UB конструкторів в різних версіях С++, то це не фундаменталс, а саме

вимагає постійної роботи, а якщо нічого не робити, втратити тонус дуже легко.

хоча б тому що стандарти С++ швидко змінюються

матрицю транспонував в універі,

Це не зовсім так ... наприклад, жорданову форму матриці я зараз ось так не згадаю і не зроблю, оскільки після курсу лінійної алгебри жодного разу не використовував. Цей «м’яз» все-рівно треба качати ) Він не так швидко атрофується, але атрофується.

Кажется я понял — я общаюсь упаковками вроде:
const newUser = { ...user, ...update }
Но я шизофреник (болезнь нервов такая) поэтому и не понимаю, зачем программистам гоняться за шизофреническим мировосприятием?
И да, я собираюсь использовать вассаби энжайн для оптимизации кодирования других собственных разработок.
Алгоритм на настоящий момент времени такой:
Программист составляет модель на естественном языке.
Компьютер выбирает подходящий язык программирования и генерирует детальный шаблонный код.
Программист исправляет ошибки в этом коде, добиваясь, чтобы тесты прошли.
Для trainee задач думаю трудности не составит такую схему запилить.
И еще, вассаби это НЕ готовый программный продукт, а просто модель, вроде модели планера.
Вы ведь не летаете на модели планера, несмотря на то, что эта модель может летать?
P.S.
Это все написано предполагая наличие заинтересованных в продолжении разработки движка.

Пропущенное НЕ в правилах что ли всему виной? Всему этому бардаку на нетфликс?

Може вибирати, створювати алгоритми для складних задач

Ну-ну. Мне вот просто интересно, что автор подразумевает под «алгоритмом для сложных задач» и насколько часто это нужно среднестатистическому веб(!)-помидору. Львиная доля уже сделана до нас.

«Подумаешь! Я ещё и вышивать могу, и на машинке — тоже...»

Так виріс же за рік у кожного!

Бред, вы трейни перепутали с джуном, а синьора с мидлом. В крайнем столбце у вас требования не более чем на мидла (ну что такое «знает основные Х»??)

поддерживаю. я вообще считаю что в крайнем правом столбце требования на трейни из какого-то зажопинска.. не говорю уже о Киеве. о каких сеньйорах вообще там речь.

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

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

не уверен, что сможет тягаться с порнхабом.

Это все уже прошлый день. Я открыл кое-что поинтереснее.

раніше було «якщо в тебе менше чим $2500, то ти не сенйор» , зараз, думаю планка $4000

Если дело только в деньгах, то пусть хоть джуном называют.

В США всё, кроме денег — просто так. ©

Вспоминается фрагмент (примерно) из цикла «Молот и Крест» Гарри Гаррисона:

— что надо сделать чтобы стать королем?
— стань в центре каждого селения и объяви себя королем. Если ты обойдешь так всю страну и выживешь то, стало быть, ты и есть король.

Если ты прошел на синьора и другие синьоры считают тебя синьором и тебе платят как синьору, то ты и есть синьор.

Если ты прошел на синьора и другие синьоры считают тебя синьором и тебе платят как синьору, то ты и есть синьор.

duck typing ))

Не проистекает ли требование к элегантности кода (что конечно же хорошо) в основном из интересов поглотителя/заказчика ?
Если код жуткий, понять его сможет не каждый и такие специалисты (как я например) очень редки, а следовательно очень дороги.
Обычные кодеры обычный код поймут за меньшее количество часов, чем они же, но код жуткий (например, мой)

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

Для заказчика элегантность кода находися в шестом приоритете.

ровно до тех пор, пока этот код не надо мейнтейнить

как раз наоборот. хотя, смотря что подразумевается под

элегантность кода
элегантность кода

не крешиццо :)

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

а если это не твой код? и смотришь ты на него впервые?

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

рядовое ооп как раз понимаемо легко, поскольку синтаксис и идея базируется на математических выражениях и точках.
А вот код рядового функциональщика в стиле -> (() -> { ()->{}, ((), ()-> {[]} хрен кто разберет

Вы просто ООПшник. Функиональщина не страшна как кажется

А вот код рядового функциональщика в стиле -> (() -> { ()->{}, ((), ()-> {[]} хрен кто разберет

у вас три незакритих дужки

у вас дві незкритих дужки
у вас три незакритих дужки

Спасибо :)))
Твой комент — отличный индикатор хреновой понимаемости фп-кода.

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

Та то я просто на глаз скобок и стрелок насыпал типа функция функции функцией функцию функционально вызывает передает вызывая передачу вызова в вызов функции вызова функции.
Ну ты понел )

да понєл, єстем троха рустаманем

Я через полгода смотрю и ок. И через два. Дело в скорости вспоминания. Чем больший промежуток времени от последнего использования/просмотра прошел, тем большее время срабатывания/всплывания воспоминания.
Но — знаю — когда помню.
Простота, атомарность, компактность, защищенность = элегантность
У каждого свое понимание что такое элегантный код (долго много любовно вылизанный и покрытый тестами) и чем он отличается от кода на скорую руку (лишь бы работал)

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

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

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

Я считаю пальцы на руке так: 1-2,2-3,3-4,4-5
Итого 5. Первый 1, Последний 5.
А те, у кого нет моих возможностей, талантов, особенностей реализации так:
1,2,3,4,5

по 10 минутах как закончил писать этот код

 — это уже диагноз коду.

Верно. Элегантный код пишется / уточняется вечно ибо он всегда немножко не совершенен.
Критерий состязания — упрости мой код, но чтоб тесты прошел. В том числе и на отсутствие в коде упаковок.

Вот именно... Элегантный код порождает минимально возможное количество ивентов.

нет, мне нипанятна, что ты имеешь в виду

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

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

Ты open source имеешь в виду, типа все, что не открыто — в топку?

Путь DIY это когда легко разбирается и потом легко заменяется элемент или элементы и легко собирается и потом работает.
Смени стекло для мобилы в домашних условиях. Не можешь? Тогда мобила такая это не путь DIY

Карму никто не отменял.

Так-то да. Но со стороны программиста было бы наивно предполагать, что заказчик будет изначально понимать такие вещи. Это уже задача программиста донести до заказчика, мол, «если вы хотите максимально быстро получить решение сейчас, то мы можем наговнокодить за месяц, но суппортить это будет дорого; если дадите нам два месяца, сделаем по красоте и внедрять новые фичи / фиксить баги в этом будет намного дешевле».
Заказчик с небольшим опытом работы с командами программистов может и не понять, конечно. Но если он уже имел дело с проектами, которые живут больше года и в которых нужно регулярно что-то добавлять, улучшать или фиксить, то наверняка задумается и примет решение уже с учётом полученной информации.

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

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

It depends. Якщо планується, що продукт буде жити багато років, поступово розвиватися, релізитись у нових версіях, що буде активний суппорт/багфікс, то так, якість коду повинна бути дуже важливим фактором для бізнесу (але нагадувати про це повинна девелопмент команда, щоб замовник давав їм достатньо часу на всякі рефакторинги і стабілізацію). Якщо ж планується випустити продукт швидко і 1) забити на його підтримку взагалі, 2) підтримувати не надто активно, вифікшуючи тільки критичні штуки і не розширюючи функціональність, 3) підтримувати активно, але бізнесу ну от ппц як важливо зарелізитися зараз, бо потім пізно буде, — якість коду може відійти на другий план, віддавши пріоритет швидкості розробки. Такі ситуації також бувають.

Згадаємо класику:

Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.
Згадаємо класику:

помилка вижившого

помелрим видніше)

Бізнеса з низькоякісним продуктом довго не живуть

Качество кода относится к так называемому «структурному» (внутреннему) качеству, которое далеко не всегда воспринимается и ощущается конечным потребителем.

Грубо говоря, купил ты музыкальный центр. Звук качественный, все заявленные функции работают. Если ты сам не электронщик, тебя сильно будет волновать, какое там «воронье гнездо» из проводов внутри, и сколько схемотехнических костылей вбили инженеры, которые его разрабатывали?

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

применительно к стартапам может и так, а для всех остальных действует принцип — Too Big to Fail

Фикшу код после таких сеньоров — недорого — 100$ час

Вот только что интересный пользовательский опыт «надыбал» / приобрел:
Захотелось сапоги, пошел искать. Отмел в сторону магазины с неудобным интерфейсом.
И еще «(по возрастанию/по убыванию)» не.
Лучше «(от 0 до 100 / от 100 до 0)»

А что, если некто умело находит ошибки?
Вот посадят его перед чужим кодом и скажут: разберись, почему не работает этот код.
Что это за несчастный? Сойдет ли решение такого задания за прохождение собеседование?

сіпасібо завдяки вам я зрозумів що є джуном і буду джуном до кінця днів своїх.

Якщо у вас буде сеньорская зарплата, то яка різниця?

то була іронія. Бо на оцей весь поділ мені начхати. я маю те що я хочу і в що я себе оцінюю. коли мене питають а ви сіньор я кажу — а біс його знає чітких критеріїв з палати мір і ваг досі нема тому називайте як хочете. Вмію те і те хочу то і то. І всьо. Ганяння за статусами вважаю дитячими забавками.

Привет, а ты точно техлид по вебу в продакте?
Тогда расскажи мне минимум две веб-технологии обеспечения платных онлайн-чатов без использования стейта серверной части. Да, заодно включи туда минимальный антифрод.
Рассказ веди так, будто объясняешь 8-и летнему ребенку.

Цікаво послухати ваші відповіді на власні запитання

Кто был на мастер-классе на последнем оффлайновом девопс-стейдже — тот слышал

Отак все і є. Спочатку одні складають таблички, а потім інші лікують синдром самозванця.)

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

Хто створює таблички, і є самозванцями ;)

Найкраще синдром самозванця лікує проведення співбесід, перевірено :)

Приходит на память афоризм Козьмы Пруткова «Специалист подобен флюсу, полнота его односторонняя»

В разделе архитектура, почему-то метрики кода, хотя они должны быть в разделе Код.
В разделе Код почему-то говориться про уровень знания языка программирования и его ограничения.
Алгоритмы как-то уж очень поверхностно, типа слышал-видел-может, это не по сеньерски, можно было бы накидать хотя бы пару-тройку слов в тему, типа divide-and-conquer, динамическое программирование, графы и т.д.
Тема Баз данных не раскрыта, кроме реляционных есть NoSQL базы данных и CAP теорема относится в основном к ним, как впрочем и шардинг. Под деформализацией наверно имелось в виду денормализация?
Тоже самое про Безопасность, а как же типы угроз, уровни предотвращения угроз, а что про клауд?
И т.д. и т.п
Видишь эту «таблицу знаний» и сразу понятно, что за сеньер её придумал и для чего)
Жаль что Vladyslav решил остаться анонимом, имя продуктовой веб компании тоже была бы интересно, страна должна знать своих героев.

Давайте устроим состязание таблиц?

Насправді я б усе це поміняв лише на 1 фактор: код зрозумілий, без зайвого ускладнення. Читай — код буде добре працювати, мало багів, не потребуватиме покриття 100500 тестами (які значно менш зрозумілі, ніж код), і найголовніше — такий код є продуктом, який потім легко підтримувати та розвивати. А не говнокодом, який дешевше викинути та переписати з нуля.

А ото лайно що ви понаписали — зветься БЮРОКРАТІЯ. А бюрократія є або доброякісною пухлиною, або злоякісною (що частіше), і вбиває бізнес незалежно від його успішності.

PS. Бог створив світ за 6 днів, бо йому не треба було робити його сумісним з минулими версіями.

Принцип наименьшего удивления работает всегда :)

Я видела красивый код с багами. Написали красиво но 1) не учли все нужные edge cases 2) нет корректной обработки ошибок и вся система крешнется если что-то пойдет не так 3) если произойдут race conditions (придет два запроса к одной сущности почти одновременно) то произойдет deadlock. А код-то красивый, выровнен как под линеечку, переменные названы как будто боженька называл.
Аа еще фича-киллер: код красивый но грубейшая security ошибка когда какие-то credentials отдаются в JSON ответе сервера. Бери не хочу.

У младенчиков в IT 99.9% ошибок в коде, у джунов 30%, у мидлов 20%, у сеньоров 0%

у сеньоров 0%

Oh my sweet summer child

Наивный. Как раз у младенчиков ошибок меньше. А вот у мамкин-синьор-архитектов...

Или хотя бы Clean Code. Красиво научился, качественно еще нет.

вы так говорите, как будто это что-то плохое

Навпаки, якщо ти писатимеш код по SOLID, він буде щонайменше втричі монструозніший, і найголовніше, незрозумілим. Бо люди не логічні, їм важко буде і читати тупі абстракції, і правити їх, а шукати помилику то може й місяці зайняти.

Для людей SOLID є обфускацією. KISS — от що треба прийняти за аксіому.

KISS my SOLID
(нова парадигма розробки)

чого ж про нього, СОЛІД, тоді так волають на кожному кроці?!

Про геїв теж волають, здебільшого ті хто сам не в темі.
Так і про SOLID — зазвичай лише манагери кукурікають та джуни вухасті. Доки їм не дадуть читати чужий код за усіма канонами соліду написаний.

вот именно.
подобные дефекты кода — я постоянно и заворачиваю на код ревью. это основная причина.
причем «удивляюсь» про себя нередко — а чё, это разве не очевидно было, что его еще и увековечивать кодом нужно было?

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

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

Третий основной вариант — ты сам это писал, просто уставшим

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

А по поводу кода под линеечку — как раз это ошибка. Код не должен красиво выглядеть. Он должен читаться. И красиво выглядеть только издали, блоками и структурно. Но не так что jf в 5 строчек и 3 табулятора.

В остальном... это свойственно как раз таки прокачанным рабочим лошадкам, те кого «обучили», но сам учиться не имеет. Те, кто входил в IT с собственных проектов, наоборот, скорее неправильно назовут переменные (потому что надо БЫСТРО кодить, а не мозги полоскать), но вот на секьюрити и прочие грабли потратят 90% времени.

В остальном спецы нужны разные. И если где-то нужно велосити, а не качество — так тому и быть. И если в вашей конторе ОЦЕНКА ведётся именно по скорости и это ключевой показатель — то вам такой спец нужен.

PS. А вот по поводу переменных «как боженька назвал» — покажите пожалуйста. Потому что это на словах красиво звучит, но когда начинаешь пытаться понять что оно зачем — понимаешь что и боженька с именами явно не синьор, даже сынулю не мог назвать чтобы это однозначно писалось со слуха. А детское имя как — ися? изя? исюсик?

Ну вот поэтому ви и лид а не синиор. 2. Между спагетти кодом и лазанья кодом я все же выбираю лазанью. Туда легче добавить всего чего в нем не хватает и изменить то что нужно. Мешанину «с душком» (с. Мартин Фаулер) надо рефакторить, бывает и так что иногда дольше чем с нуля написать.

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

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

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

Для понимания: в сказке Конёк-горбунок ≈3000 строк. А теперь прикиньте, как бы она выглядела с полным соблюдением SOLID-бюрократизма.

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

побачивши на першому ж слайді текст фонтом Comic Sans — вирішив далі не читати.

Страсть говоришь? Да лозунг 98% здесь сидящих звучит «И так сойдёт!»

фанатов своего дела или просто трудоголиков.

Как ты красиво переформулировал «задрот-ноулайфер» :)

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

НА САМОМ ДЕЛЕ, senior — это человек, который обладает адекватным опытом, более-менее знаком с доменной областью, и базируясь на этом, может самостоятельно проанализировать бизнес-проблему, адекватно оценить время на ее решение, и решить ее в срок согласно своей оценке с приемлемым качеством кода, на уровне обычного middle-программиста. Все.

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

Все.

не все.
синьор — это еще и софт скилы, обычно. благодаря которым он лидить может, немножко, и менторить, чуть-чуть.

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

софтскилы — вот окончательная точка в разнице.

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

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

Это подразумевается. Без софтскиллов обычно сложные проблемы не решаются, так как сложные проблемы подразумевают обширную коммуникацию в самых разных направлениях.

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

работает я проверял ))

ЗЫ: ну и да одно другого не отрицает но чаще возможность скоммуницировать как-то находится а вот возможность оборзеть сложную проблему до её решения уже не всегда и если ты таки умеешь делать последнее тебя таки будут старательно слушать и помогать «с коммуникацией» а вот наоборот это уже чистый трёп это боюсь уже не за компьютеры )) в политику может?

синьор — это еще и софт скилы, обычно. благодаря которым он лидить может, немножко, и менторить, чуть-чуть.

ну да ну да и шапочка ))

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

если синьор может ещё и самоорганизоваться в команде синьоров то это вообще уже идеал супер синьор я бы б сказал но чаще это банально «реальный лид» здесь «реальный» это термин для той реальности с которой реально приходится иметь дело

ЗЫ: ну может в фхтангах это и не так

софтскилы — вот окончательная точка в разнице.

а ну ок ))

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

Бессмысленно знать миллион фреймверков

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

если все равно не знаешь как из применить на практике для решения бизнес задачи.

ну вот одно из отличий тоже, синьора от мидла
синьор в первую очередь думает о бизнес задаче, а потом о фреймворках, тех что знает, да и тех что не знает
мидл думает о фреймворках, а потом, если хороший, о бизнес задаче. а может и не думать о б.з., протестуя: «Мне за вовлеченность не доплачивают!»

это софт или хард скилы?

синьор в первую очередь думает о бизнес задаче, а потом о фреймворках, тех что знает, да и тех что не знает
мидл думает о фреймворках, а потом, если хороший, о бизнес задаче. а может и не думать о б.з

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

делать единообразно

В рамку и на видное место. Как-то у меня спросили на интервью у клиента, а как Вы относитесь к разным подходам работы с данными через код: просто ORM, или навернуть ещё паттерн репозиторий, rich vs anemic model, как с DTO и т.п. Ну, я говорю да, в интернете холивары постоянно, лично я люблю так, так и так, по следующим причинам, но, честно говоря, самые большие проблемы не от того, что выбрали неправильные конвенции, а из-за того, что их нет, и люди банально как попало называют модели и пихают их куда попало, с чем во многих проектах приходилось воевать, т.к. бардак а-ля User, UserModel, UserDto, UserRecord, UserRequest, UserResponse, UserMessage, разбросанные как попало по разным папкам в разных неймспейсах, сильно бьёт по восприятию и поддержке. Поэтому я с готовностью приму решения большинства, лишь бы они были, и за этим следили на код ревью.

делать единообразно

безобразно но единообразно!

Знания/Память о миллионе фреймворков в мозгу съеживается до многомерного все-подобия.
И будет использовано не только в точных ситуациях но и в похожих.

Дополню, что основное отличие — не «чуть-чуть», а все-таки полноценно уметь руководить командой. Т.е. уметь не только написать код самому, но и еще понять кто из команды может с этим справиться и проделегировать.
Кажется, что я описал тимлида, они и правда похожи (как по мне), но тимлид все-таки больше про административку, а синьор — про код.

А еще в команде должны быть сумасшедшие изобретатели, вроде такого из «Назад в будущее»

Это люди полезные, но в малом количестве. Когда такой один, всем хорошо. Когда два — уже беда.
Но я просто к тому, что в укрИТ понятие «сеньор» какое-то странное. В смысле это нифига не синьоры, а просто крепкие миддлы.
Напоминает ситуацию с карточками банковскими. Во всем мире Золотая Карточка — это предел, но в СНГ и у арабов, кажись, придумали еще и платиновую, кроме понтов ничего не дающую. Зато золотые начали раздавать чуть ли не всем. Вот и с синьором так получилось.

Кажется, что я описал тимлида

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

а синьор — про код.

нет, про код — мидлы думают. потому что умеют.

нередко поэтому мидлы и бузят
да я пишу код лучше чем синьор такой то! почему же он синьор а не я?

и правильно бузят, когда пишут хороший код, а синьор — приемлимого качества.
только вот не понимают что разница в этих «чуть-чуть»

ну и конечно в правилах раздачи лычек, которые к теме о скилах нередко не имеют никакого отношения.

Тут, мне кажется, можно спорить как про цвет платья.
Но в целом, да, синьор это про софт-скиллы. И про такое понятие, как ответственность :)

Тут, мне кажется, можно спорить как про цвет платья.

зависит от целей.
цвет платья тоже можно подбирать согласно целей — это платье скрывает полноту? а насколько маркое? «мне назначена встреча с японской императорской семьей» — тогда желтый цвет нежелателен (хотя запрет действовал лишь до VIII века. )

так и тут — какая цель в определении различий мидла, синьора и лида — такой будет и результат
можно и подобрать цель — что не будет никакой разницы :)

Цель — это частный случай всегда. Тут же мы говорим о некоем «сферическом синьоре в вакууме». Т.е. чтобы человек, переходя из компании А в компанию Б одним термином мог объяснить свои обязанности на предыдущем месте и свои компетенции. Понятно, что потом все уйдет в частности.
Спор про определение «в среднем по больнице»

Цель — это частный случай всегда

конечно. по другому и не бывает. вы хоть термин «Бог» возьмите определить — определения тоже будут зависеть от цели определения

Тут же мы говорим о некоем «сферическом синьоре в вакууме».

не знаю о чем вы

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

Т.е. чтобы человек, переходя из компании А в компанию Б одним термином мог объяснить свои обязанности на предыдущем месте и свои компетенции

у компаний А и Б могут различаться эти наборы.

Понятно, что потом все уйдет в частности.

вначале в категории, в контексты:
мы говорим об уровне развития специалиста?
о лычках? и т.д.

никаких сферических синьоров никто в таких темах не обсуждает :)

Спор про определение «в среднем по больнице»

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

тут говорят о вполне конкретных критериях
качественной разнице,
тех скилов
глубины знания
уровня зарплаты

Правильно. Т.е. эти самые критерии и являются поводом для «лычки», но для каждой компании они свои.

у компаний А и Б могут различаться эти наборы.

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

Т.е. эти самые критерии и являются поводом для «лычки»

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

Когда человек говорит, что он «синьор» или «миддл» — это не вопрос про кто какой стек знает и умеет отличить докер от подмана.

это вообще дело десятое, что человек говорит. другой контекст.

А про класс выполнения задач

да, это один из контекстов.

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

почему не ожидает? зависит от проекта. и если на проекте вменяемые — то поводят за ручку, чтобы быстрее начал работать, вышел на уровень продуктивности на который брали

В отличие от «джуна». Иногда «миддла».

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

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

....и проекта.

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

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

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

0. Знакомство с командой
1. Короткий овервью митинг плюс ссылки на проектную документацию
2. Краткое самостоятельное погружение в курс дела
3. Несколько митингов для ответа на конкретные вопросы

При этом я ожидаю, что текущие вопросы (типа доступов) он решает самостоятельно, после знакомства с командой

А не о том, что «оружие добудешь в бою, ура сразу в атаку»

В отличие от — «ну давайте, рассказывайте мне неделю по 4 часа в день как оно все у вас тут»

более-менее знаком с доменной областью, и базируясь на этом, может самостоятельно проанализировать бизнес-проблему

Имеется в виду senior business analyst?

К большому сожалению бизнес-аналитики это больше исключение чем правило в современной разработке. И да, нормальный senior как минимум должен уметь в UML и в нормальную декомпозицию и постановку задач

Ок. Назовём его иначе — продакт оунер. Он тоже большая редкость в современной разработке?
Или может, скрам большая редкость?
Или бэклог никто не мейнтейнит?
Я при любом собеседовании первое что спрашиваю у менеджера, это процесс и методология постановки задач.

Назовём его иначе — продакт оунер

Средний продакт оунер тебе запилит юзер-стори типа «As a user ... I need to have a possibility to use an external identity provider ... so that I can avoid the creation of the separate profile»
Чуть более продвинутый — разобьет на две — логин и логаут.

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

Вопросы выбора конкретного протокола, провайдера — это и не его, в принципе, компетенция.

А это и не является доменным знанием. Знание протоколов — это знание технологий

Типа как капитану в армии не обязательно лично быть супер-пулеметчиком

Не знаю, что в современной армии, но в ВОВ дед был капитаном, и хорошо разбирался в пулемётах. Рассказывал, что даже в кармане небольшие расходники носил — чтобы пофиксить что-то в пулёмёте, когда неопытные (за теми пулеметами они как «расходники» были — ибо в полный рост за станком стояли) бойцы жаловались на его работу.

Это сообщение не против утверждения про сеньёра, но про плохую аналогию.

І де тут сеньор?
Ні слова про код рев’ю, про менторинг і про обмін досвідом. Ні слова про софт скіли і можливість адекватної бесіди з клієнтом.
«Приємлівое качєство» — це не рівень сеньора

А хіба капітан — це еквівалент сеньйора? Капітан це рівень командира роти або заступник командира батальйону. А рота — кілька взводів (по суті команд). Явно, що сеньйор іншим займається.

ну так а сіньор це навіть не офіцер ))

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

ЗЫ: і доречі цікава думка подумати над тим як сіньор виглядає «за аналогією» армійського принципа переймання командування за умови втрати старшого офіцера

Синьер — сержант в армии(званиие).
Лид — старшина(должность).
Отличие от рядового — может самостоятельно выполнить отдельную задачу, иногда даже правильно.
Задачи старшины помимо всего прочего *вытирать сопли новобранцам* и следить чтобы сапоги одевали левый-на-левую 8)

Ни тот ни другой никогда не станет генералом в старой армии.
Офицеров же обычно учат(в вузах 5 лет) как обьяснить куда воевать, и кого-то заставить делать то, что нехочется.
Хорошие офицеры обычно знают скорость полета пули(снаряда,ракеты, и проч. вундервафель), и количество *стволов* чем создают ошибочное мнение что умеют этим пользоваться. 8)

Например в армии сша может быть *главный сержант рода войск*
подчиняется напрямую коммандующему(например ввс) но всеравно отвечает за патроны, запас трусов на складах и *боевой дух* личного состава — разница только в маштабе.
По этому в армии(как правило) знание любых средств вооружения(или базвордов), даже на уровне iddqd не даст возможности решать глобально — что делать.
По этому когда рассказывают что им нужны *рембо*(или фуллстек например) и тщательно перечисляют необходимый опыт(типы патронов, количество траков на танке, почему люки круглые — и проч. что гуглится за 15 сек).
— то это скорее всего либо понты(за которые обычно не доплачивают), либо мясорубка с *рыцарями без головы* вместо офицеров.

умови втрати старшого офіцера

ПМ шолэ?

«отряд не заметил потери бойца»

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

Пора програмістам створити таку табличку для Project Manager, Scrum Master, Agile Coach, HR, Happiness Manager...

Так забирают ли сеньоры у джунов всю работу?
Вот доказательство, что забирают: dou.ua/...​rums/topic/32483/#2042390

Прочитав і зрозумів, що я мабуть по Базам не сеньйор. Навіть не чув про деформалізацію бази, не те що робив.

Гадаю, що мова насправді була про денормалізацію

Автору самому стоит её изучить, а он точно лид?)

Это какой-то бред честно говоря.
Это не сеньйор получится а какой-то супер-фул-стек. Чего только стоит требование понимания ограничения РАЗНЫХ баз данных. Вы еще напишите «всех».
Это скорее таблица как завалить любого кандидата. Мне не попадалися даже техлиды хотя бы с половиной требований.

Таблица действительно, чтобы завалить кандидата и не раздумывать над тем «почему нет»
Если все идёт к тому, что надо брать — таблица прячется куда подальше.

Чего только стоит требование понимания ограничения РАЗНЫХ баз данных.

Например, понимание того, что в документной NoSQL базе скорее всего будет сложно обеспечить referential integrity между коллекциями, в то время, как в практически в любой реляционной БД это как два пальца об асфальт — это какое-то космическое требование на senior уровень?!

Или, что в условном PostgreSQL есть триггеры, а в условном MariaDB их нет — это тоже какое-то адское требование, по-вашему?

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

а какой-то супер-фул-стек

С тем, что список навыков подразумевает, скорее, back-end, а не front-end — да, соглашусь. Но, опять же, такое разделение — это уже специфика современного украинского рынка труда. Тот же Beaver Green не раз писал, что в начале-середине 2000х все толковые разработчики были фулл-стек (и я, своим опытом, тоже готов это подтвердить).

Если уж говорить о базах данных, то, тогда, скорее, DBA были отдельной «кастой» — но и это не означает, что разработчикам не приходилось писать хранимые процедуры и триггеры (не говоря уже о SQL запросах, далеко не всегда тривиальных)

Вот вы и показали, что вы этому требованию НЕ соответсвуете.
В mariadb есть тригеры, кстати. Еще с mysql 4 они там есть. Но очевидно, что вы не можете прилично хорошо знать Postgress, Mysql, mariadb, oracle, Cassandra, Aerospike и чего там еще знает ваш интервьювер и при этом знать остальные пункты.

Вот вы и показали, что вы этому требованию НЕ соответсвуете.

Ну, то есть, вы предпочли докопаться к деталям, проигнорировав слово «условный», которое я специально написал именно для того, чтобы не было придирок к выдуманному с потолка примеру. Отличный уровень дискуссии, я считаю.

что вы не можете прилично хорошо знать Postgress, Mysql, mariadb, oracle, Cassandra, Aerospike и чего там еще знает ваш интервьювер и при этом знать остальные пункты

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

Ещё раз — суть требования (как я его понимаю) в том, что человек на senior позиции в принципе понимает, чем вообще могут отличаться разные БД — набором фич (да, те самые триггеры, хранимые процедуры и т.п.), способом хранения данных (по строкам / по колонкам), парадигмой (реляционная, документная, графовая...). Знать, что такое CAP теорема, наконец.

Детали по конкретной базе ищутся в документации, это ежу понятно. Главное — знать, что искать, а не тулить в проект ту или иную БД потому, что «а вот друг Вася использовал, ему понравилось».

суть в том, что тут такой набор, который нереален на необходимом уровне для среднего человека.
Нельзя требовать от кандидата знать вот эти общие вещи вот в такой постановке.
Можно требовать знать mysql или postgress на среднем уровне, но не блин то, что там написано.
Нафига среднему сеньйору уметь делать шардинг? Нафига среднему сеньйору знать ваши (неописанные) базы? Очень мало людей знает больше двух-трех ВООБЩЕ.

Вот я вас попрошу написать агрегатор для Aerospike, вы, думаете, справитесь? да там же простой lua, подумаешь. И пофиг, что там надо еще пару дней читать доки просто чтоб ответить на вопрос.

Очень мало людей знает больше двух-трех ВООБЩЕ.

Так а где в табличке написано, что нужно знать больше? Написано — «несколько», две-три в это определение вполне попадают. Ну и, получить за несколько лет опыт работы c, например, MariaDB, PostgreSQL и какой-нибудь Монгой — кажется, более чем реально. По крайней мере, уровень понимания основных возможностей и ограничений этих БД такой опыт точно даст.

я вас попрошу написать агрегатор для Aerospike, вы, думаете, справитесь? да там же простой lua, подумаешь. И пофиг, что там надо еще пару дней читать доки просто чтоб ответить на вопрос

Покажите, пожалуйста, где вы видите в обсуждаемой табличке подобные требования? Вместе с тем, общее знание о том, что в NoSQL базах данных агрегации вполне вероятно придётся писать руцями — senior’у будет более, чем полезно. Ну, хотя бы, для того, чтобы не тащить, поддавшись хайпу, NoSQL базу в проект, где ожидается большое количество отчётов и дашбордов, которые потянут за собой эти самые агрегации.

Нафига среднему сеньйору уметь делать шардинг

А вот тут начинается самое интересное. Я не зря выделил жирным слово «среднему».

В понимании автора этой таблички (да и в моём, по большей части) senior — это специалист, способный решать нетривиальные задачи. Если говорить конкретно о back-end, то, да, в том числе — high load, где требуются шардинг и денормализация. Ну, чёрт возьми, хотя бы иметь представление о том, как такие задачи решаются.

Разработчик, который просто хорошо умеет в свой стек и вышел на плато продуктивности в нём в решении типовых задач — это strong middle.

Да, тяжело вам наверно сотрудников искать.

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

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

Да они ВСЕМ могут отличатся.
А требовать от разработчика вот этот список это жесть.

А требовать от разработчика вот этот список это жесть

Погодите, я правильно понял, что жестью вы называете вот этот список:

  • Виды баз — классические реляционные, документные, графовые, колоночные
  • Различие по поддерживаемым фичам — транзакции, блокировки, триггеры, агрегации...
  • CAP теорема и какие комбинации обычно бывают

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

Грубо говоря, что для агрегации по миллионам строк лучше подойдёт колоночная БД, для OLTP нагрузки без намёка на хайлоад — классическая реляционная, скорее всего, будет оптимальным выбором, если часто меняется схема данных, то может хорошо зайти документная БД (но нужно быть осторожным со ссылочной целостностью) и т.п.

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

Правильно правильно.

конечно — правильно :)
не синьор просто, и все.
почему я могу поговорить на эти темы, не будучи специалистом по БД — а другой синьор — но не может?

В результате вы получите фигового абсолютно во всем специалиста

это уже зависит от кто нужен.

ибо у него тупо не будет времени все это обновлять до текущего стандарта.

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

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

Да, конечно.
Почему физик-ядерщик не в курсе как рыбу на блесну ловить, если я в курсе.
Че, реально в это верите?

Почему физик-ядерщик

зато он в курсе мат. аппарата.
а ловец на блесну — нет.

Че, реально в это верите?

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

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

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

так что тут даже от обратного можно
возмущен критериями синьорства? ну наверное мидл потому что :)

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

подумалось, еще краткий критерий
синьор и тех лида подсидеть может.
а вот мидл — нет.

В этом случае блесна — это вот эти узкие требования к специалисту, физику-ядерщеку.
Понятно, что вам не интересно читать, только писать.
Причем тут джун?
Не вижу смысла с вами препираться, бессмысленно.

Требования к мидлу — узкие
к синьору — широкие.

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

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

пусть говорят. вы же синьор — вакансий тьма — идите к другим, на зп синьора. делов то!

значит не сеньор

вы собеседуете — вам и решать, и предлагать не умеющему ловить на блесну — мидловую зп.

почему я могу поговорить на эти темы, не будучи специалистом по БД — а другой синьор — но не может?

Уверен, что этот сеньор найдет темы, в которых он не специалист, но про них он поговорить сможет, а ты нет.

я такие темы нахожу постоянно, когда синьоры на доу сдуваются :)

найти несходящиеся темы на самом деле просто всем.
даже математикам с мировым именем но с разных областей

Думаю, всё достаточно банально.

Клиенту в счёт идут услуги всех специалистов как нужно: опытные девопсы, специалисты по безопасности, архитектор, техлид, отряды синьоров и горстка миддлов.
Когда вывешиваются вакансии на ДОУ и т.п. под проект, то есть вакансии максимум уровня синьора. Просто обязанности всех тех специализированных спецов — они перечисляются в вакансиях синьоров. И компенсация соответствующая — 4, максимум 4.5к месяц/чистыми, 48-54 к/год. Ведь это ОГРОМНЫЕ (!!) деньги для бедной Украины. :-) Даже в 2020+ году. А то, что в levels.fyi полная компенсация уровня аутсорсных миддлов+ в более-менее серьёзных продуктовых конторах по 130-180 тыс. в год минимум — этого такие дельцы вместе с их нищебродными клиентами предпочитают просто не замечать.

Поздравляю, ты только что открыл бизнес-модель аутсорса

И это тоже. )
Мне кажется, к этой модели органично примешивается ещё тянущееся из совка презрение к профессии инженера. Типа кто он такой, за что ему платить такие деньги? А если уж платим на уровне 2-3 месячных аренд минимально приличного жилья — то требовать будем космос и вкалывать он должен за эти деньги ого-го!

Потому что современное IT уходит от узкой специализации. Да, никто не ожидает от, скажем, senior back-end разработчика быть гуру также во front-end и в dev ops. Вместе с тем, иметь некий кругозор в этих областях и уметь решать несложные задачи — крайне ценно. И это не какие-то мифические персонажи, я таких ребят знаю среди коллег, и далеко не одного.

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

А я вижу наоборот, что специализация все уже и уже.
Ну может на галерах это не так, но в мире именно специализация у всех.

Понятие full-stack не галерами придумано. И, часто, full-stack — это именно хотелка заказчика.

Хотя бы, потому, что узкая специализация сильно усложняет планирование и повышает вероятность простоев.

Количество специалистов full-stack сильно меньше всех остальных, в сотни раз гдето в обычном мире(не галерном).
и да, в теме вообще ни разу не написано про фулстэк.

И, часто, full-stack — это именно хотелка заказчика.

Вот-вот, заказчики-нищеброды. В моём понимании простого разработчика, любой заказчик-юрлицо, которое заказывает у внешнего подрядчика что-то сложнее веб-сайта-визитки или вебсайта для простейшего приёма заказов — это точно нищеброды. Потому как не могут позволить себе in-house разработку. Либо «эффективный» менеджер ради откатов и/или экономии выносит in-house-разработку в отдельное юрлицо с потогонкой и низкой компенсацией.

Меня как простого разработчика всегда интересовало. Если контора не может позволить себе in-house разработку на бесплатных/open-source инструментах — почему не купить и не внедрить то, что в 2000-х называлось тиражным коробочным продуктом? Или теперь модно ради откатов заказывать себе 10 000-й по счёту интернет-магазин, банковский опердень и т.п.?

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

Начиная от временнЫх факторов, потому что быстро застаффить несколько сильных команд, если требуется, — задача не такая уж простая.

А с чего это вдруг конторе нужно застаффить несколько сильных команд?? И как они без них раньше обходились? Я как простой разработчик полагаю, что контора вдруг нуждается сразу в большом кол-ве спецов только в одном случае. Когда контора получила/выделила финансирование на непрофильную деятельность, т.е. попросту «распил». Например, если какая-то крупная голливудская киностудия вдруг решила сделать убийцу Нетфликса, то им вдруг нужно застаффить десятки разработчиков. Т.е. это попытка заняться непрофильным бизнесом, в данном случае, разработкой ПО, продуктово-сервисным бизнесом. Если это основной бизнес, то команды растут естественным образом, есть репутация конторы, процессы и, соответственно, нет серьёзных кадровых проблем.

Плюс, внутренняя разработка — это всегда намного более рискованно для бизнеса.

Рисокванно только для непрофильного бизнеса. На самом деле, внутренняя разработка есть практически везде. Для этого не нужны гигантские команды из десятков специалистов. Какую-нибудь ERP в ТНК или крупной оптовой конторе поддерживают буквально несколько разработчиков на купленной платформе. Другое дело, что, конечно же, это узкоспециализированная, прикладная разработка с купленными лицензиями/подписками. А не неуклюжая писанина с абсолютного нуля на бесплатных/опен-сорс инструментах типа Java, MySQL ради экономии на корпоративных подписках.

А если кто-то, допустим, получил финансирование, поручает галере с разработчиками из бедных стран типа Украины разработать инновационный, рвущий конкурентов программный продукт по каким-то высокоуровневым спецификациям, надёрганным из PowerPoint-презентации — это, ИМХО, чистой воды мошенники, корпоративные инфоцыгане.

Если это аутстафф, т.е. технологическое ядро разработки полностью у заказчика — то это ок. Пусть хоть тысячами нанимают с Украины, РФ, Индии и самостоятельно, удалённо управляют разработкой и полностью несут риски за конечный результат. А если начинается «мы предоставляем специалистов с доменной, технологической экспертизой для заказчика», от вас только менеджер и/или контактное лицо, т.е. стандартный аутсорс — вот это, ИМХО, полное дно, с позиции разработчика.

Вы, при этом, похоже, не учитываете, что нанять core команду на родине заказчика ни разу не проще, и, пока ещё, сильно дороже, если мы говорим о США.

Особенно, если это стартап в одном из штатов, где разработчики избалованы зарплатами уровня FAANG

Какая должна быть численность core-команды технологического стартапа? Лично я считаю, что в самом начале — это максимум 3-4 единомышленника-партнёра. Из того, что я достоверно знаю, в начале 2000-х, первый серьёзный коммерческий украинский Интернет-банк переделывали на Java, из российского прототипа, 2 (!) разработчика.
На Доу в топиках недавно отмечались, по всей видимости, действительно сильные технари, пробовавшие стартаперство. Хорошо, если бы они отписались, как оно в 2010-х было.

Как по мне, нанимать именно в прорывной технологический стартап, на ФОП-контракт в аутсорс, галерно-корпоративных разработчиков — это вообще нонсенс. Разве что все стороны осведомлены, что это «распил».

Особенно, если это стартап в одном из штатов, где разработчики избалованы зарплатами уровня FAANG

Штаты — это большая страна, не Сингапур, откуда нельзя уехать в локацию подешевле. Как по мне, делать с нуля программный продукт для рынка США и не иметь финансовой возможности заинтересовать на старте достаточно разработчиков в США — ну такое, «распил» или мечтательство мамкиных стартаперов. Все более-менее нужные, серьёзные продукты, их прототипы — делались как in-house разработка, в «гараже», индивидуальный проект.

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

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

Согласен, есть проблема терминологии. В моём понимании, технологический стартап — это когда создаётся нечто принципиально новое, чего нет на рынке и что повлияло на потребительский и/или корпоративный рынок. Например, в своё время был таковым Скайп — бесплатные голосовые и видеозвонки, Youtube — видеохостинг, мобильные операционные системы конца 2000-х (взамен морально устаревшим десктоп-клонам типа Nokia Symbian).

А почитаешь многие галерные вакансии сейчас и раньше — облачная CRM/ERP для ветеринарных клиник, очередная CRM, очередной бэкенд для гэмблинга, очередное кастомное решение для электронной коммерции — это просто «распил», мамкино стартаперство, а не инновации.

Ну вот, например, есть
www.clean.io

Разрабатывается командой из Sigma Software. В основателях — люди с большим опытом в AdTech бизнесе.

В вашей классификации — это «распил», или, всё-таки, инновации?

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

Т.е. я, возможно, с позиции пессимизма, отнёс бы такой продукт/севрис к категории мамкиного стартаперства.

Это борьба с вредоносным кодом в Веб-рекламе. Проблема действительно серьёзная, так как «подставиться» с каким-нибудь криптомайнером (а то и чем похуже) во встроенном в чужую Веб-страницу рекламном объявлении не хочется ни одному рекламодателю и ни одной бирже Интернет-рекламы.

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

Любить — так королеву, проиграть — так миллион, так? Меньше Нетфликсов проектов в принципе не бывает? Например, есть сеть условных пиццерий, которые используют передовую по состоянию на 10 лет назад систему заказов, которая безнадежно устарела и требует замены. Или там гостиничная сеть. Или, любой в принципе %customer name%, бизнес которого не связан ИТ напрямую. Все что им надо — проект на 3-4-6 месяцев, который потом вряд ли будет активно обрастать новыми фичами.

Что делать в таком случае?

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

Если какая-то ИТ-услуга, косвенно связанная с основным бизнесом — «ложишься» под мировых/региональных монополистов — системы бронирования типа Booking/Hotels.com — подаёшь заявку, документы, проходишь аудит — получаешь полный комплект ИТ и маркетинговых услуг под ключ, саппорт. То же самое с каким-нибудь Uber Eats, Glovo и т.п. Да и практика показывает, что потребителю удобнее работать с крупными розничными платформами аггрегаторов, чем с какими-то индусскими копеечными писульками от гордой и незавсимой сети пиццерий. Для совсем маленьких и гордых есть странички в Facebook и бизнес-аккаунты в Инстаграмм.

И так с каждым малым, немасштабируемым бизнесом — коробочное/облачное решение с подпиской и саппортом. Я ещё со времён работы в сфере 1С помню, какая репутация у профессионального сообщества была у франчайзи 1С (полный аналог аутсорс-галер). Всякая мелочная, однотипная, тупая работа, самое главное — низкооплачиваемая, выполняемая молодняком, выпускниками заборостроительных институтов, которые не нашли себя в других сферах. Накрутка/мутки с часами, впаривание услуг, трудоустройство вчёрную или через аналоги ФОП, кидки на зарплату. Более-менее толковые люди, набравшись опыта, искали и устраивались в крупные конторы в ИТ-отделы, которые действительно требовали кастомизации и качественый саппорт кастомизированных программных решений. И, самое главное, могли оплачивать работу этих специалистов более-менее на уровне.

Лично мне как бэкендеру на бесплатной Java кажется полным дном браться собственноручно за проекты от описанных выше нищебродов на несколько месяцев. Чем это по серьёзности отличается от работы фрилансером через Upwork? Оосбенно сейчас, когда все работники (из вменяемых софтовых контор) работают из дому.

То же самое с каким-нибудь Uber Eats, Glovo и т.п.

Возвращаясь к примеру про пиццерии.
«Despite Food Delivery Boom, Uber Has Lost $5.8 Billion in 2020»
Например завтра Uber Eats закроется. Или, скажем, резко поднимет оплату за сервис.

Даже если какой-то региональный аггрегатор уйдёт — на рынке есть другие. Если у рынка есть ёмкость — возникнет/зайдёт новый оператор. Т.е. это, на мой взгляд, не повод 3-4 ресторанам в условном Лос-Анджелесе начинать заказывать свой собственный аналог Uber Eats с вполне ожидаемым бюджетом на 1 разработчика на уровне почасовой оплаты уборщика в школе где-то в американском селе в глубинке. С такими хотелками — на Апворк к индусам. Давно уже нет разницы зарплат в США/ бедных странах 10:1, как это было в 80-90 годах.

Как мне кажется, владельцам нескольких ресторанов в Лос-Анжелесе виднее, что лучше для них, чем девелоперу в Украине :)
Это их деньги, и они их считают. И скорее всего не видят смысла переплачивать за решение абсолютно тривиальной задачи, которую они считают необходимой, и которая не требует каких-то особых скиллов при этом.
Или посыл в том что украинские галеры должны гордо отказываться от таких предложений? Типа проекты меньше $5млн не рассматриваем? В таком случае 90% украинских галер потонут за полгода, вот и весь результат

Или посыл в том что украинские галеры должны гордо отказываться от таких предложений? Типа проекты меньше $5млн не рассматриваем? В таком случае 90% украинских галер потонут за полгода, вот и весь результат

Я не экономист, чтобы считать, какой должен быть порог безубыточности проекта для конкретной галеры, $5млн или $500 000.

Если вы считатете, что начинающие украинские разработчики со знанием английского языка (а им владеют тем хуже, чем меньше платят) прогибались за беловоротничковую работу на зарубежных клиентов по ФОП-контракту за компенсацию уровня продавца/охранника в обычном украинском супермаркете, делая сотни примерно одинаковых, убогих копий условных Uber Eats — только чтобы «лидер рынка»-благодетель не дай бог не «потонул» — думаю, обсуждать больше нечего.

Честно говоря, не увидел ничего что может хоть как-то ответить на вопрос «что делать».

Разработка ПО — это не есть недоступный тайный ритуал секретного ордена. В сухом остатке, обычная сервисная услуга.
Которая подчиняется самым обычным рыночным законам — есть спрос, есть предложение, есть цена услуги которая, свою очередь, есть производная от комбинации спроса, предложения и репутации исполнителя в данное время.
Если украинские галеры (ну или гребцы на них) станут в позу, мир, по большому счету, этого и не заметит. Просто потому, что они в основной массе не предлагают абосолютно ничего уникального — средняя экспертиза, среднее качество, рейт чуть ниже среднего за счет примененного чит-кода с ФОПами. Почему это так — не тема этого поста. И, соответственно, укранская часть рынка достаточно быстро просто размажется по Польше, Вьетнаму, Чехии, и так далее.

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

Взаимоотношения же «лидеров рынка» c девелоперами — абсолютно то же самое. Спрос, предложение и т.п. Не нравятся существующие лидеры — ну так извини — других не завезли. И надежда на то, что галера будет подгонять свой бизнес, приносящий прибыль, под тонкую душевную огранизацию девелопера, который ощущает себя недостаточно удовлетворенным работой ... Типа как «Розетка» вывесит на сайте — «Троещину не обслуживаем, потому что курьеру Васе туда некомофортно ездить»

Честно говоря, не увидел ничего что может хоть как-то ответить на вопрос «что делать».

Мне кажется, уже нужно на государственном уровне прекращать пропаганду/рекламу курсов программистов, тестировщиков; всяких ИТ-наций. Которые обещают зарплату в несколько тысяч долларов через n лет в этой сфере. Формальный повод: это недобросовестная реклама, вводящая граждан в заблуждение. Реальный уровень доходов — на параллельном итальянском сайте есть свежие данные, ну и опросы на Доу.

Реальная причина: мне кажется, что Украина как территория-поставщик ИТ-специалистов давно исчерпала резервы роста. Этой работой качественно, без очковтирательства, с учётом владения английским языком на профессиональном уровне — может заниматься максимум 1%-2% процента людей. Т.е. если вузы, ПТУ выпускают 1-2 тыс. специалистов в год. Плюс кто-то самостоятельно научится перейдёт — тоже максимум 1-2 тысячи прироста в год. Т.е. 3-4 тысячи ежегодного прироста в год — это максимум для Украины. Для занятости новых и существующих спецов при таких темпах не нужно потоков демпинговых говнопроектов в сегодняшних объёмах.

Так Uber Eats вроде был прибыльным, хотя и весь Убер убыточен.

Если какая-то ИТ-услуга, косвенно связанная с основным бизнесом — «ложишься» под мировых/региональных монополистов

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

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

И, естественно, никто не будет перекраивать успешно работающий бизнес, чтобы втиснуть его в «прокрустово ложе» стороннего решения под ключ.

Намекните, пожалуйста, о каких масштабах и доменной области идёт речь? Если говорить об Украине, то я допускаю, что конторы типа кондитерской корпорации «Рошен» или электрогенерация «ДТЭК» может потянуть по деньгам серьёзную кастомизацию учёта на производстве.

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

Доменная область — кадровый учёт и всё, что с ним связано.

Масштабы — ну, не Рошен с ДТЭКом, но явно больше местной сети пиццерий.

Смотри, возьмем даже условную сеть пиццерий на 7 точек. Пусть в этой сети суммарно работает например даже 50 человек. Пусть все они получают около-минимальные зарплаты (для простоты $10 в час) . Т.е. зарплатный фонд итого 50×80×250 = 1 000 000 (на самом деле больше, ибо еще налоги с работодателя, плюс, возможно, мед.страховки), но пусть так для простоты.
И теперь представь что какой-то софт позволит убрать 4 человека за счет оптимизации работы.
Т.е. за один год это экономия 4×80×250 = 80 000. За два года — 160 000.
Пусть есть галера с миддл девелоперами, которых она продает по $4000. Итого, 80000/4000 = 20 человеко-месяцев. Т.е. проект на 4 месяца для 5 человек, который окупается за год, а со второго года приносит прибыль в 80 000 в год. Вполне разумное вложение, не так ли?
И это очень маленький масштаб. В US например достаточно много вполне себе успешных региональных ( присутствующих в нескольких штатах) сетей, супермаркеты, заправки, автосервисы и т.п.

Спасибо за пример. Мне кажется, он всё же сильно оптимистичен. В самой пищевой точке, ИМХО, вряд ли чисто софтом можно так изменить процесс, что получится сократить целого человека. Я видел ролики, как китайцы ставят в Хореке роботизированные руки, которые участвуют в пищевом производстве — вот это да, действительно прорыв.

Если сократить 4 человека в офисе — ну хз. Если там вёлся учёт на бумажках и в Excel — теоретически можно. Но за 4 календарных месяца с нуля написать и внедрить под ключ на Java что-то жизнеспособное в плане автоматизации учёта — очень сомневаюсь. Под это дело есть куча специализированного софта по подписке.

Ну и бюджет проекта на 80 000, на 4 месяца. С нищенскими 1500-1700 кодерам. А внедрять кто это будет у кастомера? Тестеры, DevOps — на них бюджет выделять не будем — всё магические фулстеки в лучшем виде сделают? Ок. Сопровождение этого решения — на кого? Есть ли смысл тратить ресурс галеры на почасовый саппорт? Т.е. я не думаю, что стоимость последующего владения этим программным решением клиенту обойдётся в ноль долларов.

Это был очень приблизительный пример (зарплата может быть и не минимальная, кодеров можно попробовать найти еще подешевле , масштаб бизнеса может быть больше и т.п.), основной смысл — показать примерное отношение затрат и потенциальной экономии. Т.е, условный проект на 5 человек на год в Украине, стоимостью в $ 240 000, примерно окупатеся экономией на минимальной зарплате 5 человек в US в течение 2.5 лет для заказчика.
Причем с увеличением размеров экономия растет нелинейно
Ну и это только прямая экономия, а есть же еще такие вещи как увеличение удовлетворенности клиентов (~ рост бизнеса ), уменьшение издержек производства и т.п.

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

У нас был кастомер, которому предлагалось использовать готовый сервис с возможностью кастомизации и сэкономить денег, но тогда как раз был недавно инцидент с AWS, и он из-за этого ни в какую не соглашался на 3rd party, т.к. сильно боялся потерять в какой-то момент данные. В итоге сервером занималась отдельная команда индусов, которая так ничего и не заделиверила, пока мы работали, поэтому в инициативном порядке использовался тот самый 3rd party на бесплатном dev плане, чтобы разблокировать себе работу. Сделали, показали заказчику, отдали (в т.ч. наброски API спек индусам)... хотя можно было просто серверную часть нашу же сразу купить — только план платный взять для сервиса, и всё).

Есть мнение, что фулл-стеки — вечные мидлы

Есть мнение, что фулл-стеки — вечные мидлы

есть такое мнение

его корень в холиваре
универсал vs специалист

неустранимая дилемма. Впервые на русском встретил у Буча в его «Объектно-ориентированный анализ и проектирование»

Хотя, можно еще и более поэтичное припомнить:
«Ну и худа ты!» — глумилась дубина над тростью.
«Ну и толста ты!» — ей трость отвечала со злостью
(Рабиндранат Тагор)

синьор более универсален чем мидл.
на что мидлы и бухтят — да я сидя на одной технологии 10 лет познал ее кручее!

так и живет этот холивар :)

Вообще-то заказчику, при нормальном контракте с приложенным вменяемым SLA, абсолютно наплевать на тип разработчиков — это полностью проблемы исполнителя. Другое дело, что "full stack’ можно попытаться чуть дороже продать, ну так это просто особенности бизнеса по-украински, а не желание заказчика.

Через меня, так сказать, по долгу службы проходит довольно много запросов заказчиков «в подлиннике». И сами заказчики просят full-stack.

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

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

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

у капитанов обоих подводных лодок есть общее — отдельная каюта, и должностные обязанности= уровень ответственности, которых не дают просто за выслугу старшему матросу.

продажа ж мидлов как синьоров в аутсорсе-аутстафе(а потому раздача лычек) — это вообще про другое.

Давайте тогда определимся, что считать усложнением фронтенда.

Зоопарк браузерных движков, порой весьма вольно трактующих стандарты, CSS2 и отсутствие autoprefixer’ов, нет готовых polyfill’ов, сторонние библиотеки уровнем максимум jQuery/knockout.js — вам правда кажется, что было проще?

Что касается деплоя, то, разумно будет отталкиваться от задач. Ожидается ли, что senior в одно лицо развернёт production Kubernetes кластер? Конечно же, нет. Но написать Dockerfile или Helm chart — что в этом такого космического?

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

джуны и мидлы так и воспринимают :) по этому их восприятию их и можно идентифицировать — они ж мыслят о скилах количественно, а не качественно. линейно, а не двумерно.

хорошее кстати направление в собеседовании:
какие недостатки технологии X знаете
о достоинствах везде пишут, это любой прочитать и зазубрить может.
давайте — о недостатках поговорим.

Сам всегда так делаю :)

давайте — о недостатках поговорим.

реально это уровень эксперта я проверял ))

ЗЫ: но этот вопрос можно разыграть по другому «а с какими недостатками сайд эффектами странностями и вообще сам сталкивался на практике вот написано 1 год опыта на протяжении года успел куда-нибудь закопаться?» вот про это с обычным гребцом можно более или менее поговорить

о достоинствах везде пишут, это любой прочитать и зазубрить может.

я уже набил оскомину где только можно слушая за «правые и левые ссылки» и «абстракций с нулевой стоимостью» а пусть он своими словами объяснит ))

реально это уровень эксперта я проверял ))

ну, эксперт это уже уровень не просто знания недостатков, а с набором апробированных рецептов по их обходу :)

я эксперт )) я стал постоянно сталкиваться с такими и быстро разработал «универсальный по их обходу» следи за рукой

я просто говорю «так _не_ делай»

всё )) работает я проверял

ЗЫ: и да возникают вопросы «почему?» но на это тоже ответ простой «ну без проблем вот ты возьми и разберись вот тебе список источников откуда начать к утру доложишь что уже успел накопать исполняй!» и тоже работает я тоже проверял ))

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

Если бы кто-то на полном серьезе спросил разницу в Postgress, Mysql, mariadb, я бы подумал что там работают одни неадекваты

Если бы кто-то на полном серьезе спросил разницу в Postgress, Mysql, mariadb, я бы подумал что там работают одни неадекваты

отличная идея! я специально не копал — но расскажу о разнице между ними тремя. еще и между парами версий Mysql и MariaDB — что в какой появилось, а что убрали. не все конечно, но смогу.

«- А вы не знаете?»
понятно — мидл

Да ну? Там в 10.4 столько всего наубирали, что учить не переучить. А до этого в 10.3. И это только разница между maria/mysql
Практически уверен, что вы и сотой доли разницы не расскажите, и если запомненное вами не совпадет с интервьювером — будет неудобненько.
А уж между postgress и mysql вообще разница сложно описуемая.

Да ну?

ну да :) если вы что-то не можете, не знаете, из этого никак не следует что никто этого не может, не знает.

Там в 10.4 столько всего наубирали, что учить не переучить

если вам уже даже это «учить не переучить» то
«Ясно. Понятно.»

Практически уверен, что вы и сотой доли разницы не расскажите

будете меня собеседовать — проверите.

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

А уж между postgress и mysql вообще разница сложно описуемая.

описуема. вполне описуема.
долго просто, собеседования может не хватит слушать о ней.

Помоему, классический эффект Даннинга-Крюгера

Если один считает другого кретином, то один из них точно кретин

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

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

Так что просто признаю,что вы глубокий специалист в когнитивных искажениях :)
Я ж вам комплимент сделал, а вы о какой-то дуэли.

Зачем же передёргивать. Никто в здравом уме не будет спрашивать про отличия в минорных версиях.

Но такие элементарные вещи, как поддержка хранения JSON/BSON, или geospatial типов данных?

Поддержка всяких там подзапросов, временных таблиц (особенно — несколько на один запрос), window functions?

И, опять же — это не чеклист, из которого нужно знать всё. Важно, что человек в принципе понимает, какие отличия могут быть, и может привести несколько примеров.

А давайте.
JSON типы — никогда не использовал за все время работы, не вкурсе.И да, также ни разу не видел использование их в реальных проектах. Я уж не говорю про geo.

Подзапросы, временные таблицы — поддерживаются обоими версиями. ПО РАЗНОМУ. Причем минорными версиями — тоже по разному.

window functions — как раз написанное выше «отличие в минорных версиях». И да, в mariadb 10.1, 10.2,10.3,10.4 — нефига не минорные, ибо разный набор фич а 10.3 и 10.4 даже несовместимы между собой бинарно.
Смотрим. data-xtractor.com/...​window-functions-support

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

Дмитрий, поймите, то, что вы это знаете — вообще не говорит о том, что тот, кто этого не знает — не сеньйор. Просто это значит, что у него был ДРУГОЙ ПУТЬ. Может он вообще никогда ни с mysql ни с postgress не работал по причине того, что он работал с Oracle и MSSSQL.

Так отлично, пусть расскажет про свой опыт с MS SQL и Oracle!

Нет же привязки к какому-то конкретному продукту. Мне лично важно было бы в целом понять, что человек не просидел 5-10 лет строго в одном стеке, и вообще слабо себе представляет, что происходит за его пределами

Этот говорит только о том, что ты ни разу за 10 лет не сталкивался с задачами, выходящими за рамки самого типового использования БД.

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

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

Под типовым использованием я имел в виду задачи класса (условно) «работал с базой через ORM и ничего сложнее запросов, которые можно построить через предоставляемый ORM query builder, не писал»

И вот берёшь такого человека, а потом начинается:

— План запросов? Не, не слышал
— Индексы? А что это? В ORM нет такого
— Денормализация? Вы что это за ересь мне такую предлагаете?!
— Какая ещё read replica? Это наверное только Гуглу и Фейсбуку нужно...
— Я не знаю, как сделать такой запрос, query builder в моей ORM не умеет в такое
— Audit logging? Ну-у, могу в коде прикостылить. А если изменение в базу мимо твоего кода пойдёт? Ну-у, тогда не знаю, у меня лапки.

Другими словами, речь здесь не идёт о каком-то извращённом не предусмотренном производителем использовании БД.

Я все что ты описал знаю, и все равно топлю за ORM, это не ORM плохие а разработчики, то что ты говоришь на английском(ORM) еще не значит, что ты не знаешь латынь(SQL).

А я и не говорю, что не нужно использовать ORM там, где это целесообразно.

Я же о другом — плохо, когда разработчик не понимает, что происходит на уровне базы, и «спотыкается» на любых задачах, которые не имеют типового решения через ORM.

Это уже не говоря о случаях, когда в результате бездумного использования ORM на ровном месте порождались проблемы с N+1 запросами (а я такие «шедевры» видел собственными глазами).

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

Очень много вопросов по тому, как работает базы.

Исключительно потому, что на примере этой строки таблицы начали обсуждать оправданность требований к senior’у.

Справедливости ради, данная категория вопросов никак не относится к знаниям тонкостей, особенностей и недостатков одной реляционной СУБД от другой. А если такой кандидат запросит $1500-2000 — высока вероятность, что ему дадут офер.

А если такой кандидат запросит $1500-2000 — высока вероятность, что ему дадут офер.

Это уровень зарплат мидла. Конечно, на мидла ему офер дадут, кто ж спорит.
Некоторые компании, при этом, даже senior’скую лычку выдадут.

Вот только потом подобный «дутый» senior, прийдя на собеседование в более серьёзные компании, будет долго и неприятно удивляться, почему ему предлагают в лучшем случае middle позицию.

данная категория вопросов никак не относится к знаниям тонкостей, особенностей и недостатков одной реляционной СУБД от другой

И, вместе с тем, это связанные вещи. Поскольку человек, весь опыт которого состоит в, например, в клепании простеньких сайтиков с использованием MariaDB, просто даже не задумается, что под другие задачи гораздо лучше подойдут совсем другие БД, в которых «из коробки» есть то, чего в условной MariaDB либо отродясь не было, либо завезли только недавно, а человек «по старинке» пользовался только возможностями, о которых узнал пять лет назад.

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

Так вот, вместо того, чтобы задействовать JSON для хранения таких слабоструктурированных данных, такой боец с большой вероятностью начнёт городить адовые конструкции с наследованием таблиц или entity-attribute-relationship (или как там его), с «прелестями» в виде лишних join’ов, и хорошо ещё, если с индексами.

Чисто по технической части — я согласен. Но такие вещи, как использование специфических особенностей конкретной СУБД, всё же ИМХО, должен санкционировать архитектор. Т.к, возможно, для этого нужно апгрейдить версию СУБД, возможно, покупать какой-нибудь Enterprise Edition для этой СУБД, идти сознательно на вендор-лок.
Другое дело, что ради получения прибыли с низкобюджетного, а то и планово-убыточного проекта эту функцию и ответственность взваливают на разработчика, так как дефакто архитектора на проект не поставили.

Ну и вишенка на торте, почему большинство стремятся в «дутые» синоры на отечественном рынке? Мне кажется потому, что ФОП-компенсация $1500-2000 — это по сути смешные деньги. Нигде в нормальной Восточной Европе такой смешной компенсации нет, с учётом всех налогов, с увольнением в 1 день по любой причине. Поэтому люди и пытаются спрыгнуть побыстрее с такой смешной, по сути, промежуточной компенсации.

использование специфических особенностей конкретной СУБД, всё же ИМХО, должен санкционировать архитектор. Т.к, возможно, для этого нужно апгрейдить версию СУБД, возможно, покупать какой-нибудь Enterprise Edition для этой СУБД, идти сознательно на вендор-лок

Санкционировать — да, согласен, это уже епархия архитектора. Но предлагать использование подобных особенностей (и, соответственно, знания об их существовании) — я бы ожидал уже на уровне senior.

почему большинство стремятся в «дутые» синоры на отечественном рынке? Мне кажется потому, что ФОП-компенсация $1500-2000

У меня здесь другой вопрос — почему в реалиях украинской ИТ-индустрии компенсация так прочно прибита гвоздями именно к грейду?

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

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

У меня здесь другой вопрос — почему в реалиях украинской ИТ-индустрии компенсация так прочно прибита гвоздями именно к грейду?

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

ИМХО, это очень хорошее замечание. Просто в Украине почему-то считается нормальным платить смехотворные суммы на начальных этапах. Вероятно, надбавки в $300-$500 — с изначально низкой базовой ставкой в итоге просто слишком мало. Вроде в Европе нет такой разительной разницы между штатным джуном, миддлом и синьором. Поэтому там нет смысла лезть любой ценой вверх по грейду.

Мне кажется потому, что ФОП-компенсация $1500-2000 — это по сути смешные деньги.

Без обид, сколько тебе лет? Очень похоже что ты просто не застал внутренний-рынок-без-галер.

Нигде в нормальной Восточной Европе такой смешной компенсации нет, с учётом всех налогов,

Про какие такие страшные налоги идет речь?

Без обид, сколько тебе лет? Очень похоже что ты просто не застал внутренний-рынок-без-галер.

Мне 42, профессионально в ИТ с 2000 года.

Внутренний рынок, вероятно, таки не застал. Но зарплаты уровня $300 в «галерах» той эпохи — вполне.

Мне 42, профессионально в ИТ с 2000 года.

Это был вопрос @Andrew Frolov :). Сорри за confusion

Кстати полностью аналогично, 42, и с 2000

Без обид, сколько тебе лет? Очень похоже что ты просто не застал внутренний-рынок-без-галер.

Мне 38 лет. Я в ИТ начал работать в 2006-м году. Работал на внутреннем рынке, на внешнем, в специализированных конторах продуктового типа и просто в ИТ отделе. Сейчас уже несколько лет в аутстаффе на одном аккаунте, по всей видимости, хорошем, раз явно лучше пока не находится.

Я повторюсь — я не считаю, что $1500-$2000 ФОП-компенсации — что это какие-то серьёзные деньги. Что там было в 2000-х — это уже история. Тогда у доллара была совершенно другая покупательная способность в мире.
И самое главное — это не зарплата в стабильной сфере. Это заробитчанство без эмиграции. После возраста 40 лет, экстраполируя нынешнюю ситуацию — личный доход будет падать, а где-то в 45 старого, выгоревшего дядьку с кучей хронических заболеваний и психических отклонений, после очередного закрытия проекта, на новую галеру не возьмут — молодёжи море. Будет после 45 эникеем подрабатывать — менять картриджи и ездить по командировкам сервис-инженером — обслуживать дисплеи, платёжные терминалы и настраивать wi-fi частным лицам. Это если не обеспечит себе пассивный доход и частную пенсию.

Про какие такие страшные налоги идет речь?

НДФЛ, ЕСВ (их аналоги), страховки. Если всё это повычитать по-настоящему (по польским ставкам налогов) из обсуждаемых миддловых сумм, то по меркам 2020+ года будет совсем грустно. Практически доход программиста 1С в областном центре или в Киеве, а то и меньше, судя по предлагаемым зарплатам в проектных организациях:
www.work.ua/jobs/3160454
www.work.ua/jobs/3848193

Что там было в 2000-х — это уже история. Тогда у доллара была совершенно другая покупательная способность в мире.

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

И самое главное — это не зарплата в стабильной сфере.

Что тогда есть «стабильная сфера» в Украине («стабильная» != «стабильно нищая») ?

Что тогда есть «стабильная сфера» в Украине («стабильная» != «стабильно нищая») ?

Стабильная — которая не контролируется монополистами или случайным совпадением внешних обстоятельств — курс доллара, технологические достижения типа удалённой работы/Интернета.

В галерном ИТ максимальный срок жизни знаний/опыта — это 5 лет. Человек не станет в ИТ аналогом уважаемого врача, чиновника со связями/знакомствами, он никогда не станет частью истеблишмента. Это всегда будет «шестёрка», бегающая по техническим собеседованиям от проекта к проекту, участвующая в тендерах уровня «кто предложит наименьшую цену?». Неважно, в виде наёмного сотрудника или руководителя маленькой «шлюпки». И мечтательное стартаперство на накопленные запасы в 99% окончится впустую потраченными временем, ресурсами и здоровьем.

В галерном ИТ максимальный срок жизни знаний/опыта — это 5 лет
Когда нынешнему сообществу Ит в Украине, 200 000 человек, будет по 50-60 лет — много они смогут повыбирать?

Вот тут уже соглашусь с ораторами выше. Саморазвитие, хотя бы минимальное, всегда должно присутствовать. Если нет — то се ля ви, некого обвинять кроме себя. И кстати, ИТ тут еще и в очень выигрышном положении, так как требования по здоровью, возрасту или внешности минимальны по сравнению с остальными сферами деятельности.

Человек не станет в ИТ аналогом уважаемого врача, чиновника со связями/знакомствами, он никогда не станет частью истеблишмента.

Ну так это как бы очевидно. Как и автомеханик. Как и электрик. Как еще и n! профессий. Хочешь стать уважаемым чиновником — иди в политику. Хочешь стать уважаемым врачом — ну так закончи медицинский и поработай вначале ординатором на мизерную зарплату. Это так во всем мире, Украина тут уж никак не уникальна.

Рассмешили )))
Лично знаю кейс сеньора, который благополучно в 60 лет выбирал работодателя, причем успешно и с повышением ЗП относительно текущего места. Но это если изначально выбрать бессмертную область — разработку баз данных )))

Я работал с людьми 50+ и что? Когда нынешнему сообществу Ит в Украине, 200 000 человек, будет по 50-60 лет — много они смогут повыбирать? И на какую компенсацию? Оплатить еду+коммуналку или еду+коммуналку+ 2 недели в турецком all-inclusive раз в год?
Я то уж точно знаю, что DBA и разработчики баз данных сильно сдулись с 2000-х, очень многие были вынуждены переквалифицироваться или прозябают на 1000-1500 долларов на внедрениях 2000-х годов, украинский внутренний рынок.

Это относится к базовой компьютерной грамотности разработчика, имхо

А это у вас на проектах такое, когда разработчики вот так просто могут херачить индексы в базу без лишних вопросов и сомнений? Видят планы продакшн запросов (и вообще имеют такой уровень доступа в боевую базу)? Еще и в DDL получается могут. Сесурненько так.

А кто вообще говорил про доступ в боевую (в смысле продакшен) базу?

По-вашему, проблемы с производительностью никак не могут проявиться на тестовом окружении при первом же прогоне performance тестов?

с полной копией правильно анонимизированных реальных данных

Реальных данных — не всегда, поскольку первые прогоны performance тестов делаются, естественно, до запуска в продакшен.

Но, в таких случаях, обязательно на тестовых данных, близких к реальным как по объёму, так и по структуре.

read-replica зачастую действительно выглядит печальным костылем/памятником мертвой базы.

Ну конечно же, и именно поэтому это один из самых распространённых в индустрии подходов к масштабированию БД.

Вам приходила в голову мысль, что поднять read реплику может быть тупо проще и дешевле, чем искать гуру DBA для хардкорных оптимизаций базы?

А для read replica DBA не нужен, это любой фуллстек зафигачит? Типа «what could possibly go wrong» и read replica никогда не сможет прибить вашу основную базу (например MSSQL)?

Я не знаю по поводу MS SQL — возможно, там есть какие-то сложности с репликами. Но, в целом, пока не очень верю, что для настройки master-slave репликации в read replica обязательно нужен полновесный DBA.

начинают пинать индексы и «денормализировать», помогает но не очень, создают read реплику, переводят кластер полностью в память, добавляют еще кучу всяких «hints» и вот кто-то уже доходит до уровня гуру DBA в этом говне

Так и отлично — у человека появляется дополнительная компетенция.

Не проще ли остановить это на уровне «а давайте спросим DBA, может мы делаем что-то не так»?

Не проще, потому что такой DBA получается очень узкоспециализированным товарищем. И, если только компания не делает «на конвейере» проекты с подходящими для уровня DBA уровнем задач, то для такого специалиста просто не будет загрузки.

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

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

Не совсем понятно. Компания, больше совсем уж маленькой шлюпки на 20 человек, обычно специализируется на каких-то стеках технологий. .NET + MS Sql или там Java + Postgres или там php + MySql. Под них подбираются типовые команды c типовыми скиллами. И обычно всегда имеет смысл иметь специалистов по базам данных, из расчета один на n проектов. Очень странно слышать что для специалиста «просто не будет загрузки»

Если это конечно не:
— Маленькая шлюпка которая хватает что попало и набирает кого попало.
— Полный бардак и анархия в архитектурном подразделении, когда в 10 аналогичных проектах используется 10 разных СУБД

специализируется на каких-то стеках технологий

Далеко не всегда, и причём здесь размер компании?

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

И обычно всегда имеет смысл иметь специалистов по базам данных, из расчета один на n проектов.

Внезапно, я работал в GlobalLogic и до этого в Validio до осени 2010 года. Выделенных специалистов по базам данных даже в середине нулевых можно было пересчитать по пальцам, а уж к концу нулевых вообще затрудняюсь вспомнить, кто у нас в харьковском офисе работал именно как DBA.

бардак и анархия в архитектурном подразделении

Какие громкие слова, Александр. К вашему сведению, далеко не во всех компаниях оно существует как структурная единица — это первое. И не всегда выбор БД является степенью свободы для компании-исполнителя — это второе.

Наоборот, такая специализация мешает растить бизнес,

Ну так если речь идет об растить, то это требует некоторых инвестиций, не так ли?

Внезапно, я работал в GlobalLogic и до этого в Validio до осени 2010 года. Выделенных специалистов по базам данных даже в середине нулевых можно было пересчитать по пальцам, а уж к концу нулевых вообще затрудняюсь вспомнить, кто у нас в харьковском офисе работал именно как DBA.

Вполне возможно, я перешел в GL позже и в Киевский офис.

К вашему сведению, далеко не во всех компаниях оно существует как структурная единица — это первое.

И вы считаете это нормальным? То есть условые n команд девелоперов, независимо друг от друга, используют любые языки/БД/версии что им нравится?

И не всегда выбор БД является степенью свободы для компании-исполнителя — это второе.

Да, я это прекрасно понимаю. У серьезных заказчиков обычно как раз есть архитектурные стандарты. Ну так тут вопрос в другом — если у вас нет соответствующей экспертизы, зачем хватать такие проекты? Или, см. п1, рост требует инвестиций.

условые n команд девелоперов, независимо друг от друга, используют любые языки/БД/версии что им нравится?

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

Разумеется, есть некие общие рекомендации и предпочтения, но это не возведено в ранг какой-то обязаловки.

И, разумеется, есть присмотр за тем, что выбирают и используют команды — но этот присмотр, скорее, из разряда sanity check, чем строгая проверка на соответствие каким-то «священным скрижалям».

У серьезных заказчиков обычно как раз есть архитектурные стандарты.

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

если речь идет об растить, то это требует некоторых инвестиций, не так ли

Разумеется, но как это относится именно к вопросу выделенных DBA? Инвестиции именно в них пока не выглядели особенно оправданными.

Но тут ещё такой момент, что в области биг дата необходимые навыки могли покрываться просто прокачанными data engineers.

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

Проблемы начинаются потом. Когда заканчивается проект у команд использующих специфичный стек. Или заказчик разрывает отношения. В результате в компании появляется 5 свободных разработчиков с проекта на NodeJs и 5 свободных Scala разработчиков, при одновременно открытых горящих 15 вакансияx Java и 10 .Net на других проектах.

Бывает ещё и так, что заказчик например уже вложился в некую инфраструктуру, у него есть персонал, который умеет именно эту инфраструктуру и этот софт обслуживать

Это точно такой же архитектурный стандарт, причина, по которой он возник, тут второстепенна. Он просто есть и не обсуждается.

И новый «зоопарк» (каким бы стандартным он не был для компании-исполнителя) заказчику совсем ни к чему.

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

Разумеется, но как это относится именно к вопросу выделенных DBA? Инвестиции именно в них пока не выглядели особенно оправданными.

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

5 свободных разработчиков с проекта на NodeJs и 5 свободных Scala разработчиков

Да, это проблема, если разработчики не имели раньше опыта с другими тех стеками. Но, это характерно обычно для «молодняка» — более опытные бойцы вполне могут вспомнить, что несколько лет назад писали на .NET или Java.

Бывают, конечно, случаи, когда человек принципиально хочет Scala и только Scala — ну, такие попадают на бенч и ждут подходящего проекта.

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

И, тем не менее, практика показывает обратное... 🤷‍♂️ за исключением, пожалуй, big data — но там это совмещено с data engineer / архитекторами соответствующего направления.

И, да, у нас были DBA (по MS SQL так точно) года эдак до 2012го. То есть, это не то, чтобы какая-то моя личная упоротая позиция в духе «DBA не нужны».

«если в руках есть молоток», у вас эта условная база теперь будет плодиться на каждом проекте

Это решается присмотром старших товарищей за теми, кто ещё не перерос детскую болезнь «если у вас в руках молоток»

Не пробовали на парт-тайм контракт или вы пытаетесь идти путем гильдий?

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

Насчет MSSQL некая команда выгребала в выходные как-то от очень похожего кейса

Открываю, читаю:

When using synchronous commit mode the primary waits for this acknowledgement before committing the transaction it is running (an insert for example). So the increase in time for the acknowledgement of the secondary replica causes the primary replica to take longer on the insert.

и возникает вопрос — а зачем им этот synchronous commit mode понадобился? Обычно, read replica подразумевает eventual consistency, что для отчётов, обычно, ни разу не проблема.

любая достаточно сложная система несет в себе кучу особенностей, багов и недокументированной функциональности. Для пользователей это часто скрыто за user friendly UX, что дает ощущение «та хуле там»

А мой поинт, как раз, в том, что настоящий senior наступил уже на достаточное количество граблей, чтобы понимать, что в незнакомой ему системе подход «та хуле там» с 99% вероятностью не сыграет, и нужно тщательно курить документацию и форумы, прежде чем тыкать кнопочки в UI.

А если старшие товарищи этим и страдают? Как это определить?

Если этого не видят CTO / chief software architect — то это означает только то, что в компании печаль-беда с архитектурным надзором :(

Рискну предположить, что такое наиболее вероятно там, где любят раздавать лычки и плодить «23-летних senior’ов» (ключевое слово — «плодить», так как в единичных количествах самородки, конечно, в природе встречаются).

У них же все фулстеки. Просто все работает «по среднему»

А без хорошего коммерческого опыта работы с любой из технологий (хотя бы в виде POC для решения конкретной задачи), «выход из стека» в стиле «читал статью, запускал туториал» не имеет смысла вообще.

+100500. На одном из собесодований архитектор спросил про графовые базы. Я честно сказал, что поверхностную теорию какую-то рассказать могу, и в каких случаях они могли бы использоваться, но сам лично считаю, что эти знания стоят 0 целых 0 десятых по причине отсутствия реально опыта с ними, поэтому давай лучше пропустим этот вопрос, тем более, что в резюме я этого и не писал. В итоге после моего пересказа базового internet articles wisdom, как я их понимаю, первый же практический вопрос поставил меня в тупик, как и предполагалось).

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

Я бы уже после вашей фразы

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

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

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

вакансия на поддержку сайта собачьего корма на php

^^^this

Вы, как я понимаю, мыслите в категориях найма строго под конкретную вакансию и конкретный проект. Окей, пусть так.

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

Проходит время, проект успешно сдан. Заходит другой проект, где требуется хайлоад и, скажем, обработка географических данных. И получается вот что: «по бумагам», у нас есть свободный senior, а поставить на новый проект в этой роли мы его не можем, так как вся его senior’ность заключалась в умении хорошо делать простые сайтики для местных зоомагазинов.

А Вы :-)! мыслите в категориях найма строго в аутсорсинг

Вполне возможно. Как известно, «точка сидения определяет способ мышления».

И, если честно, очень старался понять конструктивную мысль из всего потока сознания, но получилось не очень :)

Если основная мысль в том, что

... хайлоад с Zero-Copy забудет он вместе с географическими данными и всем остальным

то senior на таком проекте будет решать да, другие, но, вместе с тем, далеко не тривиальные задачи. И, на масштабе Pedigree, что-то я сомневаюсь, что там не будет хайлоада :)

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

А когда же senior будет изучать все отличия во всех новых минорных версиях всех актуальных DB, как тут настаивали некоторые авторы, если у него будут другие задачи?
Без этого нещитово, раз не блесну ловить не умеет :))

А когда же senior будет изучать

не «когда» — а «сколько» (времени он будет изучать)

Мы же говорили про работу с «географическими данными», вот это, и все остальное что было «до» и будет крепко забыто.

Именно поэтому, не стоит цепляться за один этот конкретный пример :)

Мысль, которую я пытался донести — человек с несколькими годами опыта разработки, скорее всего, имел дело не с одной БД. А, раз так, то наверняка сталкивался с какими-то различиями и индивидуальными особенностями этих БД. Ну это же, блин, в конце-концов, здравое техническое любопытство — хотя бы открыть и почитать статью в духе «MS SQL vs Oracle» или «MySQL vs PostgreSQL».

И, да, согласен, бывают узкозаточенные специалисты, которые годами сидят в одном стеке (ну вот тот же opencart), и вообще не смотрят по сторонам. И, речь о том, что вот таких специалистов можно считать, разве что, «senior opencart developer», но не senior в общеинженерном — за неимением лучшего слова — смысле.

Если не просто видел/читал, а сталкивался в смысле «наступал на конкретные грабли» или, хотя бы, «решал вполне конкретную практическую задачу» — то, такое, обычно, запоминается.

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

Я, например, с 2009 года помню, как тогда в MS SQL не было windowing функции для smoothing average, и таковую пришлось разрабатывать врукопашную на .NET

Заходит другой проект, где требуется хайлоад и, скажем, обработка географических данных.И получается вот что: «по бумагам», у нас есть свободный senior, а поставить на новый проект в этой роли мы его не можем, так как вся его senior’ность заключалась в умении хорошо делать простые сайтики для местных зоомагазинов.

Рассказываем заказчику про свою мега-экспертизу, кое-как выигрываем проект, когда он заходит, садимся и начинаем думать кто же его сможет сделать :) Business as usual :)

Я уже не один раз видел, к чему приводят такие авантюры. И никому повторять их в реальной жизни не посоветую.

А какое есть «нетиповое» использование БД?

Выше ответил:

dou.ua/...​ign=reply-comment#2044350

А остались еще больные психи, что пишут триггеры? (если это не легаси конечно)

остались, остались. если понять в чем с ними проблема, и что они могут, а что ой не надо ими делать — то и в марии они вполне ок применяются.

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

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

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

интелектуальные системы обнаружения нетипичных операций.

Это чаще stream платформы, на основе events

— зміни в таблицях для індексації
— оновлення суми рахунку(чи чогось подібного) та дати його останньої зміни — при змінах у підпорядкованих данних
— інкрементальні зміни залишків, з встановленням флагу потреби в перерахунку
— контроль можливості змін, або позначки про втрату актуальності залежних розрахунків
— кешування, накопичення у memory tables змін, які можуть бути втрачені, та не потребують актуальності, і основні данні оновлюються по event

це тільки в нас, а ми не такі вже й складні.

Я б так не робив, це бізнес логіка вже в трігерах буде.

вона все одно десь буде.
якщо у основному коді, маємо
— катастрофічне падіння швидкодії. і ніяке кешування на равні аплікації не допоможе, або буде дужа складна інвалідація
— і коли після рефакторингу відвалиться, ота інвалідація або контроль інкрементів то те виявиться на проді

скільки не бачив проектів — усюди, частина бізнес логіки, яка впливає на швидкодію та логічну цілісність данних — робиться на стороні БД

чого там сумного :)
загальна, звичайна практика.

я бачив коробочні системи, вся логіка яких була взагалі на Pl/SQL, а на Java тільки інтерфейсна частина.

але так — ваш проект, робіть як знаєте.

а те що ви не знаєте що це загальна практика, бо викликана об’єктивними причинами — і вказує що не маєте досвіду у розробці більше менш складних систем з викростанням РСУБД

P.S.
наша система двічі проходила незалежний технічний аудит.
суттєвих зауважень до цих та інших рішень не було.

Я мав досвід багато років тому власноруч почати писати логіку на трігерах

яку логіку писати на трігерах, яку ні — відповідь залежить від проекту

погрязти в обмеженях, типу «таблиця мутує»,

і як часто таблиці мутують на конкретному проекті, да так, що логіка на боці БД відвалюється?

або ще більше жахіття:
ми кожні півроку мігруємо на іншу БД

побачити, що кінців в такій логіці не знайдеш

у гівнокоді — теж не знайдеш. то давайте не писати на мові на якій написаний проект?

слідкувати за станом трігерів і зробити, як на мене, єдиний правильний висновок — переписати у хранімках :)

не знаю про що мова
ось, знайшов у нас самий складний трігер
IF OLD.is_actual
THEN
CALL calculate_balance(OLD.user_id,OLD.acc_id,OLD.acc_value,2);
END IF

зазвичай просто один рядок
CALL foo(...);

І не один проект я бачив після з логікою в SP, але без зловживання трігерами.

зловживати можна і ООП. і функціональщиною
давайте заборонимо їх використання!

без зловживання трігерами.

Золотые слова. Имхо, основная проблема триггеров — это классический спагетти-код, который получается если попытаться «лианеризовать» (не знаю как более лучше © сформулировать) их логику, со множеством возможных точек входа и состояний

Та же проблема если попытаться лианезировать состояние обьектной системы.

Тригер по сути, это метод объекта, вызываемый автоматически при его изменении, создании и удалении.

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

Думай что делаешь — сложное правило, да. Проще выработать табу и догмы и им следовать.

Тригер по сути, это метод объекта, вызываемый автоматически при его изменении, создании и удалении

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

каскад неявных вызовов,

Идеальное описание спагетти-кода в трех словах

В Тригер передаётся строка, то есть сродни перелачи this.

Неявные вызовы — везде под капотом. Тогда все системы -это спагети код.

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

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

Регулярное появление словосочетания «неявных» в контексте мне прозрачно намекает на:
— Не самое простое тесттирование
— Не самое простое сопровождение кода

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

намекает на:
— Не самое простое тесттирование

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

намекает на:
— Не самое простое

Что такое — самое простое сопровождение кода — мне непонятно.
никаких сложностей пока не замечал, наоборот
кода в приложении становится меньше.
меньше и саппортить

Это все конечно мелочи

естественно. обычно есть куда более серьезные сложности и трудозатраты

— катастрофічне падіння швидкодії. і ніяке кешування на равні аплікації не допоможе, або буде дужа складна інвалідація

У всех DB-centric систем на основе классических реляционных баз есть одна общая проблема — они на порядок хуже и на порядок дороже масштабируются.

— кешування, накопичення у memory tables змін, які можуть бути втрачені, та не потребують актуальності, і основні данні оновлюються по event

Другими словами, не требуют строгой consistency. Для таких задач есть другие типы БД,

У всех ... есть одна общая проблема — они плохо ...

Берете этот шаблон, подставляете по контексту — и за умного сойдёте.

Другими словами, не требуют строгой
consistency

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

Тут шаблон для того чтобы за умного сойти -телепатировать и выдавать наиболее общие фразы

Берете этот шаблон, подставляете по контексту — и за умного сойдёте.

Мне не надо «сходить» за умного. Я и так не дурак.

У всех DB-centric систем на основе классических реляционных баз есть одна общая проблема — они на порядок хуже и на порядок дороже масштабируются.

В данном случае я старался выразился конкретно. Запасаюсь попкорном и с удовольствием жду саксесс-стори про элементарное масштабирование реляционной БД в 10 раз, и главное — во сколько это обошлось по финансам итого :)

Другими словами, не требуют строгой consistency
Другими словами для части информации не требуется абсолютная точность или достоверность

Как я понимаю, вторая цитата должна означать что-то радикально противоположное... Но не могу уловить нюансы, можете просветить?

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

Вторая цитата указывает на то в жизни, в отличие от теории, нет смысла бороться за то в чем нет смысла. И для этого не нужно менять бд.

Нюанс в том что есть упоротые «программисты фаангов» которые только тем и заняты что масштабируют перемасштабируют, когда оно нафиг не надо, потому в бизнесе рост в 10 раз за небольшое время — это ого редкость, и в конкретном и большинстве проектов тоже,
решают задачу в общем случае, когда это тоже нафик не надо, в конкретном, и большинстве проектов и т. п.
Разумеется, эти упоротые выдают в большинстве случаев банальные фразы и умозаключения, а то и просто вдаваясь в наивную демагогию.
Ессно они не дураки. Просто — упоротые :)

Нюанс в том что есть упоротые «программисты фаангов» которые только тем и заняты что масштабируют перемасштабируют, когда оно нафиг не надо

Это еще одна крайность, абсолютно согласен. Когда на мелкий стартап требуют что-то типа Oracle RAC, а то вдруг через 5 лет будут миллионы пользователей.

потому в бизнесе рост в 10 раз за небольшое время — это ого редкость, и в конкретном и большинстве проектов тоже,

Это может быть необязательно прямой рост, вида в «интернет магазине было n закзазов в месяц, а стало 10*n за три месяца». А может быть вида «появилась необходимость собирать и хранить детальную статистику по определенным\всем услугам». Или «купили компанию-конкурента и интегрируем их данные»

Разумеется, эти упоротые выдают в большинстве случаев банальные фразы и умозаключения

Еще одну банальную фразу «логика реализовання в БД на хранимым процедурах и триггерах трудно переносится при переходе на другой тип БД» наверное слышали все.
И почти все обычно думают, «ну что за нереальный сценарий».
И в целом правы, это достаттчно редкий случай. Только я вот лично видел, работа онсайт у одного из кастомеров, с какими огромными проблемами у них шел глобальный переход с DB2 на Oracle в enterprise масштабе — в этом была плотно задействована команда с их сторовн которой мы непосредственно работали по своим активностям — так как по факту они просто переписывали все.

Еще одну банальную фразу «логика реализовання в БД на хранимым процедурах и триггерах трудно переносится при переходе на другой тип БД» наверное слышали все.

ествественно слышали

это ж
Если птице отрезать руки,
Если ноги отрезать тоже,
Эта птица умрет от скуки,
Потому что сидеть не сможет.

А если с Джавы надо перейти на Хаскель? Ужас, нельзя писать на Джаве, вдруг на Хаскель придется переходить — банальность того же рода, как и вывод.
Ну ладно, не на Хаскель — на Rust вдруг надо будет переходить с Джавы?

О чем вообще речь, о «запрете» использовать технологию Х потому что «а вдруг придется перейти на технологию Y»?
а с технологии Y вдруг не придется переходить на технологию Z?
А с Z, вдруг, точно не понадобится на W?

И почти все обычно думают, «ну что за нереальный сценарий».

не поверите, не — сталкивался.

но да, бывают и такие сценарии.
читал, вполне бывают.

Или «купили компанию-конкурента и интегрируем их данные»

Или, или, или, ... — вы предлагаете посоревноваться в фантазии?
например:
«появилась необходимость собирать и хранить детальную статистику по определенным\всем услугам».
РСУБД — замечательно для этого подходит. Если эти данные не требуются для операционных данных, то есть аналитические или подобные — вообще замечательно все масштабируется — поднимаются отдельные БД для этого, .
тригеры то тут при чем?

Причем, обычно то, как раз из-за легкости создания таких разрезов и в операционной БД и РСУБД стали — доминирующими.

Но банальность — рассказывать о преимуществах РСУБД — я опущу. все есть в инете, за годы то существования SQL
Как и недостатки.

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

Аргумент блондинки: «А вот я знаю случай!»
не обсуждаю.

Примерно по тем же причинам что юристы не вписывают в договора форс-мажор: падение метеорита.
Хотя, думаю, и такие случаи бывают что вписывают.

но вопросики все же задам, риторические

... с какими огромными проблемами у них шел глобальный переход с DB2 на Oracle в enterprise масштабе

— а с какими проблемами бы они жили — НЕ используя возможности DB2, ради того чтобы потом, в будущем далеком без проблем, перейти на Oracle?
— куды смотрели архитекторы, почему в функционал системы не было заложено: ... предусмотрена возможнсть перевода системы с DB2 на любую другую БД, аналогичного типа, или другого типа, в том числе и такую, которой еще и не существует на момент запуска в эксплуатацию.
другими словами: безпроблемность перехода «на другой тип БД» — это топовая потребность для информационнй системы уровня ERP?
— компания погибла на этом переходе? команда не смогла переписать?
«огромные» проблемы — каковы критерии огромности, например: затраты ресурсов: времени, денег, людей — во сколько раз превысили стоимость создания предыдущей системы? или вообще на порядки? «что с чем сравниваем?»

так как по факту они просто переписывали все.

переписывают все — и по куче других причин, оставаясь и на той же БД"

И переписывание да — трудозатратно. Вообще, даже не переписывание, а написание с нуля — трудозатратно.
Такая вот банальность — разработка ПО — это трудозатратно.

А если с Джавы надо перейти на Хаскель? Ужас, нельзя писать на Джаве, вдруг на Хаскель придется переходить — банальность того же рода, как и вывод.
Ну ладно, не на Хаскель — на Rust вдруг надо будет переходить с Джавы?

Аналогия абсолютно неуместна. Очень грубая подмена понятий

Или, или, или, ... — вы предлагаете посоревноваться в фантазии?
например:

.

Я не люблю фантазировать и говорю про еще один реальный случай из своей практики. Только речь шла не непосредственно о покупках (собствено покупки произошли раньше), а о миграции региональных биллинговых систем достаточно большого телекоммуникационного холдинга в единую централизованную.
Которая, к сожалению, была написана большими любителями запихнуть-побольше-логики-в-БД. По факту, если обращаться к классической трехуровневой архитектуре, уровень бизнес-логики там был редуцирован в «получили данные-заинсертили в базу-там разберутся». И которая уперлась в бутылочное горлышко дискоовой посистемы при росте нагрузки всего лишь в 3 раза.

это топовая потребность для информационнй системы уровня ERP?

Это была не ERP-система. Это был набор in-house OSS/BSS систем.

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

И ведь не поспоришь ...

Которая, к сожалению, была написана большими любителями запихнуть-побольше-логики-в-БД

«И обжёгшись на молоке, дуешь и на воду»

Давайте возьмем индусский код, и обобщим что Джава это — гуано

И которая уперлась в бутылочное горлышко дискоовой посистемы при росте нагрузки всего лишь в 3 раза.

«думай что делаешь» — уже писал
касается всего, и тригеров тоже.

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

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

он о том как
переход на ХП уменьшил количество кода (и в итоге количство программистов для поддержки)
и «В карантин нагрузка выросла в 5 раз, но мы были готовы»
Как Lingualeo переехал на PostgreSQL с 23 млн юзеров — хабр

Этот рецепт ессно не универсален. просто — случай, как и ваш.
В коробочной ERP — IFS, на момент моего с ней знакомства, вся бизнес логика была написана на Pl/SQL
Вакансия намекает что так и осталось jobs.dou.ua/...​-ukraine/vacancies/42807

senior хотя бы интересуется чем-то за пределами привычных ему технологий и инструментов.

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

Тот же Beaver Green не раз писал, что в начале-середине 2000х все толковые разработчики были фулл-стек

А что там по фулстеку было в начале 2000х? Asp, php, apache на бэкенде, а что на фронте? А там у половины юзеров js отключен был в браузере. А что остается? Точно — html)))
тот же jquery только в 2006 был сделан. Конечно сравнения — адок

Тру сеньоры все делали прямо в сервлетах и html генерили прямо там же)))

Это, скорее, самый конец 90х, может быть, год 2000-2001й. Потом как минимум в IE подвезли уже относительно вменяемый dynamic HTML, и front-end перестал быть тривиальным server-side rendered HTML. В корпоративных приложениях так точно

HTML Applications (.hta) тут кто-то из олдфагов пилил? Эдакий «дедушка» Electron середины нулевых. Сами Microsoft на этой технологии даже инсталляторы (точнее, их UI) делали.

Ещё в первой половине 2000х мой коллега пилил на Javascript портальный движок с асинхронной загрузкой содержимого портлетов. Работало это всё на Internet Explorer 5.5, XML/XSLT во все поля вместо современного JSON, и никакого jQuery и даже готовых реализаций AJAX.

Так что, если ты думаешь, что до появления jQuery не было сложных задач на фронте — ты сильно ошибаешься.

А что остается? Точно — html)))

Который всего лишь по-разному рендерился в разных версиях IE, Firefox и Opera. И бизнесу зачем-то надо было чтобы верстка выглядела одинаково хорошо и в IE5, и в IE6, а попозже и в IE7

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

Тот же Beaver Green не раз писал, что в начале-середине 2000х все толковые разработчики были фулл-стек (и я, своим опытом, тоже готов это подтвердить).

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

Таблиця рівня «у нас в компанії працюють тільки девелопери рівня «Архангел». Не можливо знати все. На практиці часто треба переходити з одного стека на інший. Якщо для продуктової компанії, тоді можливо щось і підійде. Але не в такому вигляді. Майже в кожному розділі є теми, дуже обширні і не на всі навіть з великим досвідом можна відповісти

Подобається формулювання «чув/бачив/розуміє» ))
Краще б «працював» )))) )))

И вас с пятницей :)

Факт тот, что если проходить такое тестирование по памяти, то я например, даже на пол-джуна не наберу поинтов. Да и соображаю медленно, так что оговоренные ниже 5 часов — не. Скорее 20, а еще лучше рабочая неделька времени на оценку боевых качеств.
Бои на время проигрываю, играю только походовки с неограниченным time-on-step. Это, кстати, не значит, что все степ будут по миллиону секунд.
Мне больно от лимитов. И от деталей. Я клаустрофоб, любитель абстракций и вечности.

Спасибо. Но я 100% не нанимаемый. Разве что в роли твичера — обзорщика игр и/или софта. Играю (софтю), записываю, смотрю, что в игре/софте/сайте неудобно и рассказываю об этом диктофону.
Я идеально тупой пользователь. Я необыкновенный мастер провалов, фейлов и багов. Но только устроитель. За мной по пятам должен ходить расшифровщик-регистратор-документатор моих находок. В какую джиру он их засунет мне все равно.
Обыкновенно, я снимаю видео своих действий, а потом исправляю. Вот так кодю. Степ бай степ.

За мной по пятам должен ходить расшифровщик-регистратор-документатор моих находок.

И рядом еще трое — один корону и скипетр несет, двое края мантии придерживают чтобы по полу не волочилась...

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

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

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

«Меня», «Я» это не самолюбование. Я просто отмечаю тот факт, что такие как я отличаются от остальных своими особыми свойствами талантами возможностями и поэтому незаслуженно отбрасываются на обочину жизни. Вот почему я продвигаю свой бренд именно так. Многие — не тупые просто соображают медленнее чем требует «прогресс цивилизации» Тот самый, который растопил льды Антарктиды. Так что нужен он нам — этот прогресс и ускорение добытия прибыли для кого-то — это еще тот вопрос. Я бы напротив всеми силами пытался замедлить чертову колесницу прогресса, который сломя голову несется к пропасти.

Ты может быть и «особенный», но никто не работает лучше ограниченный временем И все хотели бы, чтобы привычные и удобные для них виды деятельности оплачивались, как нечто «брендовое». Это не твоя личная специфика, просто все остальные подстраиваются под требования потому, что (им нужно/они могут), а ты обходишься малым без этого.

Нет. Есть люди, которые хорошо помнят и или вспоминают быстро. А есть, которые не запоминают. Вроде меня. Мне надо написать задание на бумажку и потом позвонить и напомнить, чтобы я прочитал бумажку.

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

Я предложил (неявно) эксперимент провести.

Люди вроде меня — устроители катастроф. Потому что катастрофы они запоминают легче всего.

Еще больше позерства и самолюбования?

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

Кому нужны устроители катастроф?
Я не хвастаюсь, я довожу до тебя (и всех) свои полезные качества.
Иначе был бы невидимым.
— Доктор, меня игнорируют.
— Следующий!

Тааак, темка начинается с упоминания проблемы собеседований. В табличке 30 поинтов, даже если по 10 минут на поинт (10 минут — это совсем не много времени на то, чтоб понять, к примеру, действительно ли человек умеет в шардинг и понимает последствия, а не просто 100-лучших-вопросов нагуглил) то получим 300 минут или 5 часов собеса без перерыва на туалет, кофе и вопросы «кем вы будете через 10 лет».

Как вы эту табличку в реальности применяете?

... в замен интервьювера, который не выдержал?

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

Например, если бы можно было каждому в эту статью (как в вики) добавить собственного опыта и знаний, как и кем бы это одобрялось/отсеивалось? Сейчас думаю над подобным алгоритмом накопления знаний и сохранения и распространения / тиражирования опыта.

Алгоритмы в вебе — это каким способом отсортировать каталог из 20 товаров?)

Это — почему пробел в браузерах автоматически не перекодируется в знак_пробела и обратно,

ну вон в ML копия ломают, что лучше, питон или жабоскрипт? а пне как то фиолетово из под чего они с++ код там запускают

Взагалі не бачив МЛ на JS... на R, прости господи, бачив а на JS — ні...

та гдето в твиттере недавно срачъ © (тм) мимо пробегал
я ж говорю — эти все языки просто запускали с++ кода, поэтому смотреть на эти срачи (мой мл на жабе быстрее твоего мл на питоне) просто смешны

то есть все интерпретируемые языки — по сути одно и то же, ибо их интерпретатор написан на с++? интересный вывод

Уже давно нет — GCC имеет много кода на C++, Clang написан на нём вообще полностью.

интересный вывод

я вообще про другое

ну так из

я ж говорю — эти все языки просто запускали с++ кода

и получилось

все интерпретируемые языки — по сути одно и то же, ибо их интерпретатор написан на с++

может там конечно имелось ввиду, что для какой-то специфической задачи они все используют какую-то библиотеку, написанную на C++, например OpenCV, тогда через какой именно интерфейс вызывать функцию OpenCV действительно не особо важно

может там конечно имелось ввиду

ну наконецто

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

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

Безусловно, бывают специфические задачи для сеошников, маркетологов, но в 98% случаев — именно 20-100 айтемов с сортировкой по цене/продажам/критерию

Если известно что количество итемов ограничено и мало (до 500, например), можно отправлять все с бека на фронт и там сортировать. Знание алгоритмов сортировки в таком случае ни к чему, так как метод sort справляется с данной задачей и на нескольких тысячах элементов.

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

Но только сейчас инквизиторы церкви CS нас начнут сжигать на костре за такие еретические речи.

сортировка — это просто понятный всем пример

какая именно?

здесь имеется в виду видимо сама постановка задачи вот числа 1 3 100 100500 надо разместить их по возрастанию чтобы получилось 1 3 100 100500

многие «алгоритмы» на литкоде да и вообще в общем тоже вовсе не так просто представить себе «в абстракции результата» по крайней мере это 146% не просто для простого человека я проверял ))

ЗЫ: вот на пример задача двойной диспетчеризации

dou.ua/...​rums/topic/32515/#2042637

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

ЗЫ: попробуй сам объяснить человеку «простому» а) что вообще за «двойная диспетчеризация» такая б) что виртуальные функции т.е. рантайм полиморфизм это и есть «одинарная диспетчеризация»

ЗЫ: да ладно скажем грубо очень но половина примерно не понимают за полиморфизм )) а то например что в сях полиморфмизма нет на уровне языка в т.ч. «статического» и как это происходит так что плюсовые функции вообще укладываются в сишные это уже реально уровень эксперта

ЗЫ: да ладно сишечка взять джаву и си-шарп там толпа народу воспринимает тот факт что всё ссылки и что где-то там есть garbage collector как чистую магию же ж и действительно просто ходит по заученному сказали для складывания строк использовать string builder они и используют а почему так зачем и кто вообще все эти люди ну профессор валит гад ))

точно. сортировку первокласник видел,а деревьев в саду — никогда

чтобы обобщить деревья с графами нужен недюжий уровень абстракции )) эта проблема универсальна она же ж прекрасно работает с математикой понять что такое прямой угол и где он у треугольника и какай от него польза можно на простых наглядных примерах понять на тех же ж примерах синус косинус в целом тоже пока можно но подавляющее большинство на вечно остаются на уровне «косинус как отношение прилегающей стороны»

попробуй в этом же ж месте продвинуть простую концепцию что угол можно мерять не только в градусах но и в радианах а потом попробуй продвинуть абстракцию зачем эти радианы вообще нужны есть же ж градусы прямой угол 90 градусов вода кипит 100 градусов всё просто и понятно ))

чтобы обобщить деревья с графами нужен недюжий уровень абстракц

мы же про первоклассников, умеющих в сортировку?

я таких знаю только тов. купера но я не уверен что это реальный персонаж ))

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

сортировка как сабж один из простейших механизмов доступных для понимания наочно так например уже конкретные реализации та же ж «сортировка пузырьком» уже воспринимается чисто как магия по крайней мере тогда в самом начале )) для восприятия абстракций нужна тренировка по восприятию этих самых абстракций ну и конечно запас мощности мозгов

вот например «детская задача на пионеров» ))

scontent.fiev22-2.fna.fbcdn.net/...​2a0d57ca428cd&oe=603429C9

не знаю как долго ссылка проживёт

мне стало весело я решил с ходу сложив уравнение

x/12 + x/5 + x/8 + x/20 + x/4 + x/7 + 30 + 120 + 300 + 50 = x

ты пробовал объяснить первокласснику ну или там шестикласснику в каком там вообще классе математику учить начинают «концепцию иск как не известного в уравнении» равно как и саму «концепцию уравнения» ?

или хотя бы б как сложить дроби через общий знаменатель ))

В том то и дело, что алгоритмы в вебе — скорее исключение, а даже если и нужны — средства фреймворка/языка обычно покрывают требования. Умение нормализировать базу, составлять и использовать индексы, писать правильные запросы, учитывая особенности фреймворка, кешировать в меру — реально покрывает большинство РЕАЛЬНЫХ задач.
Если это не аутсорс с одним жирным клиентом, где можно тянуть время и задрачивать патерны, ходить на курсы инглиша, то почти все рабочее время — сделал сносно, чтобы работало под нагрузкой и не положило при чихе базы, оно начало приносить бабки, а потом, может быть, перепишешь код.
Тот же TDD — ну отличнейшая вещь, если писать с самого начала проекта, только в реальности комплексный тест от автотестеров на самые частые кейсы через веб морду/апи/приложение из маркета, справляется не сильно хуже и порой экономит время разработки и релиза новой фичи. Залить хотфикс всегда быстрее, чем еще сотню юнитов написать.
Но да, в моем случае это не банковский функционал, мы можем себе позволить риски ради прибыльных релизов. Это реальный проект, а не книжка от Фаулера

Надо было именно так, в противном случае это все не имело смысла. И дело не про количество айтемов на страничке, которые лечатся педжинацией и/или бесконечным скролом. Но зачем и почему... это писать простыню текста. Это тула для сотрудников компании была, а не пользовательский сайт. Сортировал потому что это интерактивная хрень была.

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

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

Отличное начало. Хочу еще, в более развернутом виде.
Кстати, ура! Я недоджун и буду кодить теперь горчичку (wassabi) совершенно спокойно.

Хрен же, а не горчичка?

А он вырастет? В смысле, может мне посадить японский хрен и потом он мне достаток обеспечит?

А я думал — горчичка. Горчичка круче звучит. Так что похрен.

А съедобная зеленая краска есть? Что-то не хочется зеленку кушать.

Точно! Смешаем с эликсиром тархуна и будет продавать под брендом: «wassabi — горчичка кодерская»

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

Примерно так ширпотребный вассаби и делается

Розповів би я про таких, та інтерв’юверська етика не дозволяє...

Так, ладно, кто там синьор дело десятое.
Что за такая методология тестирования TLD?

Too Long to Describe

Если с предлогами, то можно еще расшифровать как «Tests for losers development»

Забавно, но на мой взгляд наверное 90% из того, что написано в стобце для синьора является признаком обычного «мидла», или то что называется Software Engineer в остальном мире. Может конечно, у нас разные понятия кто такой синьор.
В моем мире синьор — это уже роль, подразумевающая определенный уровень лидерства и умение работать со сложностью, а не просто знать больше паттернов или библиотек.
Чисто индивидуальный контрибьютор заканчивается на мидле, а мидлы конечно могут что-то знать, чего-то не знать. Могут быть мидлами и с 10+ годами опыта.
Но как правильно написали внизу — прошел собеседование на синьора, значит синьор. Как говорится, других синьоров у меня для вас нет. Будем искать ©

В моем мире синьор — это уже роль, подразумевающая определенный уровень лидерства и умение работать со сложностью

А зачем нам тогда тимлид и техлид? Если синьор уже может лидить, и делать самый сложные такси на проекте?

Очень кратко, тимлид — это senior с дополнительными менеджерскими функциями, техлид — это senior c дополнительными архитектурными функциями

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

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

я бы добавил еще (особенно актуально для продуктовых компаний, но по-хорошему должно быть для всех), это тот, кто все-таки задумывается о бизнесе заказчика, а не просто садится выполнять таску согласно написанному в джире. И если он понимает, что в будущем возможны проблемы, то он это озвучивает вслух ДО начала имплементации. А не потом, когда проблема вылезет, говорит «у меня в задаче этого не было указано»

В этом и заключается та самая работа со сложностью. Она не столько о том, чтобы запилить какой-то сложный алгоритм (хотя и такое бывает). А в том, что каждая из задач может иметь множество возможных подходов, решений и, самое главное, tradeoffs (как это по нашему сказать?). И соответственно роль синьора на своем участке — обозначить основные точки, по которым нужно принять важные решения как действовать. В этом и заключается его часть лидерства и его часть работы со сложным — разобраться какие критерии существуют для функционала, с которым он работает, проанализировать возможные варианты, и сделать осознанный и обоснованный выбор на основе известных критериев и приоритетов.
Те самые System Design собеседование оно именно об этом. Там про алгоритмы ничего особо нет. Закодить сложный алгоритм должен быть способен любой грамотный мидл.

Обычно сеньоры знают что паттерны дрочит не нужно

по базам даних — «деформалізація» ?

слишком много обмазывания паттернами в пункте про архитектуру
хороший коммент по этому поводу с другого дев ресурса на похожую тему -

«Паттерны Головного Мозга.
Ситуация когда субъект воспринимает рисунок из стрелочек и прямоугольничков, как дарованное с небес откровение о мироустройстве. И пользуясь напильником и топором пытается впихнуть любую ситуацию в рамки одной или нескольких таких картинок, забывая об особенностях предметной области и уже существующей кодовой базы.»

отсюда выплывают абстрактные фабрики для создания абстрактных фабрик, адаптеры для фасада адаптеров, 20 классов на 2 строки только из-за того чтобы быть по солиду и прочие извращения, проверять способности в архитектуру по кол-ву заученных паттернов и знанию магических аббревиатур это совок

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

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

Или... Что если создать модель и научить ее путем записи собственных действий в рамках мета-модели? То есть, мы вообще не программируем больше поведение, а проигрываем его, записав когда-то ранее.

Прошел собес на лида/сеньора — ты лид/сеньор, остальное бла бла бла.

Такие таблички нужны менеджерам, чтобы увиливать от повышения зарплаты на перформанс ревью.

Пффф, якщо рабам піднімати оклад так, як хочуть вони, то ланці менеджерів доведеться скорочувати свої витрати на острови, машини, недвигу. Воно їм це треба?

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

Кроме всего прочего, синьоры — не сферические кони в вакууме, и не на конвеере работают. Кто-то лучше в одном, кто-то в другом. А кто-то «душа компании» и его главная польза — поддерживать дружелюбную атмосферу в команде и сглаживать конфликты.

Чудова стаття. Мені, як джуніору, завжди був цікавий набір навичок, що дозволить перейти на рівень вище. А чи використовуються отіаббревіатури з таблиці в реальних WEB продуктах вашої компанії?

А от, наприклад, два сеніори в продуктовій компанії обрали метод гілкування, потім тім-лід найняли ще одного сеніора і вже той сеніор каже, що «ваш метод гілкування гівно невідповідний», то проект відразу переведуть на новий метод?

Залежить від менеджменту і ситуації в цілому)

Синьоры должны решить это в поединке. Проигравший становится мидлом.

Тобі в Global Logic. Всього 7 років, і вже Senior :))

Для мене головною проблемою є зрозуміти хто перед тобою senior, або не дуже.

Дяденька, а вы точно лид? :) Обычно главной задачей при найме является понять что человек может или не может, а не как его правильно классифицировать...

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

собеседовали троих, могут все.
надо взять одного.

И?
так что классифицировать — придется. и классифицировать — правильно.

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

и необходимые бизнесу задчаи все трое выполняют одинаково успешно

они не выполнили еще ни одной задачи
они только прошли — собеседование.

то берите самого дешёвого

забавный совет :)
но вы конечно берите самых дешевых.

Так все равно же нужно принимать решение на неполных данных. Можно взять самого дешевого, или самого красивого, например.

Так все равно же нужно принимать решение на неполных данных

естественно. данные всегда неполные, и через первую неделю работы — тоже неполные.

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

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

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

правильный выбор для галеры! а если шо пойдет не так, гребца за борт — наймем другого

Однако удачно отлынивать от работы — тоже удача. Лучше случайно выбрать первого. Никакого харасмента.

Случайно выбираем номер претендента:
int n = random_int();  take_this_vacancy(n);

А если n > количества кандидатов?

Это только в мире богатых и бедных возможно, потому что богатые границы верхней не знают, то есть неизвестен их тип чисел, в отличие от типа бедных int32, нет int16, нет int8.

Все колдовство с отрезками внутри функций инкапсулировано. От 0 до 10 = 1 кандидат, от 11 до 27 другой. Отрезки на линии.

собеседовали троих, могут все.
надо взять одного.

По моему опыту, проходят интервью на Middle/Senior так, чтобы получить оффер, процентов 30. И практически никогда не получается, что сразу трое вот так взяли и прошли его друг за другом (даже двое — это уже большая удача). Внимание, вопрос: если у Вас уже есть кандидат, который прошёл интервью и влазит в вилку, зачем Вы собеседовали ещё двоих, а не сразу сделали оффер первому? Чтобы потом ломать себе голову, кого же нам взять, и продолжать гадать на кофейной гуще? Это же создание себе лишних проблем на ровном месте. Ну, или у Вас волшебная компания, которой постоянно везёт с ситуацией, когда предыдущий хороший кандидат ещё не решил, а следующий уже тут как тут прошёл интервью, но что-то я очень в этом сомневаюсь).

По моему опыту, 100% подходящий человек — редкость. Такой, чтоб прямо на собесе делать оффер.

Обычно получаешь 5-6 «точно нет» и 1-2-3 «В целом да, но вот если б ещё и это умел...». Есть ли смысл первому попавшемуся «В целом да» делать оффер — не уверен. К тому же, по резюме-то все вкусные: и чистый код любят, и с хайлоадом работали, стрессоустойчивые, амбициозные — заглядение. Хочется всех посмотреть.

Есть ли смысл первому попавшемуся «В целом да» делать оффер — не уверен.

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

По моему опыту, 100% подходящий человек — редкость

не встречал еще таких.
даже про себя — не помню ни одной работы, проекта, компании где я подходил на 100%
в текущую тоже попал, случайно. и думаю на все 100% и сейчас не подхожу.

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

именно.
обучал нашу эйчаршу как отфильтровывать весь лоск.
и смотреть на то что осталось. остается очень мало конечно.

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

вопрос: если у Вас уже есть кандидат, который прошёл интервью и влазит в вилку, зачем Вы собеседовали ещё двоих, а не сразу сделали оффер первому?

по присланным резюме — все трое подходят.
поэтому назначены собеседования всем троим.

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

хуже будет если потом в течение месяца работы выяснится что взяли не того.

Это же создание себе лишних проблем на ровном месте

поспешная женитьба/замужество — порождает еще больше проблем

так что провести все три собеседования и подумать — это сооовсем не та проблема.

Ну, или у Вас волшебная компания, которой постоянно везёт с ситуацией

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

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

прошедшие тех собеседование направляются на собеседование к менеджменту: деньги, условия работы, оформления, и т.п.

и вот тогда уже начинаем решать
вчера были крупные — но по 5
а сегодня по 3 — но маленькие
www.youtube.com/watch?v=sAtxNEBXL7A

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

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

Если Вы сами нашли и позвали 3 человека, всем им подошёл конкретный день для собеседования, и все из них успешно прошли собес в один день, ещё и примерно с одним уровнем, то очень даже волшебная). Потому что я такого и сам не встречал, и не слышал о таком ни разу. Завидую и пора открывать сервисную компанию по отбору сотрудников).

ещё и примерно с одним уровнем

я отвечал на

Дяденька, а вы точно лид? :) Обычно главной задачей при найме является понять что человек может или не может, а не как его правильно классифицировать...

если уровней нет — то и выбирать никак

а кроме уровня у людей еще куча других параметров.
например такой — «крут, но вряд ли сработаемся»

даже на доу об этом были статьи — про причины отказа от отказавших, которые сложно формализовать. а потому — только в процессе собеседования выясняется

Потому что я такого и сам не встречал

встречал тьму раз. и сам бывал как соискатель среди 5ых — когда нужен был 1, и взяли меня.

и не слышал о таком ни разу

ну теперь услышали о жизни в другой вселенной :)
в вашей да, такого не бывает наверное, вот и не слышали.

Ну, моя вселенная, судя по отзывам рекрутеров, как-то ближе к среднему по рынку). Поэтому либо действительно стоит открывать свой сервис по найму, либо есть вопросы, откуда все эти кандидаты взялись в ничем не примечательной компании в то время, как у остальных — проблема найти хороших...

Ну, моя вселенная, судя по отзывам рекрутеров, как-то ближе к среднему по рынку)

вполне может быть, не берусь сравнивать размеры.

откуда все эти кандидаты взялись в ничем не примечательной компании в то время

мир большой, даже русскоязычный.

в то время, как у остальных — проблема найти хороших...

смотря кого считать — остальными.
но с хорошими да, проблема.
мы так ищем, как я описал — хороших.

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

но то что — чем круче компания, тем больше она перебирает, по моему опыту — факт.

в вашей компании, Luxoft, как понимаю другие правила:

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

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

В Люксе от найма очень далёк (был сильно вовлечён в предыдущей компании — около 100 человек на тот момент), поэтому без понятия; тем не менее (как и в EPAM’е) получил позитивный фидбек от интервьюера сразу же после собеседования с пожеланием скорой встречи. После найма в Люкс, кстати, тоже сказали, что на конкретную вакансию/проект в основном берут кандидатов с бОльшей экспертизой в Ажуре, но взяли меня за общие инфраструктурные скиллы. Поэтому вряд ли крупные компании перебирают — им и позиций больше надо закрыть. Вообще очень мало компаний перебирают, т.к. иначе в текущем состоянии рынка им невозможно будет работать, и это сразу становится достоянием общественности, в т.ч. компании сами об этом пишут (но эта компания и не галера или бодишоп, которой нужны разные люди с разной специфичной экспертизой, и платит сильно выше среднего по рынку при этом).

вот то и непонятно — у лидеров рынка нет отбоя от кандидатов?
мало кто хочет попасть в «локал фаанг»?

Поэтому вряд ли крупные компании перебирают — им и позиций больше надо закрыть

и не хорошими — а лучшими по критериям — западных заказчиков.
в этом то и разница вселенных.

а нам надо — свое пилить.
и по критериям лидеров рынка — у меня знакомых даже нет.
так что наши вселенные — не пересекаются.

отсюда наверное и такая разница в подходах поиска сотрудников, и в частности — проведения собеседований.

Вообще очень мало компаний перебирают, т.к. иначе в текущем состоянии рынка

мной и моими этими знакомыми — перебирают :)

вот и пилим — свое, заказы делаем и т.п.. нас не возьмут в лидеры рынка :)
разумеется, зп ниже лидеров рынка — их источники потому что разные.

в основном берут кандидатов с бОльшей экспертизой в Ажуре

а, ажура...
а мы сами скейлимся :)
так что — просто разные вселенные — нам спец в ажуре и даром не нужен :)

и платит сильно выше среднего по рынку при этом

а мы вобщем-то ниже, и отбою нет :)
такие вот парадоксы — лидеры на более высокие зп — найти не могут
а мы — перебираем :)

Если под лидерами понимать размер, то...

вот то и непонятно — у лидеров рынка нет отбоя от кандидатов?
мало кто хочет попасть в «локал фаанг»?

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

и по критериям лидеров рынка — у меня знакомых даже нет.

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

такие вот парадоксы — лидеры на более высокие зп — найти не могут

Опять же, не-лидеры примерно в той же ситуации и ищут кандидатов на том же рынке, что и лидеры. Часто и деньги такие же платят (или не намного меньше). Плюс эдж-кейсы (не 3й квартиль по ДОУ, а плюс пару тысяч к нему) по деньгам не у лидеров рынка, а либо у залётного аутстаффа с клиентом, который может себе позволить, либо у продуктов, которые целенаправленно снимают сливки (вот их разве что можно назвать «локал фаанг»).

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

То и странно что при таком дефиците программистов кого-то из программистов беспокоят какие-то там матрицы компетентности.

Да каждый год переходи себе на +500 в другую компанию, да и все. И лычки синьора требуй. И все будет, дадут же.
А не, так вакансий же полно, значит дадут в другом месте, а эти жлобы на лычки и пару сотен пусть локти кусают

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

Почему это заканчиваются? Они до бесконечности! Дефицит же. Рынок работника, все дела

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

Недавно открылся магазин, где сео и тим лиды могут выбрать и нанять себе синьора.
У входа висит свод правил работы магазина следующего содержания.

1. Вы можете посетить магазин ТОЛЬКО ОДИН РАЗ.
2. В магазине 6 этажей, качество синьоров повышается с увеличением
порядкового номера этажа.
3. Вы можете выбрать любого синьора на каком-либо этаже или подняться
на верхний этаж.
4. Не разрешается возвращаться на нижний этаж.
Один сео решил посетить этот самый «Магазин синьоров», чтобы найти
себе гребца.
Прочитав у входа на первый этаж вывеску: «синьоры с 7 годами опыта», -
он идет сразу на второй этаж.
Вывеска на втором этаже: «синьоры, хорошо умеющие в гит, паттерны и кодинг».
Сео идет на третий.
Вывеска на третьем этаже: «синьоры, хорошо умеющие в гит, паттерны и кодинг, понимающие в архитектуру». «Ух ты! » - подумал сео, но все же пошел на
четвертый этаж.
Вывеска на четвертом этаже: «синьоры, хорошо умеющие в гит, паттерны и кодинг, понимающие в архитектуру, могущие в devops».
— Невероятно! — воскликнул сео. — Мне очень трудно устоять!
Но, произнеся это, все же поднимается на пятый этаж.
Вывеска на пятом этаже: «синьоры, хорошо умеющие в гит, паттерны и кодинг, понимающие в архитектуру, могущие в devops, укладывающиеся в собственные эстимейты и охотно менторящие джунов».
Сео очень захотелось остаться на этом этаже и выбрать себе синьора, но
все же он, преодолев себя, пошел на последний этаж.
И на шестом этаже он читает вывеску вот такого содержания: «Вы на этом
этаже посетитель № 31 456 012, здесь нет синьоров, этот этаж
существует лишь для того, чтобы лишний раз доказать, что сео и тим лида
удовлетворить невозможно. Благодарим за посещение нашего магазина!»

А прямо напротив этого магазина была открыт для синьоров «выставка галер». На первом
этаже находятся галеры, предоставляющие удаленку. На втором — богатые галеры предоставляющие удаленку, без микроменеджмента, наливающие 5к. А на этажи с третьего по шестой ТАК НИКТО НИ РАЗУ И НЕ ЗАШЕЛ.

Там *подсознательно* теория вероятностей.
Чем бОльше претендентов рассмотрено(участвовало) тем качественее результат.
Вопрос несостоятельности методики отбора — другой вопрос.

В смысле зачем? А если будет на те же деньги сильно лучший?

А если будет на те же деньги сильно лучший?

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

Чтоб это узнать и прийдется всех троих проинтервьюировать

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

Да, но это работает только в волшебном мире Сергея

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

конечно, если вам скалиста-хаскелиста надо, да еще живущего в радиусе полутора часов езды от офиса, то да, проблема

Хм, ну вот вы решили искать работу. Пришли на первое собеседование. Компания — вроде без упоминания на любимом-ИТ. Команда — ну фиг ее знает, вон за стеклом клац-клац делает. Проект — ну по рассказам вроде нормальный. И допустим — вам дают оффер. Бросаете все и принимаете?

У меня был лишь раз за 13 лет работы, когда с первого собеседования я получил оффер и согласился на него (решили +500 к моим начальным хотелкам). В остальных случаях — «спасибо, я подумаю до конца недели».

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

Так что поставить все на одного человека и играть в ждуна — ну право, не очень эффективная стратегия.

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

Так что поставить все на одного человека и играть в ждуна — ну право, не очень эффективная стратегия.

Не совсем понял, что именно в этом случае Вас обезопасит. 2 недели зависят в том числе от того, когда оффер озвучен. Вы же не сделаете 2 оффера, потом один отзовёте в ответ.

Пришли на первое собеседование. Компания — вроде без упоминания на любимом-ИТ. Команда — ну фиг ее знает, вон за стеклом клац-клац делает. Проект — ну по рассказам вроде нормальный. И допустим — вам дают оффер. Бросаете все и принимаете?

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

У меня был лишь раз за 13 лет работы, когда с первого собеседования я получил оффер и согласился на него (решили +500 к моим начальным хотелкам). В остальных случаях — «спасибо, я подумаю до конца недели».

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

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

Вот абсолютно та же фигня. Ценный спец может выбирать проекты. Компания, что платит по верху рынка — может выбирать спецов.

Ну а если попадается «единорог» — то тут конечно да, нужно действовать быстро.

На Хабре вроде недавно пробегала очень похожая табличка, это оттуда?

«Кто первый украл, тот и автор!»

Степень синьoристости соискателя — может оценить лишь другой синьор. Или гуру. И им для оценки, таблички не нужны.

А если не синьор и не гуру — таблички не помогут.

«Чув про основнi вразливостi»
— «Она знала мою единственную слабость — то, что я слаб.» (Simpsons)

А я знаю как определить Даннинга — Крюгера, и эта табличка по-моему как раз оно.

а как различить кто из них Даннинг, а кто Крюгер?

сразу полным комплектом идут оба

Это из серии «джуниор должен знать»?

Настоящий мужчина должен)

А тепер питання: як зрозуміти хто перед тобою сидить, middle чи senior за годину співбесіди? Чи той хто проводить співбесіду сам відповідає даним критеріям хоча би на половину? Якщо це використовується як система грейдів, то чи буде в співробітника можливість довести сво знання на практиці? — бо як показує практика, набрати мідлів та сенйорів правити формочки — легко.

Думаю, варіант — розповісти про складні ситуації, з котрими сам стикався, і подивитись, як людина запропонує їх вирішувати.

Складна ситуація покриє максимум 2 пункти таблиці, як перевірити інші 11?

А навіщо тобі та таблиця? Недостатньо, що людина вміє виходити з технічно складних ситуацій?

Власне, і я про це — нафіга треба ця таблиця?

хто сказав що вона це вміє?
людина просто пригадала одне обговорення подібної ситуації — та й переказала.
якщо людина в програмуванні понад 5 років — то багато що може поразказати — того чого не вміє і ніколи не робила.

2 пункта это если тушат пожар последствий.
Действительно сложная ситуация это когда до того как *это* произошло никто даже не имел представления о сабже.
А тут синьер = человек оркестр, если отвечать честно без применения софт-скилов.

никто даже не имел представления о сабже

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

хто швидше зрозуміє як використати сабж

Час це метрика?

його правильно і швидко.

Забули ще, про *дешево, а краще безкоштовно* для повної картини.
Вже давно, придумали рівні кваліфікації, згідно яких можна визначити зміст(та обсяги) завдань для спеціаліста.
Але в *Айтишичке* трапилася *повінь* і тепер крокодили з мавпами цари звірів у джунглях а не леви. 8)

Час це метрика?

Хто як вважає, а головне, як вимірює

Забули ще, про *дешево, а краще безкоштовно* для повної картини.

Не зрозумів до чого це написано

Вже давно, придумали рівні кваліфікації,

Ті хто придумав, нехай його і використовують

Але в *Айтишичке* трапилася *повінь* і тепер крокодили з мавпами цари звірів у джунглях а не леви.

Вистачає того що в державних установах барашки мнять себе левами. То ж краще не лізти зі своїми постановами в налагоджені процеси

Вистачає того що в державних установах барашки мнять себе левами.

Вислів *Офісні тигри* вам щось каже? 8)

Ті хто придумав, нехай його і використовують

Безперечно, будуть наслідки такого світогляду, але як ви, і натякали, це — не моя справа.

То ж краще не лізти зі своїми постановами в налагоджені процеси

Убогість системи(в.д.в. процессів), визначається в тому числі не бажанням її порівнювати з аналогами по тому що вона не витримує порівняння.

тільки пояснення займе хвилин 10-15. і людина буде думати хвилин 10-15.
і розповідати буде — хвилин 10-15.
от вся співбесіда й закінчиться. причому відповідь буде погана, якщо людина не зтикалась з точнісінько такою ж ситуацією — не зная подробиць, вибере поганенький варіант

якщо співбесіда години на 3 мінімум, ну тоді так, можна «попрацювати» разом над складною ситуацією.

Можна ретельно підготувати сценарій заздалегіть.
Навіть дати кандидату наперед, завдання.
А на співбесіді він мае захистити свій варіант рішення.
* Вже сам хочу на таку співбесіду, набридло лічити порти та вгадувати як саме написав *папередник* лисапеди на баш\повершелл.

А тепер питання: як зрозуміти хто перед тобою сидить, middle чи senior за годину співбесіди?

за годину можна зрозуміти тільки такого ж або нижче
тому — сіньор сіньора побачить. а от мідл сіньора — ні. може навіть бути впевненим що спілкувався з якимось джуном обізнаним.

Чи той хто проводить співбесіду сам відповідає даним критеріям хоча би на половину

звісно що наврядчи усім критеріям.

головна різниця між джуном — мідлом — сіньором — якісна: розуміння.
джун — нічого не розуміє, добрий — як завчив на пам’ять.
мідл — розуміє одне відокремлено від іншого.
а сіньор починається с розуміння яке стає інтуіцією. при тому — має софтскіл — пояснити мідлу. (джуну пояснити теж можна, за декілька місяців)

то чи буде в співробітника можливість довести свої знання на практиці?

залежить від проекту, та працелюбності. працелюбность на годинній співбесді — не виявиш.

Бачу весело у вас там в Білорусі

«Знає основні проблеми демони і як їм запобігати»
не вызывать демонов?

В команді має бути екзорцист для вирішення проблем такого роду

3 последние строки задачи девопса, нет?
Или опять про фулстек?
Или знание(названия)?
Декларируя такие требования вы подразумеваете что сами *преисполнились*.
Наберите меня, отлетите после 3 вопроса по тсп-ип как джуниор в лучшем случае.
А я просто пол в серверной мою иногда.

Ну і це цікаво(окрім фронтенду з написанням красивих формочок)

Нє, от шо ви маєте протів «красівих формочек»? — «нормальна внучка нормального дедушки» © Спробуйте написать складну форму з купою валідацій, опціональних полів, автозаповнень, картами, графіками, автентифікаціями, сторами для багатосторінкових форм, сервісами для проміжних розрахунків, з можливістю кастомізації клієнтом, перекладом всього, інтеграцією сторонніх сервісів і т.д. А ще — зоопарк бровзерів, фрейморків, бібліотек, всякі openAPI/GraphQL... І вас також заставлять писать скріпти для Дженкінса, і юніт-з-інтегрешн тести під все це...Самі скажете, шо манали все це і підете не таким замороченим бекендом займатись...

SPA — то просто підхід до оранізації аплікації. До речі, чистий SPA підхід рідко зустрінеш на більш-менш великих продуктах. Частіше використовується гібридний — і SSR, і SPA.

Фреймворки, звісно, допомагають — сексу менше, ніж писати аплікацію тільки на jQuery. Але і гемору додають — адже накладають деякі обмеження і треба під них підстраюваться...

Тож мій поінт у тому, шо зверхність до «формошльопів» — то тільки від нерозуміння того, що фронтенд за складністю іноді вже доганяє бек, а то і переганяє...

Это ж классика. Слышишь про формочки, говори что все бэкендеры одни круды делают. И наоборот.

складну форму з купою валідацій, опціональних полів, автозаповнень

ух как это серьезно звучит) прямо как у Воловитца)))
youtu.be/Hndxgs77N9k?t=51

Підписатись на коментарі