Офер за 1 день в команду BetterMe (Frontend Hiring, JavaScript/React/Redux)
×Закрыть

«А ти точно senior?»

Привіт, я тех/тім лід в одній з продуктових web компаній — час від часу займаюся співбесідами. Для мене головною проблемою є зрозуміти хто перед тобою senior, або не дуже. А якщо ще потрібно узгодити думку з іншим інтерв’юером ...

Якщо ви займаєтеся WEB розробкою і хочете зрозуміти свій рівень, або стоїте на варті компанії, але не до кінця розумієте як визначити рівень кандидата ласкаво прошу далі.

Важливий момент до якого я дійшов — поняття рівня дуже суб’єктивно і залежить від типу компанії й завдань які вона вирішує. В принципі на цьому можна було б закінчити статтю, але спробуймо піти трохи далі.

Для себе я виділив два основних напрями — аутсорс і продуктові компанії.
Для аутсорсу важливіше широкий спектр технологій з якими стикався кандидат.
У продуктовій буде акцент глибоке розуміння технологій і принципи написання підтримуваного коду.

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

Найпростіша відповідь на питання: «аякже зрозуміти який у мене рівень» — той за який тобі згодні платити. Але ж ви тут витрачаєте час не для цієї демагогії, тому я спробував формалізувати цю відповідь.

І поки не забув, підпишіться на мій канал в телеграм t.me/resilience_engineering, щоб не пропустити нові публікації, також буду ділиться короткими роздумами на теми розробки, відписатися завжди встигнете :)

Отож наш герой дня, таблиця навичок для web розробника, врахуйте що таблиця вказує на середній / верхній поріг рівня, для нижнього можна на свій розсуд прибрати частину пунктів.

На жаль тут неможливо зробити таблицю — тому гугл таблиці та картинка)

docs.google.com/...​Z67tVwt0/edit?usp=sharing

👍НравитсяПонравилось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 вариантов замены при отсутствии товара, редактирование корзины (удаление позиции, изменение количества товара по позиции).
Может, чего забыл, давно это было.

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

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

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

Да. И что?

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

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

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

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

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

Т.е. магазин был serverless, просто присоединен к условному Firebase Database?

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

Ну тогда действительно глупо называть это «полнофункциональным интернет магазином», ведь его как-то наполняют, у него есть какая-то админка, главный модуль — это сервер. А мобильное приложение действительно просто клиент. Я помню, пару месяцев работал над мобильным приложением в сфере гемблинга, www.ifortuna.cz. Тоже мог бы рассказывать что делал «полнофункциональный гемблинг сервис», но это ведь не так.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не хранит платежные данные, 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й миддл.

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

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

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

По лінку трохи не так напряжно написано)

«perhaps another way of defining what an intermediate software engineers is... an intermediate software engineers is a software engineer who can work on and complete a small well-defined task»

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

Ну от знову, по лінку мені здалося не так жорстко. Там же ще вище сеньйора левели є. Команда там чувак написав це вже стаф інженер.

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

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

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

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

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

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

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

Це жахливо. Мені теж один клієнт на фрілансі казав, що він за 25-30 сіньйорів наймає, і я до 20 ще не доріс. Але я просто пішов до інших. Хоча раніше думав що фрілансні 20 це огого експертиза потрібна. Таких булінг роботодавців потрібно обходити/йти від них.

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

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

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

2500 то мідл. В мідлах довго не затримуються.

$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. Что при таких суммах уже несущественно.

Если так то грустно. Я думал что 5к не проблема

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

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

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-м годом.
Такое вот «развитие».

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

Stable release

SQL:2016 / December 2016; 4 years ago

SQL:2016 / December 2016; 4 years ago

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

SQL/PSM

SQL/PSM was later incorporated into the multi-part SQL:1999 standard, and has been part 4 of that standard since then, most recently in SQL:2016.

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

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

Там, похоже, расширили 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 ? В тому, що завершено і самодостатньо. Синтаксичного цукру насипати, як в мови програмування, щоб імітувати стильно, модно, молодьожно ? Типу, не SELECT * FROM Table..., а (*) : Table => ... щоб було ?

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

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

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

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

І багато ти бачив «західного ентерпрайза», щоб так радикально ? Я постійно бачу, і нові проекти теж, з доступом і логікою реляційної бд в хранімках. Хоча Code guru, вони ж, мабуть, як NodeJS ninja — sqlя не знають ;)

Ну на самом деле еще дохиба проектов с логикой в хранимках, но везде где встречал это переписывается (последние два проекта именно такие) бизнесс логика в хранимках это днище.
Можно конечно и так но оно того не стоит и все крайне геморно становится а главное что толку от этого ноль на палочке. Сиквел должне хранить\собирать\агрегировать данные но никак не изменять и боже упаси — знать что-то о 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 я упоминать не буду. это и в «индию» заглядывать не нужно.

тот кто умеет только в ORM — и не увидит даже.

„Another aspect of the design that changed significantly in 3.x is that we now always generate a single SQL statement per LINQ query. In previous versions, we used to generate multiple SQL statements in certain cases, translated Include() calls on collection navigation properties and translated queries that followed certain patterns with subqueries. Although this was in some cases convenient, and for Include() it even helped avoid sending redundant data over the wire, the implementation was complex, and it resulted in some extremely inefficient behaviors (N+1 queries). There were situations in which the data returned across multiple queries was potentially inconsistent.”

Проблема в ОРМ була, її там вже пофіксали.

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

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

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

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

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

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

Нет, если, конечно, бизнес-модель предполагает найм одного 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. Оскорбления
Это низший уровень несогласия и, пожалуй, самый распространенный. Мы все видели комментарии вроде
«Вот же ты козлина!!!!!!»
Важно также осознавать, что более многословное оскорбление имеет такой же вес. Комментарий вроде
«Это написал дилетант с завышенной самооценкой»
— просто пафосный способ сказать «Вот же ты козлина!»
Пол Грэм. Как правильно возражать

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

А фейл білда тому, що лінту не подобається пробел в кінці строки не хочеш ?

Ну ніхто ж не довів теорему про те, що наявність юніт-тестів підвищує шанс проекту на успішне завершення. Як більшість проектів в давні часи фейлілись частково чи повністю, так і зараз. І мені здається, що зараз більше ;)
Я от, наприклад, як не один раз бачив проекти з хранімками на sql, так і не перший раз бачу проект, в який тягнуть всі бест практики — і епічний просир всього в результаті.

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

а кого цікавить успішне завершення, в тому ж аутсорсі?

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

а успіх проекту, то такє. гроші ж отримуються не за успіх — а за працю. праця була — плати!

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

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

там же треба показувати — метрики. а покриття — то дуже зручна метрика. ... а успіх проекту, то такє

Хорошо. Вот у вас есть условный проект. Ну, не знаю там, 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

фабричный метод против абстрактной фабрики

вилкой в глаз или в жопу раз

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

Часто разумно выкинуть нафиг и заюзать pimpl. Код будет понятнее и саппортить его сможет даже июнь.

Моє питання — як знання цього факту який можна дізнатися за кілька секунд показує відповідність кандидата проекту чи компанії в цілому?

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

Між сеньйором який ніколи не писав на плюсах чи писав дуже давно, і сеньйором який вміє лише в одну технологію (навіть якщо це С++) я виберу не того хто знає на пам’ять про віртуальні деструктори, а того хто вміє розв’язувати задачі і тягти проекти і фічі до завершення. Хіба не логічно?

Для мене ці питання про якісь нюанси наче ми на іспиті на 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льки? Я хочу синтезировать из свинца золото, а у меня нет денег на оборудование... Куда это годится??

питання до автору: А ти точно тімлід? А на аутсорсингу зможеш стати тімлідом?)

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

по вечерам тренировать модельки.

З великими boobs.

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

Не стоит заниматься подменой понятий, да еще и настолько неуклюжей. Речь в основном шла о том, что синьор должен ясно представлять бизнес-контекст конкетной задачи с точки зрения реализации и 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, якому рік від народженя і де скрипти в бранчах зберігаються, аби було свіженьке з пилу, з жару, дуже модно ? Якщл у вас там VSTS була якась. І скільки людьских місяців праці витратилии на написання екшнів і розмноженя воркфловів по репам ?

тягнути 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%

Это у трупов уже. У сеньjров 10%.
З.Ы. Я надеюсь мы о програмерском коде, а не о ДНК.

у сеньоров 0%

Oh my sweet summer child

Наивный. Как раз у младенчиков ошибок меньше. А вот у мамкин-синьор-архитектов...

Значить той красивий код писав джун, який недавно прочитав про SOLID.

Или хотя бы 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-презентации — это, ИМХО, чистой воды мошенники, корпоративные инфоцыгане.

Если это аутстафф, т.е. технологическое ядро разработки полностью у заказчика — то это ок. Пусть хоть тысячами нанимают с Украины, РФ, Индии и самостоятельно, удалённо управляют разработкой и полностью несут риски за конечный результат. А если начинается «мы предоставляем специалистов с доменной, технологической экспертизой для заказчика», от вас только менеджер и/или контактное лицо, т.е. стандартный аутсор