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

Илья Цапу 09.02.2021 12:38

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

Andrew Frolov 08.02.2021 10:01

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

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

Sergey Poprygin Software Engineer 07.02.2021 23:51

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

Lev Andropov 04.02.2021 11:27

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

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

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

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

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 14:30

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

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

Lev Andropov

Lev Andropov 04.02.2021 16:32

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 16:38

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

Lev Andropov

Sergey Lysak T/T Lead 04.02.2021 16:46

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 19:44

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

Sergey Lysak T/T Lead 04.02.2021 20:26

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

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

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

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

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

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

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

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

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

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 20:34

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

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

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

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

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

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

Sergey Lysak T/T Lead 04.02.2021 20:38

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

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

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

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

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

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

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

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

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 22:48

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

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

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

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

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

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

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

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

Sergey Lysak T/T Lead 04.02.2021 23:00

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 05.02.2021 09:45

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 04.02.2021 20:46

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

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

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

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

Sergey Lysak T/T Lead 04.02.2021 21:07

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

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

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

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

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

Andrew Frolov 04.02.2021 21:13

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 22:50

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

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

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 04.02.2021 23:05

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

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

Sergey Lysak T/T Lead 04.02.2021 23:08

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

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

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

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

Lev Andropov 04.02.2021 17:05

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 19:51

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

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

Lev Andropov

Lev Andropov 04.02.2021 20:27

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

anonymus ps 04.02.2021 21:13

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

Sergey Lysak T/T Lead 04.02.2021 21:21

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

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

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

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

Yaroslav Shevchuk Staff Software Engineer в Bolt 07.02.2021 12:36

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 22:53

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

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

anonymus ps 05.02.2021 07:40

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 05.02.2021 09:39

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

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

Oleksandr Golovatyi -`★´- в ☁︎ 05.02.2021 21:39

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 06.02.2021 08:51

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

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

Oleksandr Golovatyi -`★´- в ☁︎ 06.02.2021 22:13

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 06.02.2021 22:53

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

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

Oleksandr Golovatyi -`★´- в ☁︎ 07.02.2021 00:00

Да. И что?

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

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 11:58

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

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

anonymous 07.02.2021 12:11

-

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 12:29

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

anonymous

anonymous 07.02.2021 12:46

-

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 19:17

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

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

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

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

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

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

anonymous

anonymous 07.02.2021 19:25

-

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 19:36

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

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

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

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

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

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

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

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

anonymous

Oleksandr Golovatyi -`★´- в ☁︎ 07.02.2021 19:29

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

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

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 19:37

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

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

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

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

Oleksandr Golovatyi -`★´- в ☁︎ 07.02.2021 19:46

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

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

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 19:52

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

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

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

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

Oleksandr Golovatyi -`★´- в ☁︎ 07.02.2021 20:07

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 08.02.2021 11:26

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

И что?

Oleksandr Golovatyi -`★´- в ☁︎ 08.02.2021 20:06

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 08.02.2021 22:35

И что это меняет?)

Oleksandr Golovatyi -`★´- в ☁︎ 08.02.2021 22:54

Те що ось це

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 09.02.2021 07:48

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

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

Sergey Lysak T/T Lead 07.02.2021 20:52

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 08.02.2021 11:27

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

anonymus ps 08.02.2021 12:28

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

Sergey Lysak T/T Lead 08.02.2021 13:19

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

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

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

Sergey Lysak T/T Lead 07.02.2021 20:51

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

понятно.

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

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

?

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

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

Sergey Lysak T/T Lead 07.02.2021 20:46

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oleksandr Golovatyi -`★´- в ☁︎ 07.02.2021 18:59

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

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

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

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

Denys Poltorak Embedded | C++ 07.02.2021 19:05

Smart UI (DDD) pattern
grahamberrisford.com/...on script.htm#_Toc6939582

Oleksandr Golovatyi -`★´- в ☁︎ 07.02.2021 19:32

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 19:07

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

Почему?

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

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

Oleksandr Golovatyi -`★´- в ☁︎ 07.02.2021 19:27

Почему?

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

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

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

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

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

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

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

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

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 19:44

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

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

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

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

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

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

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

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

Oleksandr Golovatyi -`★´- в ☁︎ 07.02.2021 19:50

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

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

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

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

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

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

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

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

Sergey Lysak T/T Lead 07.02.2021 20:55

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

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

Sergey Lysak T/T Lead 07.02.2021 20:54

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

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

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

Andriy Prokopiv Project Manager в LYNQ Ltd 03.02.2021 19:33

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

Олег Дорожко 02.02.2021 16:23

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

Ольга Пиц 02.02.2021 15:08

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

Sergey Lysak T/T Lead 02.02.2021 15:12

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

Ольга Пиц

CodeGuru 02.02.2021 15:13

По рекомендациям.

Sergey Lysak T/T Lead 02.02.2021 16:32

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

CodeGuru

CodeGuru 02.02.2021 17:03

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

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

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

Sergey Lysak T/T Lead 02.02.2021 17:38

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

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

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

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

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

CodeGuru

CodeGuru 02.02.2021 17:47

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

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

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

Sergey Lysak T/T Lead 02.02.2021 19:05

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

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

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

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

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

CodeGuru

CodeGuru 02.02.2021 19:26

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

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

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

Sergey Lysak T/T Lead 02.02.2021 19:33

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

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

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

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

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

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

CodeGuru

Denys Poltorak Embedded | C++ 02.02.2021 19:33

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

flyman 03.02.2021 15:49

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

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

Denys Poltorak Embedded | C++ 03.02.2021 16:07

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

flyman

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 02.02.2021 20:17

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 02.02.2021 18:02

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

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

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

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

Sergey Lysak T/T Lead 02.02.2021 18:08

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

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

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

всегда.

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

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

Elizaveta Voron Engineering Manager 01.02.2021 18:26

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

Oksana Chuiko Software Engineer в Pure Storage 30.01.2021 08:29

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

Olexandr 30.01.2021 08:31

Доповніть! Цікаво.

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

Oksana Chuiko Software Engineer в Pure Storage 30.01.2021 08:53

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

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

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

Olexandr

Olexandr 30.01.2021 09:17

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

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

«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»

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

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

Oksana Chuiko Software Engineer в Pure Storage 30.01.2021 09:27

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

Olexandr

Влад Мельник Senior StackOverflow Developer 02.02.2021 18:24

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

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

Andrew Frolov 30.01.2021 09:01

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

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

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

Olexandr

Olexandr 30.01.2021 09:22

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

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

Andrew Frolov 30.01.2021 09:41

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

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

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

Olexandr

Olexandr 30.01.2021 10:03

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

flyman 30.01.2021 12:24

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

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

Alex Fogol Software Developer, C/C++ Expert 30.01.2021 23:20

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

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

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

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

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

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

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

Employers subject to the Fair Labor Standards Act ...

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

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

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

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

flyman

flyman 30.01.2021 23:26

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

Alex Fogol Software Developer, C/C++ Expert 30.01.2021 23:32

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

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

flyman

anonymous 31.01.2021 09:33

-

flyman

flyman 31.01.2021 09:37

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

anonymous

Oleksandr Golovatyi -`★´- в ☁︎ 31.01.2021 05:43

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

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

Oksana Chuiko Software Engineer в Pure Storage 30.01.2021 09:01

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

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

Olexandr

Alex Fogol Software Developer, C/C++ Expert 30.01.2021 23:22

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

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

Denys Poltorak Embedded | C++ 30.01.2021 23:27

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

Alex Fogol Software Developer, C/C++ Expert 30.01.2021 23:42

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

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

anonymous 31.01.2021 09:21

-

Alex Fogol Software Developer, C/C++ Expert 31.01.2021 16:43

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

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

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

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

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

anonymous

anonymous 31.01.2021 18:59

-

Oksana Chuiko Software Engineer в Pure Storage 31.01.2021 01:05

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

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

anonymous 31.01.2021 09:23

-

anonymous 31.01.2021 09:20

-

anonymous 03.02.2021 17:37

-

Oksana Chuiko Software Engineer в Pure Storage 03.02.2021 22:26

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

anonymous

Alex Fogol Software Developer, C/C++ Expert 04.02.2021 03:36

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 14:35

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 04.02.2021 16:49

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

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

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

Sergey Lysak T/T Lead 04.02.2021 17:10

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

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

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

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

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 19:59

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

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

Oksana Chuiko Software Engineer в Pure Storage 04.02.2021 20:12

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

Sergey Lysak T/T Lead 04.02.2021 20:32

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

Oksana Chuiko Software Engineer в Pure Storage 04.02.2021 20:42

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

Sergey Lysak T/T Lead 04.02.2021 21:12

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

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

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

Oksana Chuiko Software Engineer в Pure Storage 04.02.2021 21:33

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

Sergey Lysak T/T Lead 04.02.2021 21:38

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

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

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

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

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

Oksana Chuiko Software Engineer в Pure Storage 04.02.2021 21:50

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 22:57

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 04.02.2021 23:06

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 05.02.2021 09:41

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

Yaroslav Shevchuk Staff Software Engineer в Bolt 07.02.2021 12:57

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

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 20:35

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

Oksana Chuiko Software Engineer в Pure Storage 04.02.2021 21:54

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 04.02.2021 22:59

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

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

Oksana Chuiko Software Engineer в Pure Storage 04.02.2021 23:01

в Украине?

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 05.02.2021 09:42

И в Украине, и в США.

Oksana Chuiko Software Engineer в Pure Storage 05.02.2021 20:24

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 06.02.2021 08:45

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

anonymus ps 06.02.2021 09:16

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 06.02.2021 09:23

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

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

anonymus ps 06.02.2021 09:29

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

anonymous 07.02.2021 12:12

-

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 12:31

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

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

anonymous

anonymous 07.02.2021 12:57

-

Oksana Chuiko Software Engineer в Pure Storage 06.02.2021 09:29

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 06.02.2021 09:59

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

Oleksandr Golovatyi -`★´- в ☁︎ 06.02.2021 22:14

Нє очень і хотєлось.

Nikola Utiuzhnikov Кодировщик 07.02.2021 10:46

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

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 07.02.2021 12:01

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

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

Nikola Utiuzhnikov

Сергій Назаревич Java team lead/ Senior Java Software Engineer в Luxoft 30.01.2021 03:17

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

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

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

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

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

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

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

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

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

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

anonymus ps 30.01.2021 08:10

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

flyman 30.01.2021 08:32

CS це не про інженерію, на жаль

Alex Fogol Software Developer, C/C++ Expert 30.01.2021 23:22

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

flyman

Мамкин АЙПИшник 02.02.2021 16:27

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

Sergiy Morenets Java evangelist 28.01.2021 00:01

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

Alex Fogol Software Developer, C/C++ Expert 28.01.2021 02:21

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

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

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

Dmytro Lapshyn Chief Technology Officer в Telmie 28.01.2021 11:43

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

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

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

не знати про NoSQL

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

Yuriy Zaliznyak regular pizza delivery officer 28.01.2021 11:52

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

Dmytro Lapshyn Chief Technology Officer в Telmie 28.01.2021 12:10

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

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

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

Yuriy Zaliznyak

anonymus ps 28.01.2021 12:57

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

рекурсия

Dmytro Lapshyn Chief Technology Officer в Telmie 28.01.2021 13:04

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

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

anonymus ps 28.01.2021 13:07

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

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

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

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

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

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

Andrey Yakovlev PHP-developer 29.01.2021 16:28

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

Yuriy Zaliznyak

Bot Bot 28.01.2021 12:38

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

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

Dmytro Lapshyn Chief Technology Officer в Telmie 28.01.2021 12:52

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

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

Bot Bot

Bot Bot 28.01.2021 13:16

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

Oleksandr Golovatyi -`★´- в ☁︎ 28.01.2021 21:10

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

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

Dmytro Lapshyn Chief Technology Officer в Telmie 29.01.2021 09:26

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

Olexandr 29.01.2021 19:13

Ковбаса як тема підійде?

anonymus ps 28.01.2021 12:59

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

Bot Bot

Bot Bot 28.01.2021 13:19

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

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

anonymus ps 28.01.2021 13:21

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

Bot Bot

Bot Bot 28.01.2021 13:25

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

anonymus ps 28.01.2021 13:28

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

Bot Bot

Bot Bot 28.01.2021 13:30

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

Sergii Marushchenko .NET 28.01.2021 23:00

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

Bot Bot

Sergiy Morenets Java evangelist 28.01.2021 15:14

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

Andrew Frolov 28.01.2021 16:31

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

Dmytro Lapshyn Chief Technology Officer в Telmie 28.01.2021 16:51

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

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

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 28.01.2021 17:20

або навіть Spring

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

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

Dmytro Lapshyn Chief Technology Officer в Telmie 28.01.2021 19:14

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 28.01.2021 20:20

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

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

Dmytro Lapshyn Chief Technology Officer в Telmie 29.01.2021 09:37

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

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

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

Сергій Назаревич Java team lead/ Senior Java Software Engineer в Luxoft 30.01.2021 03:38

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

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

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

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

Oksana Chuiko Software Engineer в Pure Storage 30.01.2021 08:55

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

Dmytro Lapshyn Chief Technology Officer в Telmie 01.02.2021 09:42

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

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

Oksana Chuiko Software Engineer в Pure Storage 04.02.2021 20:51

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

Left Outer Join 28.01.2021 21:06

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

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

Helena Logodska DWH Engineer в metafinanz Informationssysteme GmbH 29.01.2021 09:40

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

Сергій Назаревич Java team lead/ Senior Java Software Engineer в Luxoft 30.01.2021 03:55

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

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

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

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

anonymus ps 30.01.2021 08:18

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

Олексій Пєніє Developer, Java в забугорье 31.01.2021 13:37

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

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

anonymous 31.01.2021 13:58

-

Dmytro Lapshyn Chief Technology Officer в Telmie 31.01.2021 15:15

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

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

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

Олексій Пєніє Developer, Java в забугорье 31.01.2021 16:57

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

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

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

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

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

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

Dmytro Lapshyn Chief Technology Officer в Telmie 01.02.2021 09:52

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

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

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

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

Sergey Lysak T/T Lead 01.02.2021 15:21

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

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

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

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

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

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

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

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

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

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

CodeGuru 01.02.2021 15:30

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

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

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

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

Sergey Lysak T/T Lead 01.02.2021 15:49

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

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

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

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

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

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

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

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

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

CodeGuru

CodeGuru 01.02.2021 15:57

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

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

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

Sergey Lysak T/T Lead 01.02.2021 16:15

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

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

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

CodeGuru

Olexandr 01.02.2021 16:20

Цікавий у вас тут срач. Обі сторони наводять хороші аргументи. Але я так і не зрозумів як краще, і коли.

Про відмінності баз теж цікаве питання. Враховуючи моду на ОРМ, мета яких узагальнити максимально роботу з базами. Хоча звісно чим більший проект тим важче тримати роботу в межах АПІ ОРМ, і доводиться прописувати функції конкретної бази.

CodeGuru 01.02.2021 16:21

Непонятно правда почему все более дивными фичами обрастает троица 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-м годом.
Такое вот «развитие».

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

Olexandr 01.02.2021 16:25

Stable release

SQL:2016 / December 2016; 4 years ago

CodeGuru

CodeGuru 01.02.2021 16:31

SQL:2016 / December 2016; 4 years ago

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

Olexandr

Olexandr 01.02.2021 16:36

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.

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

CodeGuru

CodeGuru 01.02.2021 16:45

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

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

Olexandr

Sergey Lysak T/T Lead 01.02.2021 16:41

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

CodeGuru

anonymous 01.02.2021 17:08

-

CodeGuru

CodeGuru 01.02.2021 17:16

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

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

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

anonymous

Олексій Пєніє Developer, Java в забугорье 02.02.2021 13:37

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

anonymous

anonymous 01.02.2021 17:02

-

CodeGuru

Bot Bot 01.02.2021 18:32

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

anonymous

Bot Bot 01.02.2021 19:18

.

anonymous

Dmytro Lapshyn Chief Technology Officer в Telmie 01.02.2021 15:44

потому что — это проверенная десятилетиями практика, надежно.
И кода на 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 на уровне БД не видел эдак с самого начала нулевых.

anonymus ps 01.02.2021 15:53

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

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

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

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

Dmytro Lapshyn Chief Technology Officer в Telmie 01.02.2021 16:12

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 01.02.2021 19:25

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

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

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

Sergey Lysak T/T Lead 02.02.2021 07:31

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

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

Sergey Lysak T/T Lead 01.02.2021 16:05

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

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

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

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

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

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

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

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

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

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

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

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

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

CodeGuru 01.02.2021 16:11

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

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

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

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

Sergey Lysak T/T Lead 01.02.2021 16:17

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

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

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

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

CodeGuru

CodeGuru 01.02.2021 16:26

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

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

Sergey Lysak T/T Lead 01.02.2021 16:29

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

CodeGuru

CodeGuru 01.02.2021 19:51

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

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

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

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

Sergey Lysak T/T Lead 01.02.2021 20:02

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

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

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

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

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

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

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

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

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

CodeGuru

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 01.02.2021 19:15

А как же

(самый яркий пример что видел — когда офисное приложение-клиент на дельфи, уже в количестве 4 штук клало на лопатки локальную сеть

Аргумент блондинки: «А вот я знаю случай!»
не обсуждаю.

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

Sergey Lysak T/T Lead 01.02.2021 19:31

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

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

Bot Bot 01.02.2021 20:44

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

Sergey Lysak T/T Lead 01.02.2021 20:51

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

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

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

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

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

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

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

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

Bot Bot

Olexandr 01.02.2021 21:05

тот кто умеет только в 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.”

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

Олексій Пєніє Developer, Java в забугорье 01.02.2021 16:00

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

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

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

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

Dmytro Lapshyn Chief Technology Officer в Telmie 01.02.2021 16:17

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

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

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

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

Sergey Lysak T/T Lead 01.02.2021 16:27

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

уже ответили

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

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

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

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

Vova Lviv 01.02.2021 17:15

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

Sergey Lysak T/T Lead 01.02.2021 17:19

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

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

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

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

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

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

Vova Lviv

Bot Bot 01.02.2021 18:36

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

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

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

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

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

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

Sergey Lysak T/T Lead 01.02.2021 19:08

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bot Bot

Bot Bot 01.02.2021 19:13

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

Sergey Lysak T/T Lead 01.02.2021 19:28

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

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

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

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

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

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

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

Bot Bot

Olexandr 01.02.2021 19:29

Sergey, you are toxic.

Sergey Lysak T/T Lead 01.02.2021 19:32

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

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

Olexandr

Bot Bot 01.02.2021 20:47

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

Sergey Lysak T/T Lead 01.02.2021 20:56

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

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

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

Bot Bot

Olexandr 01.02.2021 21:08

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

Можна погуглити ангнет. Звідти всі тренди йдуть.

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 01.02.2021 19:49

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

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

Sergey Lysak T/T Lead 01.02.2021 19:53

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

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

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

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 01.02.2021 20:34

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

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

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

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

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

Sergey Lysak T/T Lead 01.02.2021 20:43

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

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

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

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

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

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

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

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

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 14:09

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

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

Sergey Lysak T/T Lead 02.02.2021 14:52

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

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

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 проекта означает, что проект будет устойчиво развиваться, если его покинет даже большое количество программистов.
википедия

Yuriy Pavlenko Embedded Software Developer 02.02.2021 15:27

Вот это

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. Тесты должны выдавать один и тот же результат, если их код и окружение в котором запускаются, не менялся. А опытные и сверхопытные тоже могут лажать. Так что можете рассматривать тесты как один из элементов, принимающий решение уйдет система в опасный отказ или нет.

Sergey Lysak T/T Lead 02.02.2021 15:44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 17:09

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

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

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

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

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

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

Sergey Lysak T/T Lead 02.02.2021 17:45

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 02.02.2021 17:44

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

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 02.02.2021 18:04

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

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

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

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

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

Sergey Lysak T/T Lead 02.02.2021 18:23

Начиная с документирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 02.02.2021 19:30

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

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

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

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

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

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

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

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

Sergey Lysak T/T Lead 02.02.2021 19:36

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

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 17:12

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

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

Sergey Lysak T/T Lead 02.02.2021 17:47

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

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

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 18:08

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

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

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

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

Sergey Lysak T/T Lead 02.02.2021 18:32

Загуглить как рассчитывается наработка на отказ

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

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

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

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

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

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

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 19:30

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

ну да, ну да

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

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

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

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

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

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

Sergey Lysak T/T Lead 02.02.2021 19:35

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

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

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

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 19:46

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

Sergey Lysak T/T Lead 02.02.2021 19:54

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 20:04

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

Sergey Lysak T/T Lead 02.02.2021 20:06

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

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 21:04

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

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

Sergey Lysak T/T Lead 02.02.2021 21:17

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

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

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

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

Yuriy Pavlenko Embedded Software Developer 02.02.2021 22:08

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

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

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

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

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

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

Sergey Lysak T/T Lead 02.02.2021 22:18

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

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

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

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

Но вы зашли сразу «с козырей» :)
И дальше ничего удивительного -все по выбранной себе роли :)

Yuriy Pavlenko Embedded Software Developer 02.02.2021 23:22

Ну вот видите, всего пару моих фраз порождает текстовое недержание. Представляете что случится, если я, не приведи Ктулху, начну на открытые вопросы отвечать? ))

Вы ж повелись.

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

Sergey Lysak T/T Lead 03.02.2021 08:49

Представляете что случится, если я, не приведи Ктулху, начну на открытые вопросы отвечать?

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

Например вот из этой:
УН0. Оскорбления
Это низший уровень несогласия и, пожалуй, самый распространенный. Мы все видели комментарии вроде
«Вот же ты козлина!!!!!!»
Важно также осознавать, что более многословное оскорбление имеет такой же вес. Комментарий вроде
«Это написал дилетант с завышенной самооценкой»
— просто пафосный способ сказать «Вот же ты козлина!»
Пол Грэм. Как правильно возражать

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

anonymous 01.02.2021 20:59

-

anonymous 01.02.2021 20:57

-

Sergey Lysak T/T Lead 01.02.2021 21:02

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

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

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

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

anonymous

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 01.02.2021 23:02

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

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

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

Хорошо. Вот у вас есть условный проект. Ну, не знаю там, 10 модулей, 5000 строк кода, или 20 модулей и 20000 строк, не принципиально. Каким образом вы можете хотя бы очень примерно оценить качество кода? Желательно в измеримом виде, а не «я ревьювил, все Ок, отвечаю». Или эта информация тоже НЕ НУЖНА ?

P.S. Ну и без демагогии на тему «видел проект с хорошим покрытием, но внутри ужасный» — такие случаи тоже бывают. Но их много меньше обратных. Хотя бы потому, что при достаточном количестве нормально написанных юнит тестов, стуктура проекта скорее всего будет более-менее вменяемой, с минимумом функций с запредельной цикломатической сложностью и гвоздями прибитых зависимостей. Иначе написать нормальные тесты либо очень трудозатратно, либо просто невозможно. Вот именно это и есть главный плюс, а не абстрактное число в 63.5% на выходе

Sergey Lysak T/T Lead 02.02.2021 07:39

Первый раз слышу о таком правиле.

Это было от Д. фон Неймана

Это просто переворот в теории надежности.

фон Нейман да, кретин.

Каким образом вы можете хотя бы очень примерно оценить качество кода?

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

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

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

Увлечение метриками — анализом кругов на воде — это ж и есть работа менеджера :)

Олексій Пєніє Developer, Java в забугорье 01.02.2021 18:44

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

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

Грубо говоря, такого кода <0.01%, и потому так просто забыть о его существовании. А потом кусать локти, когда окажется что какую-нить неочевидную логику убрали при рефакторинге, потому что «проще было с нуля переписать».

Dmytro Lapshyn Chief Technology Officer в Telmie 02.02.2021 12:56

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

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

Олексій Пєніє Developer, Java в забугорье 02.02.2021 13:21

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

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

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

В этом весь смысл ООП. Но почему-то в коде это уже три десятилетия канон, равно как и традиция работать через get и set функции, а в базах данных по-прежнему через жопу.

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

А вот писать связи на коде, особенно если код распределён по нескольким серверам — ой, проблемно. Рано или поздно нарисуется коллизия. Скорее рано, но узнают поздно.

Sergey Lysak T/T Lead 02.02.2021 13:23

Их-то снесут первыми, чтобы не мешали

...случай знаю. недавно общался с приятелем в реале. джавистом.
он в компании имеющей свой внутренний продукт. Компания с США, система на Джаве, что-то там с домами, арендами. федерального уровня кажется.
Давно написана.
спросил для порядку о тестах. Не, смеется, нету. Были, и сейчас болтаются. но поломаны давно, и никто и не пытается их чинить.
А зачем? бизнес стабильно и неспеша растет. Фичи не спеша и аккуратно добавляем. как и баги — находим, и фиксаем.
— и тестировщики проверяют?, спрашиваю я
— не, отдел тестирования у нас есть, но он толком не знаю чем занимается. сами все и тестим. проджекты — американцы в основном.
все всех устраивает.

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

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

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

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 02.02.2021 18:23

свой внутренний продукт.

что-то там с домами, арендами

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

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

Sergey Lysak T/T Lead 02.02.2021 19:17

да, очень часто бывает.

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

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

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

CodeGuru 02.02.2021 13:28

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

1. Правильные тесты — пишутся не по коду, а по спецификации/требованиям. Соответственно, за снос таких тестов — больно бьют по рукам.

2. Какой критерий «правильности» кода? Его работоспособность. Что определяет работоспособность кода? То, что его кто-то протeстировал (автоматический тест, сам кодерок, мануальный тестер, клиент в ходе работы с программой).
Когда этот «правильный» код меняется — что будет показателем работоспособности этого изменённого кода?

Dmytro Lapshyn Chief Technology Officer в Telmie 02.02.2021 13:53

Ты им не объяснишь :(

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

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

Беда только в том, что этот подход плохо (если вообще) масштабируется.

CodeGuru

CodeGuru 02.02.2021 14:02

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

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

А иначе, тестерами выступят клиенты (и им такое не понравится).

И иного — не дано.

Олексій Пєніє Developer, Java в забугорье 02.02.2021 15:12

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

Пример: в базе есть неудаляемые данные. Хочешь написать тест, способный работать на боевой базе — либо пиши процедуру удаления, либо процедуру обхода безопасности. И то и другое могут заэксплотить.

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 02.02.2021 22:35

Хочешь написать тест, способный работать на боевой базе

Что есть «боевая» в данном контексте? Потому как присутствие в одном предложении слов «тест» и «боевая» несколько смущает

Олексій Пєніє Developer, Java в забугорье 04.02.2021 05:25

То есть тебе не давали писать проектов, в которых есть серии тестов, прогоняемые на боевом экземпляре? И представь себе, некоторые из них плодят сущности.

И если наплодить много ума не надо, то вот дропнуть... Бывают случаи (и это правильный подход) когда роль у логина приложения на базу просто не позволяет прямое вмешательство в некоторые таблицы. А вот на запуск процедуры роль есть.

Особо весело, когда эти тесты разрешено пускать извне... но это уже совсем другая история.

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 04.02.2021 16:52

То есть тебе не давали писать проектов, в которых есть серии тестов, прогоняемые на боевом экземпляре?

Ддя этого есть staging энв-ы. Иначе, пардон, это называется «слабоумие и отвага». И да, процесс управления тестовыми данными должен быть на нормальном проекте. Все вот эти вот тестовые датасеты, обфусцированная копия реальных данных и т.п.

Олексій Пєніє Developer, Java в забугорье 04.02.2021 19:41

Вот-вот, отсюда и пляшем, что из примитивной по сути задачи требуется уже ПРОЦЕСС, а это и денежка, и геморой, и требование кому-то сильно в теме отслеживать ИЗМЕНЕНИЯ в проекте и переносить их в процесс. Замечаешь слабое звено?

А задача-то простая: в реальном приложении что-то сломалось. Понять что, понять быстро, и починить. И практически 100% что на стейдже это всё отработало на ура.

А теперь, внимание, вопрос: а кто именно и как готовит стейдж, кто держит его актуальным? Часто это руками, но для процессов с серьёзной нагрузкой и вовлечением людей для этого нужны ПРОЦЕДУРЫ. Грубо говоря, пачка скриптов, которые раз в какое-то время будут вливать свежие данные в стэйдж. И которые будут проверять, чтобы соблюдались процедуры защиты данных (но это уже в код лучше перенести). А ещё, подготовить стэйдж нужно максимально быстро, если нужно срочно решить проблему — и желательно не убив существующий, на котором всё ещё работает.

То есть по сути всё равно требуется солидный объём работы. Или не требуется? Вот в чём вопрос. Можно ли поверх существующего процесса прокладывать тестовые пути? В случае АВРАЛА так и делают. Разумеется, с косяками. Так вот, чтобы этих косяков не было, и чтобы авралов избежать, и нужны встроенные тестовые процедуры как СИСТЕМА.

Хорошо, когда в боевую систему есть доступ. Или плохо, с позиции безопасности? А вот как быть, когда у тебя из доступа только разъярённый человек на другом конце трубки? Когда проблему прятали под ковёр неделю, дав накопиться ошибкам и пролиться в бэкапы? А ты понятия не имеешь, что там сломали. По описаниям же... «ой, выскочило окошко, там было что-то написано, но я его закрыло, красьненькое такое».

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 04.02.2021 20:57

Часто это руками, но для процессов с серьёзной нагрузкой и вовлечением людей для этого нужны ПРОЦЕДУРЫ

Совершенно верно.

В случае АВРАЛА так и делают. Разумеется, с косяками.

В результате — хрестоматийный пример — кто-то пытается максимально быстро что-то пофиксить, в нервной обстановке аврала, пишет UPDATE ... WHERE с опечаткой в условии. Или передает некорректный параметр в хранимку. И просто проблема превращается в большую проблему.

Олексій Пєніє Developer, Java в забугорье 04.02.2021 21:06

Вот этого и пытаются избежать. Не попыткой какими-то способами уверовать в безупречность людей в определённом звене, а избеганием авралов. Только этому и служат встроенные тесты на продакшене: вместо аврала добиться определённости в проблеме и спрогнозировать сроки решения, и кто вообще и как решать должен быть привлечён.

Поверь, гораздо легче звонить начальству, отвечающему за конкретное звено процесса, когда есть логи работы теста. И знать, что отвечать, когда попробует от**здеться.

Олексій Пєніє Developer, Java в забугорье 02.02.2021 15:07

Вот-вот. А теперь угадай, есть ли у программера, который ПОНИМАЕТ логику в деталях — права менять спецификацию, писанные мальчиками с большими ~~яйцами~~ должностями, согласованную между собой за кружкой виски. В то время как ни с пользователем системы, ни с её кодером, никто нихера не согласовывал — а зачем.

А хранимую процедуру поднять — полномочия есть. Хотя я встречал случаи, когда нет. Например, когда есть ТЗ на создание сущности, а полномочий на создание таблицы в базе — нет и не предвидится, это требует туевой хучи согласований и возможно только по инициативе начальника.

Так что бюрократия только в её параллельном мире есть добро. А в реальности это песец, которого надо обходить десятой дорогой.

CodeGuru

Sergey Lysak T/T Lead 02.02.2021 15:15

В то время как ни с пользователем системы, ни с её кодером, никто нихера не согласовывал — а зачем.

при том что все логические неувязки придется разруливать простому программисту, когда начинает:
if (

ёп, так это, получается два вида true и три false, если почитать все что прислали.
а надо чтобы был только один true и один false...
как же правильно то будет... кого спросить то, таску ж завтра максимум закрыть нужно...

CodeGuru 02.02.2021 15:17

А теперь угадай, есть ли у программера, который ПОНИМАЕТ логику в деталях — права менять спецификацию, писанные мальчиками с большими яйцами должностями, согласованную между собой за кружкой виски.

Нельзя и не нужно. Т.к. не кодерское это (как правило) дело — спецификации писать/самостоятельно изменять.

Впрочем, бывает такое, что кодер хорошо понимает, о чём в спецификации идёт речь — т.к. такое понимание полезно, для написания кода по ней. Это не означает, что такой кодер понимает все бизнес-триггеры, «подводные камни», реалии предметной области (то, что необходимо для написания/изменения спецификации) — но по крайней мере может найти в спецификации явные баги и о них сообщить.

Впрочем, к хранимым процедурам всё это не имеет никакого отношения. Само наличие хранимых процедур — это дефект кода.

Олексій Пєніє Developer, Java в забугорье 02.02.2021 15:21

Само наличие хранимых процедур — это дефект кода.

Всего лишь хранение кода вместе с данными. Там, где он будет понятен. А не там, где его необходимость не совсем очевидна, и придётся копипастить код в каждый случай применения, и с объяснением зачем оно так, и надеяться что никакой дебил это объяснение не выпилит.

CodeGuru

CodeGuru 02.02.2021 15:23

Там, где он будет понятен.

Там, где с ним невозможно ничего делать. Тестировать, отлаживать, изменять, вести контроль версий, повторно использовать ...

Олексій Пєніє Developer, Java в забугорье 02.02.2021 15:31

Там, где с ним невозможно ничего делать. Тестировать, отлаживать, изменять, вести контроль версий, повторно использовать ...

ВОТ ИМЕННО! Работает — и не трогай! Ровно до тех пор, пока не понадобится вскрывать модель данных, менять те самые спецификации. Там и будет прописано наличие процедур.

Кстати, ровно ничего не мешает покрыть их тестами из кода. Что чаще всего и делается. Но в составе функционала, где они используются. Ровно ничего не мешает написать процедуру теста — кстати, прекрасный пример зачем они таки нужны — чтобы прогонять некоторые тесты прямо во время работы кода, так сказать, следить за здоровьем. Очень помогает при косяках механизма кеширования.

CodeGuru

Sergey Lysak T/T Lead 02.02.2021 15:22

Т.к. не кодерское это (как правило) дело — спецификации писать/самостоятельно изменять.

золотые слова!

я так всегда и говорю, это и есть одно из качественых различий кодера и программиста
програмист — может написать спеку (ведущий, и т.п. может еще изменения внести=взять на себя ответственность, потому что обладает продакт-ориентированным майндсетом, и т.п.)
кодер — не может.

Само наличие хранимых процедур — это баг кода.

мнение кодеров конечно нужно учитывать.

и делать так как считают нужным — программисты на проекте.

CodeGuru

CodeGuru 02.02.2021 15:25

програмист — может написать спеку (ведущий, и т.п. может еще изменения внести=взять на себя ответственность)

Проработав всю жизнь на детсадовских проектах в своей провинциальной песочнице — ты понятия не имеешь о том, что представляют из себя проекты реального «взрослого» мира.

Отсюда и твои суждения, о разработке, тестировании, спецификациях...

Sergey Lysak T/T Lead 02.02.2021 15:27

это да, на доу мы детсадовцы в меньшинстве

как и в жизни :)

CodeGuru

CodeGuru 02.02.2021 15:38

это да, на доу мы детсадовцы в меньшинстве

Здесь в таблице «Difference between System Engineer and Software Engineer :» - примерно то, о чём я тебе пытаюсь сказать:
www.geeksforgeeks.org/...eer-and-software-engineer

В сложных системах — кодерки не в курсе всех деталей реализации системы (на разных уровнях) — но это от них и не требуется, т.к. на такое естъ сборище системных инженеров (для кадого уровня системы или разных подсистем одного уровня, свой).

Системные инженеры, как правило дерьмокодеры (или вообще не кодеры), т.к.коденьем они не занимаются — но они настолько хорошо владеют предметной областью, как кодер не овладеет ею никогда (т.к. у кодеров совсем иные задачи).

Да, если ты пишешъ программу, уровня сложности «показать 3 формы пхп» — ты сам и закодишь, и спецификацию составишь, и тесты тебе не нужны. Но есть немало куда более сложных и крупных задач.

П.С. Системные инженеры это из технических проектов. Примерно тем же занимаются бизнес-аналитики — в области софта для финансов/банков.

Sergey Lysak T/T Lead 02.02.2021 16:59

В сложных системах — кодерки не в курсе всех деталей реализации системы

да. естественно.
но поэтому мнение кодерков о технологиях — самое последнее

но это от них и не требуется,

да, естественно.
так и выстраивалась разработка.

Да, если ты пишешъ программу, уровня сложности «показать 3 формы пхп»

не знаю, не писал
но видел, да. обычно это вебремесленники с фриланс биржи

ты сам и закодишь, и спецификацию составишь

воооот тут уже интереснее, и писал уже в этой теме :)

собственно слово то у нас и другое есть
«гребцы на галерах»
правда там тоже есть и кодеры и программисты
кодер — не может составить спеку, да. ему никто никогда не поручал этого. а по его должностным обязанностям ему этого и не нужно.

Примерно тем же занимаются бизнес-аналитики — в области софта для финансов/банков.

есть роль — бизнес-аналитик
а есть вид деятельности — бизнес-анализ.
то же самое с архитектор и — проектирование архитектуры

и да, кодерки с бооольших проектов обычно не занимаются этими видами деятельности

и поэтому их мнение об этих видах деятельности — можно игнорировать. они — нубы в этом, даже в песочнице не пробовали.

Но есть немало куда более сложных и крупных задач.

конечно.
только если ты кодерок в таких задачах — то твое участие в них — приблизительно как работницы клинингового центра. ну да, офис фаанга не каждой уборщице доверят, согласен. мне б не доверили точно.

но уровень понимания этих видов деятельности — такой же.

тесты тебе не нужны

нам нужны, и у нас они есть.
планирую еще добавить.
но не для метрик покрытия кода.
в этом то и разница — с нас некому требовать покрытие как критерий надежности разработки.

с кодерка — требуют. ну, так всегда ж
it depends

CodeGuru

CodeGuru 02.02.2021 17:09

да. естественно.
но поэтому мнение кодерков о технологиях — самое последнее

Кодер решает в том, что касается кодирования. Скажем, когда мне «системный инженер» настоятельно рекомендует завязать с тестами, т.к. сроки горят — я его шлю нахер. Поскольку он отвечает за дизайн системы, а я отвечаю за работоспособность кода.

В итоге оказывается, что паралельные команды, где кодят без тестов — потом зависают и отстают на многие месяцы. Т.к. по мере роста сложности, при внесении изменений — у них отваливается куча функциональности и это они чинят следующине недели.
А у нас всё работает и «зелёное»...

Sergey Lysak T/T Lead 02.02.2021 17:54

Кодер решает в том, что касается кодирования.

да и то, правила для линтера, код стайл обычно не он пишет :)

В итоге оказывается, что паралельные команды, где кодят без тестов — потом зависают и отстают на многие месяцы.

бывает и так. от дизайна системы зависит, компетенций, самих задач.

да и хотя бы приемочных тестов чуть добавить, уже хорошо.
если есть апи — то хоть наколеночных и только на чтение — пусть себе подергивают, уже отловят немало

Т.к. по мере роста сложности, при внесении изменений — у них отваливается куча функциональности и это они чинят следующине недели.

и так бывает.
it depends

«системный инженер» настоятельно рекомендует завязать с тестами, т.к. сроки горят — я его шлю нахер.

может и правильно. может и нет.
откуда мне знать, что там у вас и как.
мне с этой стороны монитора ничего не видать

вам вот с другой стороны монитора видать о моем текущем проекте куда больше! даже того что я не вижу :D

А у нас всё работает и «зелёное»...

да, верю, у вас багов на проде не бывает.
потому что юнит-тесты проходят

CodeGuru

Dmytro Lapshyn Chief Technology Officer в Telmie 02.02.2021 13:50

Их-то снесут первыми, чтобы не мешали. Точно так же на рефакторинге посчитают кусок тестов устаревшим вместо того чтобы разбираться в нюансах алгоритма

Ну, то есть, мы говорим о подходах к разработке в каком-то гараже, в котором о code review и pull request’ах никогда не слышали? Если так, то я на этом моменте откланяюсь, поскольку обсуждать такое неинтересно.

Есть часть сущностей, свойственных именно организации данных, модели, а совсем не коду. И вот их-то и нужно прятать в хранимые процедуры.

«Ой, всё!» ©
Авторы domain-driven design нервно курят в сторонке, слушая речи непризнанного гения.

Олексій Пєніє Developer, Java в забугорье 02.02.2021 15:25

Авторы бюрократии могут что угодно курить в сторонке, но человеческий фактор никто не отменял. Попытка обойти его усилением бюрократизма приводит к ещё меньшему пониманию, что происходит на самом деле. А далее — к непониманию что люди вообще должны это понимать, и нанимаются исполнители, работающие «без возражений».

Мне ли тебе рассказывать о том, кто такие реальные люди, и чего они могут творить под давлением сверху?

Dmytro Lapshyn Chief Technology Officer в Telmie 02.02.2021 15:44

Слушай, ну скажи, пожалуйста, где ты увидел в моих словах хоть намёк на бюрократию? Или ты называешь оной code review и pull request’ы? Я без всякого троллинга сейчас, хочу просто «карты мира» согласовать.

DDD — тоже ни разу не бюрократия, это же вообще не про процессы.

нанимаются исполнители, работающие «без возражений».
Мне ли тебе рассказывать о том, кто такие реальные люди, и чего они могут творить под давлением сверху

Обычно, всё же, между такими исполнителями и теми, кто давит сверху, есть ПМ / тим лид / архитектор. А на такие роли (особенно, две последние) обычно не нанимают исполнителей, работающих «без возражений», разве нет?

Ну, или мне повезло работать в компаниях, где на такие роли не нанимают yes-man’ов.

Олексій Пєніє Developer, Java в забугорье 02.02.2021 15:47

Не в компаниях, а в проектах. И либо действительно повезло (и вероятность этого не самая малая), либо не твоя обязанность разгребать последствия.

Dmytro Lapshyn Chief Technology Officer в Telmie 03.02.2021 16:22

не твоя обязанность разгребать последствия.

Вот последствия, как раз, разгребал, и не раз. Но это были последствия отсутствия или некомпетентности архитектора, а не его прогибания под начальство / клиента.

Denys Poltorak Embedded | C++ 03.02.2021 22:30

мне повезло работать в компаниях, где на такие роли не нанимают yes-man’ов.

Sergiy Morenets Java evangelist 27.01.2021 23:57

Коли читаєш коментарі в таких темах на ДОУ, то на жаль, розумієш, що єдине чого з бажанням вчаться наші програмісти — це ненавидіти інших програмістів.

Alex Fogol Software Developer, C/C++ Expert 28.01.2021 02:22

тут можу сказати цей скіл це цілком такий собі інтернаціонал )) і більш того я їх тут цілком розумію

John Appleseed 28.01.2021 17:50

Скорее обесценивать труды других программистов.

Sergii Marushchenko .NET 28.01.2021 23:07

Я, чесно кажучи, саме через це тільки віднедавна «видихнув» і став писати більш-менш розслаблено, а до того з самого 2008 (коли я тут зарегався) чекав якихось ударів з-за рогу. Ну і раз чи два то навіть притягнуло анонімного «доброзичливця»...

John Appleseed

Olexandr 01.02.2021 19:30

Так будь-який код можна обісрати. Тролям лише дай можливість.

Sergii Marushchenko

Sergii Marushchenko .NET 01.02.2021 21:13

Та б’ють по якихось слабких місцях у кар’єрі, для цього достатньо щось десь про це чути.

Olexandr

Olexandr 01.02.2021 21:55

Насправді у мене увесь псих. розлад на цій темі. Що те що я роблю обісруть, що мене обісруть. В результаті я кожу під напругою, хоча ніхто не контролює. Вчуся під напругою. І будь-що компетитів роблю так, наче дивлять злі очі. Дійшло до того, що я і відпочити не можу «наодинці». І це сильно виснажує, і провокує хвороби тіла.

Я знаю що це так, бо бувало, коли розслаблявся — якось в голові перемикався тригер на пофігізм. І в таку мить приливало купа фану, продуктивності, і бажання.

Тому я розумію про що ти.

Sergii Marushchenko

Sergii Marushchenko .NET 01.02.2021 23:01

Розумію, але я саме про ДОУ. З кодом у мене все добре.

Olexandr

Olexandr 01.02.2021 23:06

Дел

Sergii Marushchenko

Личинка мамы программиста 27.01.2021 19:21

Какой то бред в таблице... Узнаю галерный подход.

Лично я спрашиваю по технологиям в разброс от вопросов «отсеять дебилов» (что такое в С++ виртуальный деструктор? А виртуальный конструктор?) до вопросов посложнее (нюансы использования динамической памяти в жёстком реал тайме), а в завершение идут open ended questions с продакшена — на поболтать и посмотреть куда мыслит человек и насколько далеко он может зайти в своих размышлениях.

Oleksandr Golovatyi -`★´- в ☁︎ 28.01.2021 21:12

что такое в С++ виртуальный деструктор? А виртуальный конструктор?

Контора С++ компілятор пише?

CodeGuru 28.01.2021 21:18

Контора С++ компілятор пише?

В «плюсах» виртуальных конструкторов не существует. И вызов виртуальных функций из конструкторов — это очень плохая вещь.
И неспроста.

Oleksandr Golovatyi -`★´- в ☁︎ 28.01.2021 21:35

І що? Ну от дізналися чи знає людина про це чи їй доведеться колись 20 секунд витрати щоб дізнатися. А як визначити чи підходить вона компанії/проекту?

CodeGuru

CodeGuru 28.01.2021 21:41

Ну от дізналися чи знає людина про це чи їй доведеться колись 20 секунд витрати щоб дізнатися.

Это азы «плюсов». Уровень даже не миддла, а начитанного джуна.

К тому же, если неподготовленный «синьор» поставит «virtual» перед конструктором — компилятор его поправит. А вот насчёт вызова виртуальной функции из конструктора — не уверен (максимум, будет предупреждение, а многие и просто проглотят).
А потом начнутся всякие неприятные и сложно-находимые вещи...

Впрочем, я больше склонен оценивать спецов по бэкграунду/рекомендациям. А если речь о джунах, то достаточно общения/испытательного срока.

Oleksandr Golovatyi -`★´- в ☁︎ 28.01.2021 21:44

Это азы «плюсов». Уровень даже не миддла, а начитанного джуна.

Я з цим не сперечаюся. Моє питання — як знання цього факту який можна дізнатися за кілька секунд показує відповідність кандидата проекту чи компанії в цілому?

CodeGuru

flyman 28.01.2021 23:16

за кілька секунд

взнати чи чувак знає базвордс чи зовсім нуб

Oleksandr Golovatyi -`★´- в ☁︎ 29.01.2021 01:57

Ну то правильний сеньйор має сказати «не знаю є вони там чи нема, але якщо проблема саме в цьому то можу їх вам тут на дошці і реалізувати зараз». Щось типу такого?

uk.wikibooks.org/...ртуальний_конструктор_С+

flyman

flyman 30.01.2021 08:40

завдяки цій темі тепер зможу пройти левел

«отсеять дебилов» (что такое в С++ виртуальный деструктор? А виртуальный конструктор?)

а раніше би провалив інтерв"ю на сінйора :)

Alex Fogol Software Developer, C/C++ Expert 30.01.2021 23:32

а раніше би провалив інтерв«ю на сінйора :)

тю та изи )) на что подопытный получает встречный вопрос за фабричный метод против абстрактной фабрики с предложением по рассуждать кого куда совать и своими честными миддл $2500 «по результатам интервью» )) ничего личного просто бизнес

ЗЫ: на самом деле вопросов за виртуальный декструктор и вообще виртуальные функции более чем достаточно для понимания есть ли понимание или же ж есть просто заученное по методичке а реальной практики разбирательства 0.0

flyman

flyman 30.01.2021 23:35

фабричный метод против абстрактной фабрики

вилкой в глаз или в жопу раз

anonymous 31.01.2021 09:26

-

CodeGuru 29.01.2021 02:07

Моє питання — як знання цього факту який можна дізнатися за кілька секунд показує відповідність кандидата проекту чи компанії в цілому?

Если чел описывает себя синьором, но не в курсе основ «плюсового» полиморфизма (а это основа «плюсов» — собственно то, что отличает «плюсы» от «си») — что-то тут не так.

Oleksandr Golovatyi -`★´- в ☁︎ 29.01.2021 02:16

Між сеньйором який ніколи не писав на плюсах чи писав дуже давно, і сеньйором який вміє лише в одну технологію (навіть якщо це С++) я виберу не того хто знає на пам’ять про віртуальні деструктори, а того хто вміє розв’язувати задачі і тягти проекти і фічі до завершення. Хіба не логічно?

Для мене ці питання про якісь нюанси наче ми на іспиті на 3-му курсі виглядають дивно — людина потрібна як довідник з С++, чи може щоб робити щось осмислене все ж таки?

CodeGuru

Yuriy Pavlenko Embedded Software Developer 29.01.2021 10:46

Как по мне тут тонкий лед. С одной стороны вопросы типа «порядок, тип и количество аргументов, передаваемый в условный strcpy?» попахивают идиотизмом. С другой стороны — незнание о существовании виртуальных деструкторов может привести к тому, что софт потечет памятью. Потому что при таких раскладах можно договориться до «человеку не обязательно знать, что нужно удалять память после выделения в системах без garbage collector.» Ну или «человеку не обязательно инициализировать переменные»

flyman 30.01.2021 08:47

софт потечет памятью.

дик для цього є Го, або Руст

Yuriy Pavlenko Embedded Software Developer 30.01.2021 23:39

Дешевле будет нанять кого-то, кто знает за виртуальные деструкторы и продолжит тянуть проект, чем переписать проект на Го или Руст с нуля.

flyman

flyman 30.01.2021 23:42

хіба хто проти... це ж можна доїти клієнта роками ...

Yuriy Pavlenko Embedded Software Developer 31.01.2021 00:08

Угу, в аутсорце. Пойди в продукте расскажи что «а теперь вам нужно переписать весь продукт на Го, который сейчас денег генерит». Вместо того, чтобы этот продукт дальше развивать.

flyman

CodeGuru 31.01.2021 00:15

це ж можна доїти клієнта роками ...

Доить клиента годами, сопровождая продукт, приносящий клиенту баблос — куда лучше, чем начать писать продукт на расте и похоронить, так и не закончив.

flyman

flyman 30.01.2021 08:43

что отличает «плюсы» от «си»

гетери — сетери, нєа?

CodeGuru

Alex Fogol Software Developer, C/C++ Expert 30.01.2021 23:35

нет конечно )) на плюсах есть stl а на си stl нету и без stl плюсы ничто а точнее «плюсовики» просто потому как грубо большая часть 80%+ современных «плюсовиков» это на самом деле «джава стиль на stl»

flyman

flyman 30.01.2021 23:36

не в самих плюсах, а в стандарті,
ще буст є, який тепер в стл, тобто в стандарті
а ще темплейти, і метапрограмування...
та мало що там є... ромбічне наслідування ... втаблєс...екзепшени ... РТТІ ... і т.д....але найбільше там UB...

то був натяк одного із трьох китів (приховування даних, яке насправді не є приховуванням) ООП ООД, яких тіпа нема в С

Denys Poltorak Embedded | C++ 30.01.2021 23:47

Ну ще скажи що Пітон не Пітон бо усе публічне

flyman

Yuriy Pavlenko Embedded Software Developer 31.01.2021 00:03

self.__priv = «Hello»
А вот protected как в плюсах там реально не хватает

CodeGuru 31.01.2021 00:06

self.__priv = «Hello»

Это фиктивная приватность, т.к. такие функции/поля можно пользовать извне — было бы желание.

Yuriy Pavlenko Embedded Software Developer 31.01.2021 15:20

При желании можно и в плюсах до приватных членов класса дотянуться. Вопрос лишь в том, почему у разработчика возникают такие нездоровые желания.

CodeGuru

CodeGuru 30.01.2021 23:48

натяк одного із трьох китів

Главный кит — это полиморфизм, как средство объектно-ориентированности/абстрагирования. Всё остальное (включая "гетeры"/"сетeры«) достаточно легко реализуется средствами «си» (или этому есть «сишные» аналоги) — и незачем лезть в «плюсы».

Впрочем, полиморфизм тоже реализуется на «си» — но сложно. И в принципе, только лишь если он нужен — есть резон пользовать «плюсы». В прочих случаях, от пользования «плюсов» вместо «си» — лишь минусы на многих уровнях.

flyman

Denys Poltorak Embedded | C++ 30.01.2021 23:55

Ну, если честно, то вот со строками в С очень сложно работать. И со списками. С++ дает возможность писать свои типы, поэтому даже ради голой энкапсуляции стоит его затянуть, если проект больше 10к строк.

CodeGuru

CodeGuru 31.01.2021 00:02

Ну, если честно, то вот со строками в С очень сложно работать. И со списками.

Есть полно сишных контейнеров. Кода при использовании получается несколько больше, чем при аналогичных, скажем, СТЛьных — зато гораздо прозрачнее.

Олексій Пєніє Developer, Java в забугорье 02.02.2021 13:31

В С и со сборкой мусора сложно работать. Да, да, руками пишем деструкторы, даст ист фанстастиш

Olexandr 02.02.2021 13:36

Чисто не там де прибирають, а там де не смітять!

Denys Poltorak Embedded | C++ 02.02.2021 19:31

В С нет деструкторов и сборки мусора. Деструкторы только к С++ завезли, и это была киллер-фича — остальное спокойно делалось (и делается до сих пор) ручками в С.

Alex Fogol Software Developer, C/C++ Expert 31.01.2021 00:23

Впрочем, полиморфизм тоже реализуется на «си» — но сложно.

не не сложно просто берёшь таблицу «методов» и всё

почти весь линукс так и построен а скажем «файловый дескриптор» или handle в win32 api суть есть всё та же ж «абстракция системного полиморфизма на прикладном уровне»

CodeGuru

CodeGuru 31.01.2021 00:36

не не сложно просто берёшь таблицу «методов» и всё

Это я называю «сложно».

Структура с указателями на функции (класс) — это ещё куда ни шло.

Но завязываться на реализацию таблиц виртуальных функций — это уже будет код, непригодный для последующего сопровождения средними (понятно, «сишного» уровня среднести — который высок) спецами.

Denys Poltorak Embedded | C++ 31.01.2021 00:39

По-моему, это очевидный подход, на уровне «виртального деструктора» для С++ джунов.

CodeGuru

Valentin Nechayev досвідчений чайник Рассела в Дарницькі печери 06.02.2021 10:53

Но завязываться на реализацию таблиц виртуальных функций — это уже будет код, непригодный для последующего сопровождения средними (понятно, «сишного» уровня среднести — который высок) спецами.

А чем тут foo->functions->put(foo, x, y) хуже, чем foo->put(foo, x, y)? Или вы о чём-то другом?

CodeGuru

Oleksandr Golovatyi -`★´- в ☁︎ 06.02.2021 22:15

Наприклад ці таблиці можна динамічно модифікувати і тоді простим читанням коду буде дуже складно відстежити які самі методи викликають.

Valentin Nechayev

Alex Fogol Software Developer, C/C++ Expert 07.02.2021 09:09

і тоді простим читанням коду буде дуже складно відстежити які самі методи викликають.

ну да але те саме працює і для будь якого «класичного ооп поліморфізму»

Личинка мамы программиста 29.01.2021 01:29

І що? Ну от дізналися чи знає людина про це чи їй доведеться колись 20 секунд витрати щоб дізнатися.

Отсеять дурачков которые вписали себе в тайтл — Senior, а по факту сыпятся на глупейших вопросах

А як визначити чи підходить вона компанії/проекту?

А это я узнаю на сессиях с open-ended questions, которых у меня с продакшена за пару лет накопилось вагон и маленькая тележка. Было ж написано:

до вопросов посложнее (нюансы использования динамической памяти в жёстком реал тайме), а в завершение идут open ended questions с продакшена — на поболтать и посмотреть куда мыслит человек и насколько далеко он может зайти в своих размышлениях.

Стек опрашивал я. Но не дотошно — нет смысла. Доучить недостающее уже на месте можно.

Oleksandr Golovatyi -`★´- в ☁︎ 29.01.2021 01:56

Отсеять дурачков которые вписали себе в тайтл — Senior, а по факту сыпятся на глупейших вопросах

А якщо цей сеньйор писав в останнє на С++ 15 років тому і може перевернути список за пару хвилин?

А это я узнаю на сессиях с open-ended questions, которых у меня с продакшена за пару лет накопилось вагон и маленькая тележка

Тоді чому одразу не почати з цих питань?

Bot Bot 29.01.2021 09:43

і може перевернути список за пару хвилин

Потому что большинство таких сеньоров не умеют этого делать, потому заепуют теорией и базвордами.

Это как дедовщина, так и здесь, ток дедов в армии замени на преподов в универах, которые задрачивали на экзаменах потому что жизнь не удалась ну или их в также задрачивали.

У меня лучшие преподы, которых интересно было слушать, всегда разрешали пользоваться литературой на экзамене и вопросы там былы как раз решить инженерную задачку, литературу давали спецом и говорили что инжинер должен уметь работать с информацией.

Те же кто сам был туговат и читал лекции с методички — задрачивали теорией.

ЗЫ у меня специальность вообще не прогерская.

Yuriy Pavlenko Embedded Software Developer 29.01.2021 10:51

У меня лучшие преподы, которых интересно было слушать, всегда разрешали пользоваться литературой на экзамене

О, у нас физик такой был, которому весь поток в конце каждого семестра вставал и аплодировал (в буквальном смысле, из года в год).
На экзамене был лимит кажись на 5-10 минут на использование литературы. Типа если знаешь где искать, то найдешь и воспользуешься. А если весь семестр клал на учебу — то и не будешь знать куда смотреть.

Bot Bot

anonymous 29.01.2021 09:20

-

CodeGuru

Roman Pavlyuk myself в ELEKS 29.01.2021 22:37

Віртуальні конструктори були на Дельфі

anonymous

Олексій Пєніє Developer, Java в забугорье 02.02.2021 15:45

В «плюсах» виртуальных конструкторов не существует.

И что таки помешает их создать? Конструктор всего лишь функция, возвращающая объект. А уж чего она вернёт на самом деле, может быть выяснено по ходу дела.

Другой вопрос, что в отличие от более зрелых языков, в плюсах таки можно умудриться соорудить мертворождённый виртуальный объект, в котором банально таблица распределения смотрит за пределы выделенной им памяти. По крайней мере раньше можно было, много лет назад, сейчас подозреваю это дерьмо выжгли.

По-хорошему, эволюционно могли разрешить и создание виртуальных объектов, и виртуальные конструкторы, просто эволюция пошла другим путём, и вряд ли кому-то сильно нужно возвращаться к истокам, учитывая какое стадо собачек нужно сожрать чтобы подобное запилить в реальность.

Впрочем, когда-то то же самое говорили про замыкания. А вот поди ж ты.

CodeGuru

Left Outer Join 28.01.2021 21:18

Это вопросы уровня детского сада

Oleksandr Golovatyi -`★´- в ☁︎ 28.01.2021 21:34

В чому сенс їх задавати? Можна ще про кольори веселки спитати.

flyman 30.01.2021 08:51

про кольори веселки спитати

цветовая дифференциация штанов

Bot Bot 28.01.2021 22:45

Виртуальный причем :-)

Личинка мамы программиста 29.01.2021 01:28

Контора С++ компілятор пише?

Несложный продукт — графика-визуализация на проекторы/мультитач дисплеи.

Oleksandr Golovatyi -`★´- в ☁︎ 29.01.2021 01:59

От і дивно — в такій області має бути повно невеликих задочок на спрощених версіях яких можна оцінити чи підходить людина. Для чого питати про триграфи та інше, що не стосується безпосередніх задач?

Проте я підхід і точку зору зрозумів, не бачу сенсу продовжувати суперечку.

Личинка мамы программиста 29.01.2021 12:52

От і дивно — в такій області має бути повно невеликих задочок на спрощених версіях яких можна оцінити чи підходить людина.

Эти вопросы я тоже задавал, так как проект с рендерингом связан, вот одна из задач — «нам надо отрендерить белую комнату в которую светит солнечный свет через окно и попадает на стол с посудой, как сделать такое что б было красиво и презентабельно? фпс-ом пренебрегаем»

Вопрос был больше о понимании алгоритмов рендеринга. Встречный вопрос (который мне понравился) — «а что означает в этой формулировке <красиво>?» (на то это и был open ended question). Я ввел уточнение — «что б не было пересветов на белых шторах и участках где светит солнце (например видна фактура белой стены), а в темных углах под столом не было шума и пиксели не ушли в ноль по всем каналам». В ответ я услышал разные интересные вещи от HDR до разных форматов float-текстур 16 и 32 битной точности, а так же логарифмических преобразований по яркости (что б правильно свести широченный HDR диапазон с солнечным светом в LDR 0...255 и не потерять данные ни в тенях в углах, ни на ярких подсвеченных прямым светом участках). И данный ответ только один из возможных, можно упомянуть трассировщики лучей, можно рассказать про фотон маппинг, а можно и про лайтмапы статические.

Такие задачи подходят? :)

Возможно в твою компанию надо другого характера вопросы задавать. Все зависит от масштабов и типов задач. У нас маленькая компания, и людей мало работает, и цена ошибки низка и вообще багофиксом можно заниматься по 2 месяца сдвигая релизы. Был бы я в компании уже человек на 50 — скорее всего надо по другому опрашивать кандидатов. Не зря по собеседованиям целые книги написаны.

flyman 30.01.2021 08:52

ясно геймдев, проходим мимо

Личинка мамы программиста 30.01.2021 15:57

ясно геймдев, проходим мимо

вообще не угадал

а вот в рендер за 16мс ты похоже не умеешь

flyman

flyman 30.01.2021 16:03

і шо?
оно то мнє зачєм?

Личинка мамы программиста 30.01.2021 16:04

А вот это правильный ответ =)

flyman

Andrey Balyn 01.02.2021 16:06

Греби, не отвлекайся))))

Igor Mazur Инженер надежности веб-сайтов 27.01.2021 10:26

Шото поизмельчали «синьёры-помидоры»
sharpc.livejournal.com/67583.html

flyman 28.01.2021 13:23

інфляція долара

Igor Mazur

Left Outer Join 28.01.2021 21:10

По ссылке «Теоретический минимум программиста»?

Igor Mazur

Igor Mazur Инженер надежности веб-сайтов 28.01.2021 21:13

Он самый

Igor Mazur Инженер надежности веб-сайтов 28.01.2021 21:41

Ну и это ж само собой «минимум» — то есть на джуна гдето.......

Taras Soroka Web developer в self-employed 28.01.2021 22:15

с такой теорией на практику времени уже не останется

Igor Mazur

Олег Дорожко 26.01.2021 10:59

Ты не сеньор, если, например, не умеешь в GoF, а потому и денег (столько сколько ты требуешь) тебе не дадим. На совершенно законных основаниях. Чтоб сеньорить надо ооооочень много знать. Так что сойдемся на мидлознаниях и мидловознаграждениях. Как, ты даже мидло не шаришь? Что значит, я в табличку дописал незаметно? Что значит, раньше это не требовалось? Не, ну если не знаешь, то какой же ты мидл? Вот тебе прибавка джуна к зарплате джуна и все..

Olexandr 26.01.2021 16:04

Скільки можна про зарплати. Давайте про духовне.

Олег Дорожко 26.01.2021 16:32

Як це ск1льки? Я хочу синтезировать из свинца золото, а у меня нет денег на оборудование... Куда это годится??

Olexandr

anonymous 26.01.2021 10:51

-

Yegor Chumakov Президент в Гільдія IT-Фахівців 25.01.2021 22:09

Когда я слышу, что синьор должен в первую очередь думать о бизнесе, у меня возникает испанский стыд. Действительно, зачем нужны специально обученные и опытные директора, вице-президенты, бизнес аналитики, продукты, архитекторы в конце концов, когда есть синьор. Ваши фантазии послушать, так желательно еще быть фулл стеком, безупречно тестировать, придумывать дизайн, работать с инфраструктурой, а по вечерам тренировать модельки.

Olexandr 25.01.2021 22:10

по вечерам тренировать модельки.

З великими boobs.

Yegor Chumakov

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 25.01.2021 22:32

Когда я слышу, что синьор должен в первую очередь думать о бизнесе

Не стоит заниматься подменой понятий, да еще и настолько неуклюжей. Речь в основном шла о том, что синьор должен ясно представлять бизнес-контекст конкетной задачи с точки зрения реализации и NFR, а не заменять отдел маркетинга и сейлзов у заказчика на полставки.

безупречно тестировать,

У меня в команде синьоры всегда ревьювили интеграционные тесты. Не с точки зрения деталей имплементации, а чтобы удостовериться что неочевидные сценарии не упущены.

архитекторы в конце концов

Видел массу примеров когда хорошие, годные синьоры вполне себе удачно совмещали роли архитекторов. Обратные примеры тоже видел, но гораздо реже.

Yegor Chumakov

Sergey Lysak T/T Lead 25.01.2021 23:51

В недавнем обсуждении продакт ориентированности, вовлеченности было такое же возражение.
и вызвано оно похоже тем что эти вещи воспринимаются как требование каких то чувств :) такая вот хохма.

Что аж вспомнилось:
Делись со мною тем, что знаешь,
И благодарен буду я.
Но ты мне душу предлагаешь —
На кой мне чёрт душа твоя!..
(Шиллер, пер. Лермонтова)

Вовлеченность это не чуйства а лояльность — это не продажа души :)

Yegor Chumakov

Igor Lytvynenko Java Developer 25.01.2021 18:37

Критикувати цю таблицю можна, адже вона виписана через призму досвіду однієї людини. З однієї сторони там є дуже специфічні речі, от як cdn (поки раз-другий не зробиш — знати не будеш... там ой як все не просто), з іншої сторони, можна знайти речі, які тут не згадані (якщо мова про веб, то нехай web socket чи webgl).

Але в цілому, має право на життя.

Мене дивує реакція багатьох коментарів. Адже битий розробник, як мінімум з 80% цього всього мав би бачити на своєму шляху .... і не тільки цього а й ще стільки ж.

Шановні «senior»-и, вважайте цей перелік нижньою планкою. Якщо ви щось вважаєте тут непотрібним знати, можете помігяти на щось рівноцінне (наприклад, той самий cdn на webgl).

Sergiy Morenets Java evangelist 27.01.2021 23:52

На жаль, 90% коментаторів заходять в цю тему, щоб вилити лайно на автора

anonymous 28.01.2021 22:03

-

Igor Lytvynenko Java Developer 29.01.2021 11:38

З усього, що я прочитав тут, як на мене, ми маєм не достатньо інформації для такого висновку.

З іншої сторони ... чим відрізняється досвід зрілого розробника 1 рік технології Х від 5 років? Як на мене, той що 5 років працює буде знати ну від сили на 15-20% більше і то далеко не факт.

Винятки з попереднього є (в основному науковомісткі, чи мож hardware близькі), але точно не у вебі.

То ж стратегія «ходити по верхах» — це дуже навіть виправдано, з розумним підходом і якщо «верхи» є достатніми для того, щоб, наприклад вміти самостійно підняти новий проект на відповідній технології.

anonymous

anonymous 29.01.2021 14:47

-

Igor Lytvynenko Java Developer 29.01.2021 15:12

Ми стараємось на старті кожного нового проекту робити якесь review технологій/підходів. Саме на таких рейках ми впроваджували dagger (server side), java modules, prometheus, gitlab ci, kotlin (server side), http api на корутинах, так ми перейшли на з java android на flutter, тощо.

Якісь речі/підходи портуються на старих проектах, якісь плануються портувати, якісь ні, якісь проекти «працюють і добре». По технологіях треба ходити ... проекти треба портувати/переписувати ... інакше, дуже швидко стек безапеляційно застаріває і потім і проект підтримувати стає дуже важко (як от в нас є одне java 8 32bit (що вже пару років як треба в deprecated), яке важко кудись зсунути), так і навички залишаються там же.

А працювати коли

Навчатись через роботу, працювати через навчання, навчатись після роботи, жити в проміжках між усім цим). «Вічний студент» — це наше прокляття ))

Звісно, бувають задачі, коли треба взяти і по прокладених рейках зробити шмат роботи. Але практично завжди, мінімум 20% роботи (наприклад, в місячному терміні), можна спланувати так, щоб це було з виходом за межі звичного стеку.

anonymous

anonymous 29.01.2021 16:51

-

Igor Lytvynenko Java Developer 29.01.2021 17:24

тягнути github ci, якому рік від народженя

В нас був CI на Bamboo до того.
Після нього CI на gitlab — це був ковток свободи і свіжого повітря. Виправдав себе практично через місяць. Тільки що варте білди в контрольованих середовищах в docker контейнерах. Зараз у нас всі білди в контейнерах, крім ios. І коли ми налаштовували на ios runner, я згадав, що то за пекло, коли тобі потрібно обслуговувати runner (то версію чогось міняй, то на диску щось видали, то система якесь оновлення просить).

Щодо нового інструменту ... на self hosted gitlab ми перейшли на початку 2016го, на gitlab ci десь через 11 місяців. ± десь і тоді починали впроваджувати контейнеризацію по серверах. Я вам скажу, в цих всіх «нових» технологіях ми не зіштовхувалися з «непереборними багами». Були відсутність якихось фіч, які б дуже хотілося, але то таке.

скрипти в бранчах

Це одна з основних переваг — проект розвивається скрипти міняються. Завжди можна зробити будь-який білд будь-якої версії і все буде коректно.

VSTS була якась

Я вийшов з microsoft-ського стеку десь в той час, коли тільки цей інструмент випускав свої перші версії. Тому предметно порівняти не зможу.

І скільки людьских місяців праці витратилии на написання екшнів і розмноженя воркфловів по репам ?

Не зовсім зрозумів питання, якщо чесно. Звісно на те, щоб .gitlab-ci.yml + обв’язку до нього зробити знадобився час. Але на той момент нам багато і не треба було. Я б не став міряти місяцями. Та й еволюціонували білд скрипти з проектом. А той час, що ми потратили, був з запасом зекономлений на білдах-тестах-деплоях.

anonymous

Igor Lytvynenko Java Developer 29.01.2021 17:37

якому рік від народженя

Найбільш ризикованим для нас був не gitlab. Ризикованим був flutter, якому як раз і був рік від першої версії. Тоді і мова нова, архітектура UI ні на що не схожа, купа ліб під одну задачу і майже всі в беті та з github-а з малими community.

Це був дійсно ризик ... але пройшло вже понад рік, і я вам скажу, що кращої платформи для розробки UI я ще не бачив на своєму скромному шляху (якщо порівнювати з Delphi, MFC, Windows Forms, WPF, JavaFx, HTML+CSS+JS, Android, Swift).

anonymous

flyman 30.01.2021 08:53

чим відрізняється досвід зрілого розробника 1 рік технології Х від 5 років? Як на мене, той що 5 років працює буде знати ну від сили на 15-20% більше і то далеко не факт.

другий має більше набитих шишок і обійшов більше граблів

Igor Lytvynenko Java Developer 30.01.2021 09:23

Це абсолютно вірно ... але суть в тому, що ці шишки та граблі дуже швидко забуваються і через рік-два «десь я таке робив ... треба глянути отой репозиторій», а через 5 ... ну ... 10 років тому я писав на C# ... я зараз, звісно, можу писати на C#, можу поправити щось в старих проектах ... але, щоб по нормальному там щось робити, треба розбиратися заново. Ну і про граблі та шишки я там слабо вже щось пам’ятаю.

Тобто, кінець-кінцем, мілкі граблі «новачком» гугляться на stack overflow за хвилину, а більш важливі тренують в людини відчуття того що є добро чи зло в сфері. З часом це все сильно обезцінюється. Тому я і дав людині з більшим досвідом 15-20% «чогось» більше, хоча на відрізку 2-5 років це може бути і 5-10% а то і менше... По суті, немає чого вчити майже в будь-якій сучасній технології більше року. Решта часу — то збільшення кута зору, просвітлення, війна добра зі злом, прекрасного з огидним, тощо.

flyman

flyman 30.01.2021 09:32

суть в тому, що ці шишки та граблі дуже швидко забуваються і через рік-два «десь я таке робив ... треба глянути отой репозиторій»,

це не про то, мова іде більше про підходи щодо вирішення проблем/задач, а не про код.

мілкі граблі «новачком» гугляться на stack overflow

граблі гугляться досвідом чи читанням літератури, а на стековерфло гуглиться «реверс строки»

часом це все сильно обезцінюється. Тому я і дав людині з більшим досвідом 15-20% «чогось» більше, хоча на відрізку 2-5 років це може бути і 5-10% а то і менше... По суті, немає чого вчити майже в будь-якій сучасній технології більше року.

є «фундаменталс» і досвід, який не незнецінюється, на відміну від знання «модних фрейморків».

Igor Lytvynenko Java Developer 30.01.2021 11:31

є «фундаменталс» і досвід, який не незнецінюється, на відміну від знання «модних фрейморків».

Хех ... це вірно, і це та думка, яку я часто намагаюсь донести. Але на фундаментальних знаннях в нас хайп не ловлять, нажаль.

Якщо повернутися по моєї початкової тези, то я говорив про досвід зрілого розробника в якійсь технології.Тобто, вже маючи якийсь фундамент в, наприклад java, можна мати рік досвіду в C#. І теза полягала в тому, що, наприклад, 5 java+1 C# не сильно відрізняється (в знаннях C#) від 5 java + 5 С#.

Ну і, fundamentals та досвід ... то як м’яз .... накачати важко, підтримувати легше але вимагає постійної роботи, а якщо нічого не робити, втратити тонус дуже легко.

flyman

flyman 30.01.2021 12:19

якщо ти сам матрицю транспонував в універі, а не списував у сусіда, то як це робиться ти і на пенсії знатимеш,

а якщо тебе цікавили відмінності UB конструкторів в різних версіях С++, то це не фундаменталс, а саме

вимагає постійної роботи, а якщо нічого не робити, втратити тонус дуже легко.

хоча б тому що стандарти С++ швидко змінюються

Igor Lytvynenko Java Developer 30.01.2021 12:32

матрицю транспонував в універі,

Це не зовсім так ... наприклад, жорданову форму матриці я зараз ось так не згадаю і не зроблю, оскільки після курсу лінійної алгебри жодного разу не використовував. Цей «м’яз» все-рівно треба качати ) Він не так швидко атрофується, але атрофується.

flyman

Олег Дорожко 25.01.2021 16:01

Кажется я понял — я общаюсь упаковками вроде:
const newUser = { ...user, ...update }
Но я шизофреник (болезнь нервов такая) поэтому и не понимаю, зачем программистам гоняться за шизофреническим мировосприятием?
И да, я собираюсь использовать вассаби энжайн для оптимизации кодирования других собственных разработок.
Алгоритм на настоящий момент времени такой:
Программист составляет модель на естественном языке.
Компьютер выбирает подходящий язык программирования и генерирует детальный шаблонный код.
Программист исправляет ошибки в этом коде, добиваясь, чтобы тесты прошли.
Для trainee задач думаю трудности не составит такую схему запилить.
И еще, вассаби это НЕ готовый программный продукт, а просто модель, вроде модели планера.
Вы ведь не летаете на модели планера, несмотря на то, что эта модель может летать?
P.S.
Это все написано предполагая наличие заинтересованных в продолжении разработки движка.

Олег Дорожко 25.01.2021 16:03

Пропущенное НЕ в правилах что ли всему виной? Всему этому бардаку на нетфликс?

VL Software Engineer в Google 25.01.2021 13:22

Може вибирати, створювати алгоритми для складних задач

Ну-ну. Мне вот просто интересно, что автор подразумевает под «алгоритмом для сложных задач» и насколько часто это нужно среднестатистическому веб(!)-помидору. Львиная доля уже сделана до нас.

VL Software Engineer в Google 25.01.2021 13:12

«Подумаешь! Я ещё и вышивать могу, и на машинке — тоже...»

Andriy Zhilyaev Frontend developer 25.01.2021 11:40

На доу можно хоть через год зайти, а там все айтишники воображаемыми х*ями меряются, кто сеньор а кто нет))

Бурштиновий Майнер Вірю! Знаю! Порішаю! 25.01.2021 12:49

Так виріс же за рік у кожного!

Andriy Zhilyaev

Andriy Zhilyaev Frontend developer 25.01.2021 15:31

То мабуть компенсація за реальне життя, ну або побочка від смузі

Бурштиновий Майнер

Уставший архитектор 25.01.2021 03:42

Бред, вы трейни перепутали с джуном, а синьора с мидлом. В крайнем столбце у вас требования не более чем на мидла (ну что такое «знает основные Х»??)

beaver man 25.01.2021 16:16

поддерживаю. я вообще считаю что в крайнем правом столбце требования на трейни из какого-то зажопинска.. не говорю уже о Киеве. о каких сеньйорах вообще там речь.

сеньйор в 2021 должен уметь крутить красно-черные деревья в уме, работать исключительно на собственно написанных компиляторах и в свободное время проходить MBA курс чтобы говорить с бизнесом на одном языке.

Уставший архитектор

Olexandr 25.01.2021 16:17

Не кодив адронний колайдер — не сіньйор!

beaver man

Уставший архитектор 25.01.2021 22:27

Очередной культист невежества?

Olexandr

Dmitry Bugay 26.01.2021 14:27

Вот где хайлоад! Несколько сот гигабайт данных в секунду! Терабайтовые хранилища в оперативке! Не всякие там наколеночные поделия амазонов.

Olexandr

Jan Haring 26.01.2021 15:57

не уверен, что сможет тягаться с порнхабом.

Олег Дорожко 26.01.2021 16:36

Это все уже прошлый день. Я открыл кое-что поинтереснее.

flyman 24.01.2021 23:42

раніше було «якщо в тебе менше чим $2500, то ти не сенйор» , зараз, думаю планка $4000

Jan Haring 25.01.2021 00:12

Если дело только в деньгах, то пусть хоть джуном называют.

flyman

Andrew Frolov 25.01.2021 00:13

Jan Haring

Dmitry Bugay 24.01.2021 17:49

Вспоминается фрагмент (примерно) из цикла «Молот и Крест» Гарри Гаррисона:

— что надо сделать чтобы стать королем?
— стань в центре каждого селения и объяви себя королем. Если ты обойдешь так всю страну и выживешь то, стало быть, ты и есть король.

Если ты прошел на синьора и другие синьоры считают тебя синьором и тебе платят как синьору, то ты и есть синьор.

Alex Fogol Software Developer, C/C++ Expert 24.01.2021 19:13

Если ты прошел на синьора и другие синьоры считают тебя синьором и тебе платят как синьору, то ты и есть синьор.

duck typing ))

Олег Дорожко 24.01.2021 14:07

Не проистекает ли требование к элегантности кода (что конечно же хорошо) в основном из интересов поглотителя/заказчика ?
Если код жуткий, понять его сможет не каждый и такие специалисты (как я например) очень редки, а следовательно очень дороги.
Обычные кодеры обычный код поймут за меньшее количество часов, чем они же, но код жуткий (например, мой)

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 24.01.2021 20:32

Для заказчика элегантность кода находися в шестом приоритете. В приоритете номер один, чтобы его бизнес-задача была решена в минимальные сроки. И непонимание этого — наверное самая главная проблема инженеров постсоветской школы.
Это не призыв выдавать на-гора эпичный говнокод, просто обычно кода с минимально допустимым качеством вполне достаточно. Никто не оценит суперэлегантность, если это затянет проект на несколько месяцев

Vlad Stelmahovsky Software Engineer в Verity AG 25.01.2021 09:35

Для заказчика элегантность кода находися в шестом приоритете.

ровно до тех пор, пока этот код не надо мейнтейнить

anonymous 25.01.2021 09:42

-

Vlad Stelmahovsky Software Engineer в Verity AG 25.01.2021 09:51

как раз наоборот. хотя, смотря что подразумевается под

элегантность кода

anonymous

flyman 25.01.2021 10:02

элегантность кода

не крешиццо :)

anonymus ps 25.01.2021 13:08

когда смотришь на код через неделю и в целом можешь понять что он делает без огромного усилия

Vlad Stelmahovsky Software Engineer в Verity AG 25.01.2021 13:10

а если это не твой код? и смотришь ты на него впервые?

anonymus ps 25.01.2021 13:16

Это сильно субъективная оценка для элегантности кода. Может ты адепт фунциональщины и любое ООП для тебя чуждо как белый карлик за миллионы парсек от нас, а код писал рядовой ООПшник

Dmitry Bugay 25.01.2021 17:30

рядовое ооп как раз понимаемо легко, поскольку синтаксис и идея базируется на математических выражениях и точках.
А вот код рядового функциональщика в стиле -> (() -> { ()->{}, ((), ()-> {[]} хрен кто разберет

anonymus ps 25.01.2021 17:54

Вы просто ООПшник. Функиональщина не страшна как кажется

flyman 28.01.2021 13:33

А вот код рядового функциональщика в стиле -> (() -> { ()->{}, ((), ()-> {[]} хрен кто разберет

у вас три незакритих дужки

Dmitry Bugay 28.01.2021 17:19

у вас ~~дві~~ незкритих дужки

у вас три незакритих дужки

Спасибо :)))
Твой комент — отличный индикатор хреновой понимаемости фп-кода.

flyman

flyman 28.01.2021 17:21

да куда нам ембедерам кложури читать,
і все таки, що там за куйня з дужками,
чи функциональщикам пох

Dmitry Bugay 29.01.2021 00:43

Та то я просто на глаз скобок и стрелок насыпал типа функция функции функцией функцию функционально вызывает передает вызывая передачу вызова в вызов функции вызова функции.
Ну ты понел )

flyman

flyman 29.01.2021 01:07

да понєл, єстем троха рустаманем

Олег Дорожко 25.01.2021 13:27

Я через полгода смотрю и ок. И через два. Дело в скорости вспоминания. Чем больший промежуток времени от последнего использования/просмотра прошел, тем большее время срабатывания/всплывания воспоминания.
Но — знаю — когда помню.
Простота, атомарность, компактность, защищенность = элегантность
У каждого свое понимание что такое элегантный код (долго много любовно вылизанный и покрытый тестами) и чем он отличается от кода на скорую руку (лишь бы работал)

anonymus ps 25.01.2021 13:40

поздравляю что у вас такая память, я не помню что вчера было, а неделя назад это уже прошлая жизнь.

как-то раз, мне товарищ прислал код на ревью, и он был очень горд тем что его написал. когда я сказал что он не читабелен, то он смутился, слегка расстроился и спросил почему? на что ему ответил вопрос — а может ли он по 10 минутах как закончил писать этот код, объяснить как оно работает, и сможет ли он внести простенькое изменение в логику. он ответил что нет, и для изменения ему прийдется переписать весь код ибо он не понимает почему он работает.

итог — сам человек написавший его, является наилучшей лакмусовой бумажкой. другой человек может быть не знаком с концепциями которые использовал разработчик, но это не делает код плохим.

Олег Дорожко 25.01.2021 13:44

Я считаю пальцы на руке так: 1-2,2-3,3-4,4-5
Итого 5. Первый 1, Последний 5.
А те, у кого нет моих возможностей, талантов, особенностей реализации так:
1,2,3,4,5

Full Stackly 25.01.2021 13:45

по 10 минутах как закончил писать этот код

— это уже диагноз коду.

Олег Дорожко 25.01.2021 13:49

Верно. Элегантный код пишется / уточняется вечно ибо он всегда немножко не совершенен.
Критерий состязания — упрости мой код, но чтоб тесты прошел. В том числе и на отсутствие в коде упаковок.

Full Stackly 25.01.2021 14:00

Че за упаковки?

Олег Дорожко 25.01.2021 14:12

const newUser = {...user, ...update_data }

Full Stackly 25.01.2021 14:13

Нипанятна 8)

Олег Дорожко 25.01.2021 14:15

Вот именно... Элегантный код порождает минимально возможное количество ивентов.

Full Stackly 25.01.2021 14:16

нет, мне нипанятна, что ты имеешь в виду

Олег Дорожко 25.01.2021 14:20

Чтобы получить окружность, нужно к треугольнику добавить всего одну сторону. Несколько тысяч раз. Вот это и есть элегантный код.
Последовательное атомарное применение к входящим данным всего одного простого правила.

Full Stackly 25.01.2021 14:21

а где тут про упаковки?

Олег Дорожко 25.01.2021 14:26

Реализация внутри упаковки может быть любой. И нужно знать, какой именно иначе использование такой упаковки похоже на доверие к новой криптовалюте.
Разумеется, некоторые современные языки как раз и являются упаковками чуть больше чем полностью.
И это не честно. Это не путь DIY.

Full Stackly 25.01.2021 15:24

Ты open source имеешь в виду, типа все, что не открыто — в топку?

Олег Дорожко 25.01.2021 16:13

Путь DIY это когда легко разбирается и потом легко заменяется элемент или элементы и легко собирается и потом работает.
Смени стекло для мобилы в домашних условиях. Не можешь? Тогда мобила такая это не путь DIY

Dmitry Bugay 25.01.2021 17:32

Ахинея какая-то.

Олег Дорожко 25.01.2021 17:49

Вот щас обидно было.

Olexandr 25.01.2021 16:19

В жабоскрипті це мерджинг об’єктів, наскільки я пам’ятаю. Тобто все вірно — упаковка. Але так як в жс можна будь що з будь чим змішувати, то упаковка зветься сміттєвий пакет.

Dmitry Bugay 25.01.2021 17:28

Карму никто не отменял.

anonymous

anonymous 25.01.2021 17:36

-

Taras Morozovsky Senior C++ Overengineer 25.01.2021 10:30

Так-то да. Но со стороны программиста было бы наивно предполагать, что заказчик будет изначально понимать такие вещи. Это уже задача программиста донести до заказчика, мол, «если вы хотите максимально быстро получить решение сейчас, то мы можем наговнокодить за месяц, но суппортить это будет дорого; если дадите нам два месяца, сделаем по красоте и внедрять новые фичи / фиксить баги в этом будет намного дешевле».
Заказчик с небольшим опытом работы с командами программистов может и не понять, конечно. Но если он уже имел дело с проектами, которые живут больше года и в которых нужно регулярно что-то добавлять, улучшать или фиксить, то наверняка задумается и примет решение уже с учётом полученной информации.

Vlad Stelmahovsky Software Engineer в Verity AG 25.01.2021 10:47

да, пока заказчик на этом шишки не набьет, он не поймет, о чем ему толкует программист (хотя это задача скорее для менеджера проекта)

Taras Morozovsky

Taras Morozovsky Senior C++ Overengineer 25.01.2021 10:58

Конечно. Когда я говорил «донести до заказчика», я не имел в виду, чтобы программист в обязательном порядке с ним общался напрямую (хотя такой вариант тоже возможен). Можно доносить через менеджеров.
Но в любом случае важно, чтобы у программиста было вот это вот умение «переводить с технического языка на бизнесовый». И чтоб он не думал, что заказчик сам догадается о влиянии технической стороны проекта на бизнес, если программист эту информацию не донесёт.

Olexandr 25.01.2021 13:06

Якість коду це компонент якості продукту. Бізнеса з низькоякісним продуктом довго не живуть. Ось і все.

Taras Morozovsky

Taras Morozovsky Senior C++ Overengineer 25.01.2021 13:28

It depends. Якщо планується, що продукт буде жити багато років, поступово розвиватися, релізитись у нових версіях, що буде активний суппорт/багфікс, то так, якість коду повинна бути дуже важливим фактором для бізнесу (але нагадувати про це повинна девелопмент команда, щоб замовник давав їм достатньо часу на всякі рефакторинги і стабілізацію). Якщо ж планується випустити продукт швидко і 1) забити на його підтримку взагалі, 2) підтримувати не надто активно, вифікшуючи тільки критичні штуки і не розширюючи функціональність, 3) підтримувати активно, але бізнесу ну от ппц як важливо зарелізитися зараз, бо потім пізно буде, — якість коду може відійти на другий план, віддавши пріоритет швидкості розробки. Такі ситуації також бувають.

Згадаємо класику:

Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.

Olexandr

flyman 28.01.2021 16:04

Згадаємо класику:

помилка вижившого

Taras Morozovsky

Taras Morozovsky Senior C++ Overengineer 28.01.2021 16:12

помелрим видніше)

flyman

Dmytro Lapshyn Chief Technology Officer в Telmie 25.01.2021 13:34

Бізнеса з низькоякісним продуктом довго не живуть

Качество кода относится к так называемому «структурному» (внутреннему) качеству, которое далеко не всегда воспринимается и ощущается конечным потребителем.

Грубо говоря, купил ты музыкальный центр. Звук качественный, все заявленные функции работают. Если ты сам не электронщик, тебя сильно будет волновать, какое там «воронье гнездо» из проводов внутри, и сколько схемотехнических костылей вбили инженеры, которые его разрабатывали?

Плакать потом будут ремонтники, но тут уже вопрос бизнес-модели — возможно, из-за дешевизны производства вообще проще сразу поменять поломанный экземпляр на исправный, а поломанный разобрать на запчасти.

Olexandr

Oleg Korol перевожу души LPAR-ов по Стиксу с POWER7 на POWER9 26.01.2021 17:02

применительно к стартапам может и так, а для всех остальных действует принцип — Too Big to Fail

Olexandr

anonymus ps 24.01.2021 08:34

Фикшу код после таких сеньоров — недорого — 100$ час

Олег Дорожко 24.01.2021 08:11

Вот только что интересный пользовательский опыт «надыбал» / приобрел:
Захотелось сапоги, пошел искать. Отмел в сторону магазины с неудобным интерфейсом.
И еще «(по возрастанию/по убыванию)» не.
Лучше «(от 0 до 100 / от 100 до 0)»

Олег Дорожко 23.01.2021 23:56

А что, если некто умело находит ошибки?
Вот посадят его перед чужим кодом и скажут: разберись, почему не работает этот код.
Что это за несчастный? Сойдет ли решение такого задания за прохождение собеседование?

Nick K Работает в Self-employed 23.01.2021 23:09

сіпасібо завдяки вам я зрозумів що є джуном і буду джуном до кінця днів своїх.

Sergiy Morenets Java evangelist 27.01.2021 23:53

Якщо у вас буде сеньорская зарплата, то яка різниця?

Nick K

Nick K Работает в Self-employed 29.01.2021 18:56

то була іронія. Бо на оцей весь поділ мені начхати. я маю те що я хочу і в що я себе оцінюю. коли мене питають а ви сіньор я кажу — а біс його знає чітких критеріїв з палати мір і ваг досі нема тому називайте як хочете. Вмію те і те хочу то і то. І всьо. Ганяння за статусами вважаю дитячими забавками.

Andrey Rogovsky 23.01.2021 20:21

Привет, а ты точно техлид по вебу в продакте?
Тогда расскажи мне минимум две веб-технологии обеспечения платных онлайн-чатов без использования стейта серверной части. Да, заодно включи туда минимальный антифрод.
Рассказ веди так, будто объясняешь 8-и летнему ребенку.

Sergiy Morenets Java evangelist 27.01.2021 23:53

Цікаво послухати ваші відповіді на власні запитання

Andrey Rogovsky

Andrey Rogovsky 09.02.2021 04:16

Кто был на мастер-классе на последнем оффлайновом девопс-стейдже — тот слышал

Alex Raiev Software Engineer в Self-Employed 23.01.2021 11:33

Отак все і є. Спочатку одні складають таблички, а потім інші лікують синдром самозванця.)

Олег Дорожко 23.01.2021 11:43

Самозванец появляется, когда входные данные допускают множество решений. Это значит, что едва лишь завидев самозванца, необходимо быстренько суживать входящие до минимально возможного. Когда слишком много данных вычислители погрязают в рекурсиях (иногда зависают)

Alex Raiev

Luna 23.01.2021 16:11

Хто створює таблички, і є самозванцями ;)

Alex Raiev

Sergii Marushchenko .NET 28.01.2021 22:06

Найкраще синдром самозванця лікує проведення співбесід, перевірено :)

Alex Raiev

Serge Kulyk бригаден-фюрер в УдачныйСофт 23.01.2021 09:43

Приходит на память афоризм Козьмы Пруткова «Специалист подобен флюсу, полнота его односторонняя»

В разделе архитектура, почему-то метрики кода, хотя они должны быть в разделе Код.
В разделе Код почему-то говориться про уровень знания языка программирования и его ограничения.
Алгоритмы как-то уж очень поверхностно, типа слышал-видел-может, это не по сеньерски, можно было бы накидать хотя бы пару-тройку слов в тему, типа divide-and-conquer, динамическое программирование, графы и т.д.
Тема Баз данных не раскрыта, кроме реляционных есть NoSQL базы данных и CAP теорема относится в основном к ним, как впрочем и шардинг. Под деформализацией наверно имелось в виду денормализация?
Тоже самое про Безопасность, а как же типы угроз, уровни предотвращения угроз, а что про клауд?
И т.д. и т.п
Видишь эту «таблицу знаний» и сразу понятно, что за сеньер её придумал и для чего)
Жаль что Vladyslav решил остаться анонимом, имя продуктовой веб компании тоже была бы интересно, страна должна знать своих героев.

Олег Дорожко 23.01.2021 16:42

Давайте устроим состязание таблиц?

Serge Kulyk

Олексій Пєніє Developer, Java в забугорье 23.01.2021 02:20

Насправді я б усе це поміняв лише на 1 фактор: код зрозумілий, без зайвого ускладнення. Читай — код буде добре працювати, мало багів, не потребуватиме покриття 100500 тестами (які значно менш зрозумілі, ніж код), і найголовніше — такий код є продуктом, який потім легко підтримувати та розвивати. А не говнокодом, який дешевше викинути та переписати з нуля.

А ото лайно що ви понаписали — зветься БЮРОКРАТІЯ. А бюрократія є або доброякісною пухлиною, або злоякісною (що частіше), і вбиває бізнес незалежно від його успішності.

PS. Бог створив світ за 6 днів, бо йому не треба було робити його сумісним з минулими версіями.

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 23.01.2021 05:15

Принцип наименьшего удивления работает всегда :)

Elena Sharovar Node.js/JS lead в Waverley 24.01.2021 09:14

Я видела красивый код с багами. Написали красиво но 1) не учли все нужные edge cases 2) нет корректной обработки ошибок и вся система крешнется если что-то пойдет не так 3) если произойдут race conditions (придет два запроса к одной сущности почти одновременно) то произойдет deadlock. А код-то красивый, выровнен как под линеечку, переменные названы как будто боженька называл.
Аа еще фича-киллер: код красивый но грубейшая security ошибка когда какие-то credentials отдаются в JSON ответе сервера. Бери не хочу.

Олег Дорожко 24.01.2021 09:20

У младенчиков в IT 99.9% ошибок в коде, у джунов 30%, у мидлов 20%, у сеньоров 0%

anonymous 24.01.2021 09:25

-

VL Software Engineer в Google 25.01.2021 13:05

у сеньоров 0%

Oh my sweet summer child

Олексій Пєніє Developer, Java в забугорье 25.01.2021 13:45

Наивный. Как раз у младенчиков ошибок меньше. А вот у мамкин-синьор-архитектов...

Olexandr 24.01.2021 09:29

Значить той красивий код писав джун, який недавно прочитав про SOLID.

Elena Sharovar Node.js/JS lead в Waverley 24.01.2021 09:31

Или хотя бы Clean Code. Красиво научился, качественно еще нет.

Olexandr

Vadym Baranenko Solution Architect в EPAM 02.02.2021 16:30

вы так говорите, как будто это что-то плохое

Олексій Пєніє Developer, Java в забугорье 25.01.2021 13:47

Навпаки, якщо ти писатимеш код по SOLID, він буде щонайменше втричі монструозніший, і найголовніше, незрозумілим. Бо люди не логічні, їм важко буде і читати тупі абстракції, і правити їх, а шукати помилику то може й місяці зайняти.

Для людей SOLID є обфускацією. KISS — от що треба прийняти за аксіому.

Olexandr

flyman 28.01.2021 16:06

KISS my SOLID
(нова парадигма розробки)

Олексій Пєніє Developer, Java в забугорье 30.01.2021 01:35

metal ass

flyman

Сергій Машковський C# Developer 31.01.2021 02:26

чого ж про нього, СОЛІД, тоді так волають на кожному кроці?!

Олексій Пєніє Developer, Java в забугорье 31.01.2021 13:19

Про геїв теж волають, здебільшого ті хто сам не в темі.
Так і про SOLID — зазвичай лише манагери кукурікають та джуни вухасті. Доки їм не дадуть читати чужий код за усіма канонами соліду написаний.

Сергій Машковський

Sergey Lysak T/T Lead 24.01.2021 11:52

вот именно.
подобные дефекты кода — я постоянно и заворачиваю на код ревью. это основная причина.
причем «удивляюсь» про себя нередко — а чё, это разве не очевидно было, что его еще и увековечивать кодом нужно было?

и вот когда не очевидно, то два основных варианта
это новенький на проекте.
мидл или джун.

но самое сложное конечно это — отсутсвующий код, который должен был быть. и если сам плотно задачу не анализировал, то апрувишь код...

Олексій Пєніє Developer, Java в забугорье 25.01.2021 13:48

Третий основной вариант — ты сам это писал, просто уставшим

Олексій Пєніє Developer, Java в забугорье 25.01.2021 13:42

Как раз это лечится опытом, а ещё надёжнее — курсами. Да, представьте себе, для специалистов тоже нужны курсы. Правда это уже коротенькие достаточно, онлайн, и по большей части на инглише.

А по поводу кода под линеечку — как раз это ошибка. Код не должен красиво выглядеть. Он должен читаться. И красиво выглядеть только издали, блоками и структурно. Но не так что jf в 5 строчек и 3 табулятора.

В остальном... это свойственно как раз таки прокачанным рабочим лошадкам, те кого «обучили», но сам учиться не имеет. Те, кто входил в IT с собственных проектов, наоборот, скорее неправильно назовут переменные (потому что надо БЫСТРО кодить, а не мозги полоскать), но вот на секьюрити и прочие грабли потратят 90% времени.

В остальном спецы нужны разные. И если где-то нужно велосити, а не качество — так тому и быть. И если в вашей конторе ОЦЕНКА ведётся именно по скорости и это ключевой показатель — то вам такой спец нужен.

PS. А вот по поводу переменных «как боженька назвал» — покажите пожалуйста. Потому что это на словах красиво звучит, но когда начинаешь пытаться понять что оно зачем — понимаешь что и боженька с именами явно не синьор, даже сынулю не мог назвать чтобы это однозначно писалось со слуха. А детское имя как — ися? изя? исюсик?

Victor Gubin Programmer 26.01.2021 12:27

Ну вот поэтому ви и лид а не синиор. 2. Между спагетти кодом и лазанья кодом я все же выбираю лазанью. Туда легче добавить всего чего в нем не хватает и изменить то что нужно. Мешанину «с душком» (с. Мартин Фаулер) надо рефакторить, бывает и так что иногда дольше чем с нуля написать.

Олексій Пєніє Developer, Java в забугорье 31.01.2021 13:29

В спагетти-коде можно одним Ctrl-F быстро просмотреть все вхождения одного бага. Единственное, чего на самом деле не хватает спагетти-коду, так это IDE, способного открывать один файл в разных окнах.

Этого же не хватает обычным текстам, но с теми есть обход проблемы через создание копий. И это работает только на чтение. А вот с редактированием — реальная фича, которую стоит запилить.

Навигация же по спагетти-коду при грамотном компактном написании достаточно беспроблемная, и если там до 2000 строк, не вижу большого смысла делить на файлы, если там одна сущность описана.

Для понимания: в сказке Конёк-горбунок ≈3000 строк. А теперь прикиньте, как бы она выглядела с полным соблюдением SOLID-бюрократизма.

Victor Gubin

Vadym Baranenko Solution Architect в EPAM 02.02.2021 16:27

ну в таком коде легче фиксить все сказанные проблемы, надеюсь конечно что кода без тестов уже никто не пишет

Evan Demenkoff Senior JS Developer 23.01.2021 00:32

побачивши на першому ж слайді текст фонтом Comic Sans — вирішив далі не читати.

anonymous 22.01.2021 21:24

-

Олексій Пєніє Developer, Java в забугорье 25.01.2021 13:49

Страсть говоришь? Да лозунг 98% здесь сидящих звучит «И так сойдёт!»

anonymous

anonymous 25.01.2021 18:33

-

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 25.01.2021 18:43

фанатов своего дела или просто трудоголиков.

Как ты красиво переформулировал «задрот-ноулайфер» :)

anonymous

Олексій Пєніє Developer, Java в забугорье 26.01.2021 11:05

И ещё больше выгоревших, как раз поэтому. Когда их код щедро потом разбавлен дерьмом джунов, только потому что Сове тушканчики обходятся дешевле.

anonymous

anonymous 26.01.2021 11:07

-

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 22.01.2021 21:06

НА САМОМ ДЕЛЕ, senior — это человек, который обладает адекватным опытом, более-менее знаком с доменной областью, и базируясь на этом, может самостоятельно проанализировать бизнес-проблему, адекватно оценить время на ее решение, и решить ее в срок согласно своей оценке с приемлемым качеством кода, на уровне обычного middle-программиста. Все.

Типа как капитану в армии не обязательно лично быть супер-пулеметчиком или супер-гранатометчиком, у него уже основные задачи и требования к нему несколько другие

Sergey Lysak T/T Lead 22.01.2021 21:11

Все.

не все.
синьор — это еще и софт скилы, обычно. благодаря которым он лидить может, немножко, и менторить, чуть-чуть.

в табличке это просто технические скилы. в крутой компании, с серьезными проектами и требованиями и мидл может обладать набором из колонки синьорства.

софтскилы — вот окончательная точка в разнице.

Андрей Осипов 22.01.2021 21:19

неверно, выше правильно написали, про «анализ и оценку бизнес проблем в одиночку», в табличках по тех-скиллам этого нет. Но именно это и имеет значение, когда работаешь на внешних проектах. Умеешь из общего описания бизнес-проблемы сконструировать сторис, разбить на таски, оценить и выполнить — ты senior. Тебя можно закидывать в любую компанию, ты сможешь там плавать. Все очень прагматично, по софт скиллам — говорить адекватно по английски, все.

Victor Gubin Programmer 25.01.2021 17:39

В продуктовых компаниях это умение ценят ещё выше. По сути это умение зарабатывать деньги, даёт воспроизводимость результата. Кстати совсем не обязательно в одиночку и может быть даже вредно в одиночку.

Андрей Осипов

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 22.01.2021 21:19

Это подразумевается. Без софтскиллов обычно сложные проблемы не решаются, так как сложные проблемы подразумевают обширную коммуникацию в самых разных направлениях.

Alex Fogol Software Developer, C/C++ Expert 23.01.2021 01:33

я знаю множество людей с могучими софт скиллами которые не брезгуют моими скромными «советами» по решению сложных проблем подразумевающих обширную коммуникацию в ходе чего они реализуют обширную коммуникацию а я направления и темы и обобщающие выводы и наводящие вопросы по ходу в свою очередь экономящие ещё тонно человеко часы «обширной коммуникации в самых разных направлениях»

работает я проверял ))

ЗЫ: ну и да одно другого не отрицает но чаще возможность скоммуницировать как-то находится а вот возможность оборзеть сложную проблему до её решения уже не всегда и если ты таки умеешь делать последнее тебя таки будут старательно слушать и помогать «с коммуникацией» а вот наоборот это уже чистый трёп это боюсь уже не за компьютеры )) в политику может?

Alex Fogol Software Developer, C/C++ Expert 23.01.2021 01:00

синьор — это еще и софт скилы, обычно. благодаря которым он лидить может, немножко, и менторить, чуть-чуть.

ну да ну да и шапочка ))

лично я на практике столкнулся с тем что если синьор может просто взять и сделать задачу и его не надо постоянно направлять то это уже нормальный годный синьор годный к употреблению

если синьор может ещё и самоорганизоваться в команде синьоров то это вообще уже идеал супер синьор я бы б сказал но чаще это банально «реальный лид» здесь «реальный» это термин для той реальности с которой реально приходится иметь дело

ЗЫ: ну может в фхтангах это и не так

софтскилы — вот окончательная точка в разнице.

а ну ок ))

Victor Gubin Programmer 25.01.2021 17:37

Не думаю что это даже софт скилы, это хард скилы. Бессмысленно знать миллион фреймверков если все равно не знаешь как из применить на практике для решения бизнес задачи.

Sergey Lysak T/T Lead 25.01.2021 17:43

Бессмысленно знать миллион фреймверков

разумеется.
знание и навык — это разные вещи. понимание — тоже, отдельная штука, отличная от знания и навыка.

если все равно не знаешь как из применить на практике для решения бизнес задачи.

ну вот одно из отличий тоже, синьора от мидла
синьор в первую очередь думает о бизнес задаче, а потом о фреймворках, тех что знает, да и тех что не знает
мидл думает о фреймворках, а потом, если хороший, о бизнес задаче. а может и не думать о б.з., протестуя: «Мне за вовлеченность не доплачивают!»

это софт или хард скилы?

Victor Gubin

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 25.01.2021 19:28

синьор в первую очередь думает о бизнес задаче, а потом о фреймворках, тех что знает, да и тех что не знает
мидл думает о фреймворках, а потом, если хороший, о бизнес задаче. а может и не думать о б.з

Отлично сказано. Добавлю еще, что синьор всегда учитывает существующую архитектуру и старается делать единообразно, даже если что-то не хайпе или самых последниих версиях.

Max Shnurenok .NET Architect в LogiqApps AS 25.01.2021 20:07

делать единообразно

В рамку и на видное место. Как-то у меня спросили на интервью у клиента, а как Вы относитесь к разным подходам работы с данными через код: просто ORM, или навернуть ещё паттерн репозиторий, rich vs anemic model, как с DTO и т.п. Ну, я говорю да, в интернете холивары постоянно, лично я люблю так, так и так, по следующим причинам, но, честно говоря, самые большие проблемы не от того, что выбрали неправильные конвенции, а из-за того, что их нет, и люди банально как попало называют модели и пихают их куда попало, с чем во многих проектах приходилось воевать, т.к. бардак а-ля User, UserModel, UserDto, UserRecord, UserRequest, UserResponse, UserMessage, разбросанные как попало по разным папкам в разных неймспейсах, сильно бьёт по восприятию и поддержке. Поэтому я с готовностью приму решения большинства, лишь бы они были, и за этим следили на код ревью.

flyman 28.01.2021 16:10

делать единообразно

безобразно но единообразно!

Олег Дорожко 25.01.2021 17:46

Знания/Память о миллионе фреймворков в мозгу съеживается до многомерного все-подобия.
И будет использовано не только в точных ситуациях но и в похожих.

Victor Gubin

Igor Olhovskiy Computing/Telecom Engineer в CERN 25.01.2021 17:52

Дополню, что основное отличие — не «чуть-чуть», а все-таки полноценно уметь руководить командой. Т.е. уметь не только написать код самому, но и еще понять кто из команды может с этим справиться и проделегировать.
Кажется, что я описал тимлида, они и правда похожи (как по мне), но тимлид все-таки больше про административку, а синьор — про код.

Олег Дорожко 25.01.2021 17:55

А еще в команде должны быть сумасшедшие изобретатели, вроде такого из «Назад в будущее»

Igor Olhovskiy Computing/Telecom Engineer в CERN 25.01.2021 18:00

Это люди полезные, но в малом количестве. Когда такой один, всем хорошо. Когда два — уже беда.
Но я просто к тому, что в укрИТ понятие «сеньор» какое-то странное. В смысле это нифига не синьоры, а просто крепкие миддлы.
Напоминает ситуацию с карточками банковскими. Во всем мире Золотая Карточка — это предел, но в СНГ и у арабов, кажись, придумали еще и платиновую, кроме понтов ничего не дающую. Зато золотые начали раздавать чуть ли не всем. Вот и с синьором так получилось.

Sergey Lysak T/T Lead 25.01.2021 17:59

Кажется, что я описал тимлида

и потому все таки — «чуть-чуть». лид это лид, тим или тех. синьор умеет чуть-чуть, то есть побыть некоторое время и.о. и не запороть все.

а синьор — про код.

нет, про код — мидлы думают. потому что умеют.

нередко поэтому мидлы и бузят
да я пишу код лучше чем синьор такой то! почему же он синьор а не я?

и правильно бузят, когда пишут хороший код, а синьор — приемлимого качества.
только вот не понимают что разница в этих «чуть-чуть»

ну и конечно в правилах раздачи лычек, которые к теме о скилах нередко не имеют никакого отношения.

Igor Olhovskiy Computing/Telecom Engineer в CERN 25.01.2021 18:03

Тут, мне кажется, можно спорить как про цвет платья.
Но в целом, да, синьор это про софт-скиллы. И про такое понятие, как ответственность :)

Sergey Lysak T/T Lead 25.01.2021 18:16

Тут, мне кажется, можно спорить как про цвет платья.

зависит от целей.
цвет платья тоже можно подбирать согласно целей — это платье скрывает полноту? а насколько маркое? «мне назначена встреча с японской императорской семьей» — тогда желтый цвет нежелателен (хотя запрет действовал лишь до VIII века. )

так и тут — какая цель в определении различий мидла, синьора и лида — такой будет и результат
можно и подобрать цель — что не будет никакой разницы :)

Igor Olhovskiy Computing/Telecom Engineer в CERN 25.01.2021 18:36

Цель — это частный случай всегда. Тут же мы говорим о некоем «сферическом синьоре в вакууме». Т.е. чтобы человек, переходя из компании А в компанию Б одним термином мог объяснить свои обязанности на предыдущем месте и свои компетенции. Понятно, что потом все уйдет в частности.
Спор про определение «в среднем по больнице»

Sergey Lysak T/T Lead 25.01.2021 18:58

Цель — это частный случай всегда

конечно. по другому и не бывает. вы хоть термин «Бог» возьмите определить — определения тоже будут зависеть от цели определения

Тут же мы говорим о некоем «сферическом синьоре в вакууме».

не знаю о чем вы

тут говорят о вполне конкретных критериях
качественной разнице,
тех скилов
глубины знания
уровня зарплаты
...,
для того чтобы можно было определить — кто ты сам, кому что можно поручить, а кому не стоит.

Т.е. чтобы человек, переходя из компании А в компанию Б одним термином мог объяснить свои обязанности на предыдущем месте и свои компетенции

у компаний А и Б могут различаться эти наборы.

Понятно, что потом все уйдет в частности.

вначале в категории, в контексты:
мы говорим об уровне развития специалиста?
о лычках? и т.д.

никаких сферических синьоров никто в таких темах не обсуждает :)

Спор про определение «в среднем по больнице»

ничуть
он возникает потому что — разные контексты у спорящих.
никакого среднего между красным и соленым быть не может.

Igor Olhovskiy Computing/Telecom Engineer в CERN 25.01.2021 19:10

тут говорят о вполне конкретных критериях
качественной разнице,
тех скилов
глубины знания
уровня зарплаты

Правильно. Т.е. эти самые критерии и являются поводом для «лычки», но для каждой компании они свои.

у компаний А и Б могут различаться эти наборы.

Вот-вот.
НО. Когда человек говорит, что он «синьор» или «миддл» — это не вопрос про кто какой стек знает и умеет отличить докер от подмана. А про класс выполнения задач. Т.е. никто не ожидает, что если человек назвался «синьором», то его на проекте новом нужно будет водить за ручку. В отличие от «джуна». Иногда «миддла». Или когда за «миддлом» нужен не такой пристальный надзор на ранних этапах, как над «джуном».
Но все эти паттерны поведения и отношения являются уже следствием глубины знаний и софт-скиллов конкретного человека.

Sergey Lysak T/T Lead 25.01.2021 19:17

Т.е. эти самые критерии и являются поводом для «лычки»

в общем случае — нет
критерием могут быть не указанные критерии — мотивационный или для продажи в аутстафе.

Когда человек говорит, что он «синьор» или «миддл» — это не вопрос про кто какой стек знает и умеет отличить докер от подмана.

это вообще дело десятое, что человек говорит. другой контекст.

А про класс выполнения задач

да, это один из контекстов.

Т.е. никто не ожидает, что если человек назвался «синьором», то его на проекте новом нужно будет водить за ручку

почему не ожидает? зависит от проекта. и если на проекте вменяемые — то поводят за ручку, чтобы быстрее начал работать, вышел на уровень продуктивности на который брали

В отличие от «джуна». Иногда «миддла».

не согласен. даже в нашем мелком проекте я бы потратил не один день чтобы ввести в курс дела, а не бросать плавать — даже синьора.

Но все эти паттерны поведения и отношения являются уже следствием глубины знаний и софт-скиллов конкретного человека.

....и проекта.

уже писал пример
оба капитаны — американской атомной подлодки и аргентинской дизельной.
вы считаете что капитана аргентинской дизельной не надо поводить за ручку по атомной если взали даже не на капитана, а на какую-то другой офицерскую должность? сам разберется?

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 25.01.2021 19:42

зависит от проекта. и если на проекте вменяемые — то поводят за ручку, чтобы быстрее начал работать

Думаю что речь шла немного о другом. Когда на проект заходит новый senior специалист, то я ожидаю примерный паттерн поведения:

0. Знакомство с командой
1. Короткий овервью митинг плюс ссылки на проектную документацию
2. Краткое самостоятельное погружение в курс дела
3. Несколько митингов для ответа на конкретные вопросы

При этом я ожидаю, что текущие вопросы (типа доступов) он решает самостоятельно, после знакомства с командой

А не о том, что «оружие добудешь в бою, ура сразу в атаку»

В отличие от — «ну давайте, рассказывайте мне неделю по 4 часа в день как оно все у вас тут»

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 25.01.2021 18:31

более-менее знаком с доменной областью, и базируясь на этом, может самостоятельно проанализировать бизнес-проблему

Имеется в виду senior business analyst?

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 25.01.2021 19:05

К большому сожалению бизнес-аналитики это больше исключение чем правило в современной разработке. И да, нормальный senior как минимум должен уметь в UML и в нормальную декомпозицию и постановку задач

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 25.01.2021 19:33

Ок. Назовём его иначе — продакт оунер. Он тоже большая редкость в современной разработке?
Или может, скрам большая редкость?
Или бэклог никто не мейнтейнит?
Я при любом собеседовании первое что спрашиваю у менеджера, это процесс и методология постановки задач.

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 25.01.2021 20:18

Назовём его иначе — продакт оунер

Средний продакт оунер тебе запилит юзер-стори типа «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»
Чуть более продвинутый — разобьет на две — логин и логаут.

Вопросы выбора конкретного протокола, провайдера — это и не его, в принципе, компетенция. Также как и декомпозиция этой стори с точки зрения реализации.

Stanyslav Semukhyn Senior Android Developer в Doesn't matter 25.01.2021 20:22

Вопросы выбора конкретного протокола, провайдера — это и не его, в принципе, компетенция.

А это и не является доменным знанием. Знание протоколов — это знание технологий

Stan Maleev worker 26.01.2021 02:35

Типа как капитану в армии не обязательно лично быть супер-пулеметчиком

Не знаю, что в современной армии, но в ВОВ дед был капитаном, и хорошо разбирался в пулемётах. Рассказывал, что даже в кармане небольшие расходники носил — чтобы пофиксить что-то в пулёмёте, когда неопытные (за теми пулеметами они как «расходники» были — ибо в полный рост за станком стояли) бойцы жаловались на его работу.

Это сообщение не против утверждения про сеньёра, но про плохую аналогию.

Max 26.01.2021 11:45

І де тут сеньор?
Ні слова про код рев’ю, про менторинг і про обмін досвідом. Ні слова про софт скіли і можливість адекватної бесіди з клієнтом.
«Приємлівое качєство» — це не рівень сеньора

Sergiy Morenets Java evangelist 27.01.2021 23:56

А хіба капітан — це еквівалент сеньйора? Капітан це рівень командира роти або заступник командира батальйону. А рота — кілька взводів (по суті команд). Явно, що сеньйор іншим займається.

Alex Fogol Software Developer, C/C++ Expert 28.01.2021 02:29

ну так а сіньор це навіть не офіцер ))

только в самом конце разговора я обидел его я сказал капитан никогда ты не будешь майором (к)

ЗЫ: і доречі цікава думка подумати над тим як сіньор виглядає «за аналогією» армійського принципа переймання командування за умови втрати старшого офіцера

Мамкин АЙПИшник 28.01.2021 03:06

Синьер — сержант в армии(званиие).
Лид — старшина(должность).
Отличие от рядового — может самостоятельно выполнить отдельную задачу, иногда даже правильно.
Задачи старшины помимо всего прочего *вытирать сопли новобранцам* и следить чтобы сапоги одевали левый-на-левую 8)

Ни тот ни другой никогда не станет генералом в старой армии.
Офицеров же обычно учат(в вузах 5 лет) как обьяснить куда воевать, и кого-то заставить делать то, что нехочется.
Хорошие офицеры обычно знают скорость полета пули(снаряда,ракеты, и проч. вундервафель), и количество *стволов* чем создают ошибочное мнение что умеют этим пользоваться. 8)

Например в армии сша может быть *главный сержант рода войск*
подчиняется напрямую коммандующему(например ввс) но всеравно отвечает за патроны, запас трусов на складах и *боевой дух* личного состава — разница только в маштабе.
По этому в армии(как правило) знание любых средств вооружения(или базвордов), даже на уровне iddqd не даст возможности решать глобально — что делать.
По этому когда рассказывают что им нужны *рембо*(или фуллстек например) и тщательно перечисляют необходимый опыт(типы патронов, количество траков на танке, почему люки круглые — и проч. что гуглится за 15 сек).
— то это скорее всего либо понты(за которые обычно не доплачивают), либо мясорубка с *рыцарями без головы* вместо офицеров.

flyman 28.01.2021 16:17

умови втрати старшого офіцера

ПМ шолэ?

«отряд не заметил потери бойца»

Vasiliy Dicjak Многорукий Шива 22.01.2021 20:21

Конечно нет, я только собесы на сеньйорную пайку прохожу. Не понимаю зачем все это знать ;-)

Dan vor de Hoorth 22.01.2021 18:46

Пора програмістам створити таку табличку для Project Manager, Scrum Master, Agile Coach, HR, Happiness Manager...

Олег Дорожко 22.01.2021 17:03

Так забирают ли сеньоры у джунов всю работу?
Вот доказательство, что забирают: dou.ua/...rums/topic/32483/#2042390

Denis Reznik Data Architect в Intapp 22.01.2021 16:58

Прочитав і зрозумів, що я мабуть по Базам не сеньйор. Навіть не чув про деформалізацію бази, не те що робив.

Dmytro Lapshyn Chief Technology Officer в Telmie 22.01.2021 17:39

Гадаю, що мова насправді була про денормалізацію

Denis Reznik

Биг дата копатель 23.01.2021 04:55

Автору самому стоит её изучить, а он точно лид?)

Alexander Merkulov asterisk guru 22.01.2021 15:10

Это какой-то бред честно говоря.
Это не сеньйор получится а какой-то супер-фул-стек. Чего только стоит требование понимания ограничения РАЗНЫХ баз данных. Вы еще напишите «всех».
Это скорее таблица как завалить любого кандидата. Мне не попадалися даже техлиды хотя бы с половиной требований.

John Appleseed 22.01.2021 15:40

Таблица действительно, чтобы завалить кандидата и не раздумывать над тем «почему нет»
Если все идёт к тому, что надо брать — таблица прячется куда подальше.

Dmytro Lapshyn Chief Technology Officer в Telmie 22.01.2021 17:49

Чего только стоит требование понимания ограничения РАЗНЫХ баз данных.

Например, понимание того, что в документной NoSQL базе скорее всего будет сложно обеспечить referential integrity между коллекциями, в то время, как в практически в любой реляционной БД это как два пальца об асфальт — это какое-то космическое требование на senior уровень?!

Или, что в условном PostgreSQL есть триггеры, а в условном MariaDB их нет — это тоже какое-то адское требование, по-вашему?

Я, разумеется, не знаю, что имел в виду автор таблицы, но само по себе ожидание расширенного технического кругозора от senior разработчика выглядит более чем разумным. Это не значит, что senior без подготовки сможет взять любую БД и эффективно с ней работать. Это значит только то, что senior хотя бы интересуется чем-то за пределами привычных ему технологий и инструментов.

а какой-то супер-фул-стек

С тем, что список навыков подразумевает, скорее, back-end, а не front-end — да, соглашусь. Но, опять же, такое разделение — это уже специфика современного украинского рынка труда. Тот же Beaver Green не раз писал, что в начале-середине 2000х все толковые разработчики были фулл-стек (и я, своим опытом, тоже готов это подтвердить).

Если уж говорить о базах данных, то, тогда, скорее, DBA были отдельной «кастой» — но и это не означает, что разработчикам не приходилось писать хранимые процедуры и триггеры (не говоря уже о SQL запросах, далеко не всегда тривиальных)

Alexander Merkulov asterisk guru 22.01.2021 17:54

Вот вы и показали, что вы этому требованию НЕ соответсвуете.
В mariadb есть тригеры, кстати. Еще с mysql 4 они там есть. Но очевидно, что вы не можете прилично хорошо знать Postgress, Mysql, mariadb, oracle, Cassandra, Aerospike и чего там еще знает ваш интервьювер и при этом знать остальные пункты.

Dmytro Lapshyn Chief Technology Officer в Telmie 22.01.2021 18:57

Вот вы и показали, что вы этому требованию НЕ соответсвуете.

Ну, то есть, вы предпочли докопаться к деталям, проигнорировав слово «условный», которое я специально написал именно для того, чтобы не было придирок к выдуманному с потолка примеру. Отличный уровень дискуссии, я считаю.

что вы не можете прилично хорошо знать Postgress, Mysql, mariadb, oracle, Cassandra, Aerospike и чего там еще знает ваш интервьювер и при этом знать остальные пункты

А что, кто-то требует в обязательном порядке прилично хорошо знать все эти базы?

Ещё раз — суть требования (как я его понимаю) в том, что человек на senior позиции в принципе понимает, чем вообще могут отличаться разные БД — набором фич (да, те самые триггеры, хранимые процедуры и т.п.), способом хранения данных (по строкам / по колонкам), парадигмой (реляционная, документная, графовая...). Знать, что такое CAP теорема, наконец.

Детали по конкретной базе ищутся в документации, это ежу понятно. Главное — знать, что искать, а не тулить в проект ту или иную БД потому, что «а вот друг Вася использовал, ему понравилось».

Alexander Merkulov asterisk guru 22.01.2021 19:05

суть в том, что тут такой набор, который нереален на необходимом уровне для среднего человека.
Нельзя требовать от кандидата знать вот эти общие вещи вот в такой постановке.
Можно требовать знать mysql или postgress на среднем уровне, но не блин то, что там написано.
Нафига среднему сеньйору уметь делать шардинг? Нафига среднему сеньйору знать ваши (неописанные) базы? Очень мало людей знает больше двух-трех ВООБЩЕ.

Вот я вас попрошу написать агрегатор для Aerospike, вы, думаете, справитесь? да там же простой lua, подумаешь. И пофиг, что там надо еще пару дней читать доки просто чтоб ответить на вопрос.

Dmytro Lapshyn Chief Technology Officer в Telmie 22.01.2021 19:58

Очень мало людей знает больше двух-трех ВООБЩЕ.

Так а где в табличке написано, что нужно знать больше? Написано — «несколько», две-три в это определение вполне попадают. Ну и, получить за несколько лет опыт работы c, например, MariaDB, PostgreSQL и какой-нибудь Монгой — кажется, более чем реально. По крайней мере, уровень понимания основных возможностей и ограничений этих БД такой опыт точно даст.

я вас попрошу написать агрегатор для Aerospike, вы, думаете, справитесь? да там же простой lua, подумаешь. И пофиг, что там надо еще пару дней читать доки просто чтоб ответить на вопрос

Покажите, пожалуйста, где вы видите в обсуждаемой табличке подобные требования? Вместе с тем, общее знание о том, что в NoSQL базах данных агрегации вполне вероятно придётся писать руцями — senior’у будет более, чем полезно. Ну, хотя бы, для того, чтобы не тащить, поддавшись хайпу, NoSQL базу в проект, где ожидается большое количество отчётов и дашбордов, которые потянут за собой эти самые агрегации.

Нафига среднему сеньйору уметь делать шардинг

А вот тут начинается самое интересное. Я не зря выделил жирным слово «среднему».

В понимании автора этой таблички (да и в моём, по большей части) senior — это специалист, способный решать нетривиальные задачи. Если говорить конкретно о back-end, то, да, в том числе — high load, где требуются шардинг и денормализация. Ну, чёрт возьми, хотя бы иметь представление о том, как такие задачи решаются.

Разработчик, который просто хорошо умеет в свой стек и вышел на плато продуктивности в нём в решении типовых задач — это strong middle.

Alexander Merkulov asterisk guru 22.01.2021 20:06

Да, тяжело вам наверно сотрудников искать.

Dmytro Lapshyn Chief Technology Officer в Telmie 22.01.2021 20:21

Слушайте, ну я не исключаю, что у меня устаревшие представления о мире, но когда я сам ещё был разработчиком, поработать с разными базами данных и даже разными технологическими стеками за несколько лет карьры — более чем реальный кейс.

И, ещё раз — никто не ожидает идеальных и супер-глубоких знаний по каждой БД (раз уж мы за них зацепились). Важно понимание, чем фундаментально могут отличаться разные БД, и какие они вообще бывают.

Alexander Merkulov asterisk guru 22.01.2021 20:23

Да они ВСЕМ могут отличатся.
А требовать от разработчика вот этот список это жесть.

Dmytro Lapshyn Chief Technology Officer в Telmie 22.01.2021 20:41

А требовать от разработчика вот этот список это жесть

Погодите, я правильно понял, что жестью вы называете вот этот список:

Виды баз — классические реляционные, документные, графовые, колоночные
Различие по поддерживаемым фичам — транзакции, блокировки, триггеры, агрегации...
CAP теорема и какие комбинации обычно бывают

На всякий случай — речь НЕ идёт о том, чтобы разбудить человека посреди ночи, и он без запинки расскажет характеристики любой выбранной БД. Только лишь о понимании, по каким параметрам могут вообще отличаться разные БД, и как эти параметры связаны с применимостью БД под конкретные задачи.

Грубо говоря, что для агрегации по миллионам строк лучше подойдёт колоночная БД, для OLTP нагрузки без намёка на хайлоад — классическая реляционная, скорее всего, будет оптимальным выбором, если часто меняется схема данных, то может хорошо зайти документная БД (но нужно быть осторожным со ссылочной целостностью) и т.п.

Alexander Merkulov asterisk guru 22.01.2021 20:44

Правильно правильно.
А зачем тогда специалисты по базам и архитекторы по вашему?
А еще там чуть дальше перечисленны навыки девопса, причем не особо то и начальные, и ваш супер-сеньйор тоже в них должен хорошо ориентироваться.
В результате вы получите фигового абсолютно во всем специалиста, ибо у него тупо не будет времени все это обновлять до текущего стандарта. ну или на работу не будет времени

Sergey Lysak T/T Lead 22.01.2021 20:51

Правильно правильно.

конечно — правильно :)
не синьор просто, и все.
почему я могу поговорить на эти темы, не будучи специалистом по БД — а другой синьор — но не может?

В результате вы получите фигового абсолютно во всем специалиста

это уже зависит от кто нужен.

ибо у него тупо не будет времени все это обновлять до текущего стандарта.

этого и не требуется. требуется — понимание вещей выходящих за рамки узкого специалиста.
у узкого специалиста понимания нет — ну значит он мидл.
вот и все.

а почему мидл пытается доказать что он синьор, выдвигая собственные критерии — то уже другой вопрос.
и почему компания ему вручает лычки синьора — то уже третий вопрос.

Alexander Merkulov asterisk guru 22.01.2021 20:56

Да, конечно.
Почему физик-ядерщик не в курсе как рыбу на блесну ловить, если я в курсе.
Че, реально в это верите?

Sergey Lysak T/T Lead 22.01.2021 21:04

Почему физик-ядерщик

зато он в курсе мат. аппарата.
а ловец на блесну — нет.

Че, реально в это верите?

а чего тут верить? за карьеру перевидел тьму разных программистов. в разных доменах, компаниях.

и кто такой синьор — у меня вопросов нет
как и кто такой мидл — тоже.
как и почему мидлы часто возмущены — себя они уже записали в синьоры, и пытаются доказать что критерии для синьоров под которые они не подходят — фейковые.

недавно на доу какой-то джун доказывал что синьоры — это вообще костные ретрограды (занявшие тепленькие места, куда ему, джуну хотелось бы)
ну, понятна причина его такого твердого убеждения :)

так что тут даже от обратного можно
возмущен критериями синьорства? ну наверное мидл потому что :)

уже писал, вы сами можете все проверить
гуглите разнообразные интервью, опросы тех лидов о том, кто такой синьор.

подумалось, еще краткий критерий
синьор и тех лида подсидеть может.
а вот мидл — нет.

Alexander Merkulov asterisk guru 22.01.2021 21:32

В этом случае блесна — это вот эти узкие требования к специалисту, физику-ядерщеку.
Понятно, что вам не интересно читать, только писать.
Причем тут джун?
Не вижу смысла с вами препираться, бессмысленно.

Sergey Lysak T/T Lead 22.01.2021 21:44

Требования к мидлу — узкие
к синьору — широкие.

А джун при том что узкий специалист хочет чтобы его называли широким специалистом, но возмущён что почему то требуют для этого -широких знаний.

Lena 25.01.2021 13:58

Требования к мидлу — узкие
к синьору — широкие.

так говорят те, кто хочет найти сеньора на зп мидла. мол ты не умеешь

рыбу на блесну ловить

значит не сеньор. а надо ли это для выполнения текущих задач история умалчивает

Sergey Lysak T/T Lead 25.01.2021 17:19

так говорят те, кто хочет найти сеньора на зп мидла. мол ты не умеешь

пусть говорят. вы же синьор — вакансий тьма — идите к другим, на зп синьора. делов то!

значит не сеньор

вы собеседуете — вам и решать, и предлагать не умеющему ловить на блесну — мидловую зп.

Lena

Андрей Осипов 23.01.2021 03:13

почему я могу поговорить на эти темы, не будучи специалистом по БД — а другой синьор — но не может?

Уверен, что этот сеньор найдет темы, в которых он не специалист, но про них он поговорить сможет, а ты нет.

Sergey Lysak T/T Lead 23.01.2021 07:59

я такие темы нахожу постоянно, когда синьоры на доу сдуваются :)

найти несходящиеся темы на самом деле просто всем.
даже математикам с мировым именем но с разных областей

Андрей Осипов

Andrew Frolov 22.01.2021 21:52

Думаю, всё достаточно банально.

Клиенту в счёт идут услуги всех специалистов как нужно: опытные девопсы, специалисты по безопасности, архитектор, техлид, отряды синьоров и горстка миддлов.
Когда вывешиваются вакансии на ДОУ и т.п. под проект, то есть вакансии максимум уровня синьора. Просто обязанности всех тех специализированных спецов — они перечисляются в вакансиях синьоров. И компенсация соответствующая — 4, максимум 4.5к месяц/чистыми, 48-54 к/год. Ведь это ОГРОМНЫЕ (!!) деньги для бедной Украины. :-) Даже в 2020+ году. А то, что в levels.fyi полная компенсация уровня аутсорсных миддлов+ в более-менее серьёзных продуктовых конторах по 130-180 тыс. в год минимум — этого такие дельцы вместе с их нищебродными клиентами предпочитают просто не замечать.

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 22.01.2021 22:48

Поздравляю, ты только что открыл бизнес-модель аутсорса

Andrew Frolov 22.01.2021 22:55

И это тоже. )
Мне кажется, к этой модели органично примешивается ещё тянущееся из совка презрение к профессии инженера. Типа кто он такой, за что ему платить такие деньги? А если уж платим на уровне 2-3 месячных аренд минимально приличного жилья — то требовать будем космос и вкалывать он должен за эти деньги ого-го!

Dmytro Lapshyn Chief Technology Officer в Telmie 23.01.2021 16:05

Потому что современное IT уходит от узкой специализации. Да, никто не ожидает от, скажем, senior back-end разработчика быть гуру также во front-end и в dev ops. Вместе с тем, иметь некий кругозор в этих областях и уметь решать несложные задачи — крайне ценно. И это не какие-то мифические персонажи, я таких ребят знаю среди коллег, и далеко не одного.

Как я понял, основной сыр-бор возник из-за того, что табличку из статьи многие восприняли как «senior должен знать всё из таблички на уровне senior», хотя, на самом деле, это просто уровни градации каждого навыка.

Alexander Merkulov asterisk guru 23.01.2021 16:12

А я вижу наоборот, что специализация все уже и уже.
Ну может на галерах это не так, но в мире именно специализация у всех.

Dmytro Lapshyn Chief Technology Officer в Telmie 23.01.2021 16:40

Понятие full-stack не галерами придумано. И, часто, full-stack — это именно хотелка заказчика.

Хотя бы, потому, что узкая специализация сильно усложняет планирование и повышает вероятность простоев.

Alexander Merkulov asterisk guru 23.01.2021 16:43

Количество специалистов full-stack сильно меньше всех остальных, в сотни раз гдето в обычном мире(не галерном).
и да, в теме вообще ни разу не написано про фулстэк.

Andrew Frolov 23.01.2021 18:44

И, часто, full-stack — это именно хотелка заказчика.

Вот-вот, заказчики-нищеброды. В моём понимании простого разработчика, любой заказчик-юрлицо, которое заказывает у внешнего подрядчика что-то сложнее веб-сайта-визитки или вебсайта для простейшего приёма заказов — это точно нищеброды. Потому как не могут позволить себе in-house разработку. Либо «эффективный» менеджер ради откатов и/или экономии выносит in-house-разработку в отдельное юрлицо с потогонкой и низкой компенсацией.

Меня как простого разработчика всегда интересовало. Если контора не может позволить себе in-house разработку на бесплатных/open-source инструментах — почему не купить и не внедрить то, что в 2000-х называлось тиражным коробочным продуктом? Или теперь модно ради откатов заказывать себе 10 000-й по счёту интернет-магазин, банковский опердень и т.п.?

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 24.01.2021 01:04

Не обязательно нищеброды. Тут может быть много вариантов. Начиная от временнЫх факторов, потому что быстро застаффить несколько сильных команд, если требуется, — задача не такая уж простая. Плюс, внутренняя разработка — это всегда намного более рискованно для бизнеса. Провалил аутсорс проект — просто не заплатили денег, или там оштрафовали за срыв сроков. С внутренней разработкой — ну уволятся команды, но это уже поздно, деньги уже ушли

Andrew Frolov 24.01.2021 11:30

Начиная от временнЫх факторов, потому что быстро застаффить несколько сильных команд, если требуется, — задача не такая уж простая.

А с чего это вдруг конторе нужно застаффить несколько сильных команд?? И как они без них раньше обходились? Я как простой разработчик полагаю, что контора вдруг нуждается сразу в большом кол-ве спецов только в одном случае. Когда контора получила/выделила финансирование на непрофильную деятельность, т.е. попросту «распил». Например, если какая-то крупная голливудская киностудия вдруг решила сделать убийцу Нетфликса, то им вдруг нужно застаффить десятки разработчиков. Т.е. это попытка заняться непрофильным бизнесом, в данном случае, разработкой ПО, продуктово-сервисным бизнесом. Если это основной бизнес, то команды растут естественным образом, есть репутация конторы, процессы и, соответственно, нет серьёзных кадровых проблем.

Плюс, внутренняя разработка — это всегда намного более рискованно для бизнеса.

Рисокванно только для непрофильного бизнеса. На самом деле, внутренняя разработка есть практически везде. Для этого не нужны гигантские команды из десятков специалистов. Какую-нибудь ERP в ТНК или крупной оптовой конторе поддерживают буквально несколько разработчиков на купленной платформе. Другое дело, что, конечно же, это узкоспециализированная, прикладная разработка с купленными лицензиями/подписками. А не неуклюжая писанина с абсолютного нуля на бесплатных/опен-сорс инструментах типа Java, MySQL ради экономии на корпоративных подписках.

А если кто-то, допустим, получил финансирование, поручает галере с разработчиками из бедных стран типа Украины разработать инновационный, рвущий конкурентов программный продукт по каким-то высокоуровневым спецификациям, надёрганным из PowerPoint-презентации — это, ИМХО, чистой воды мошенники, корпоративные инфоцыгане.

Если это аутстафф, т.е. технологическое ядро разработки полностью у заказчика — то это ок. Пусть хоть тысячами нанимают с Украины, РФ, Индии и самостоятельно, удалённо управляют разработкой и полностью несут риски за конечный результат. А если начинается «мы предоставляем специалистов с доменной, технологической экспертизой для заказчика», от вас только менеджер и/или контактное лицо, т.е. стандартный аутсорс — вот это, ИМХО, полное дно, с позиции разработчика.

Dmytro Lapshyn Chief Technology Officer в Telmie 24.01.2021 13:32

Вы, при этом, похоже, не учитываете, что нанять core команду на родине заказчика ни разу не проще, и, пока ещё, сильно дороже, если мы говорим о США.

Особенно, если это стартап в одном из штатов, где разработчики избалованы зарплатами уровня FAANG

Andrew Frolov 24.01.2021 14:39

Какая должна быть численность core-команды технологического стартапа? Лично я считаю, что в самом начале — это максимум 3-4 единомышленника-партнёра. Из того, что я достоверно знаю, в начале 2000-х, первый серьёзный коммерческий украинский Интернет-банк переделывали на Java, из российского прототипа, 2 (!) разработчика.
На Доу в топиках недавно отмечались, по всей видимости, действительно сильные технари, пробовавшие стартаперство. Хорошо, если бы они отписались, как оно в 2010-х было.

Как по мне, нанимать именно в прорывной технологический стартап, на ФОП-контракт в аутсорс, галерно-корпоративных разработчиков — это вообще нонсенс. Разве что все стороны осведомлены, что это «распил».

Особенно, если это стартап в одном из штатов, где разработчики избалованы зарплатами уровня FAANG

Штаты — это большая страна, не Сингапур, откуда нельзя уехать в локацию подешевле. Как по мне, делать с нуля программный продукт для рынка США и не иметь финансовой возможности заинтересовать на старте достаточно разработчиков в США — ну такое, «распил» или мечтательство мамкиных стартаперов. Все более-менее нужные, серьёзные продукты, их прототипы — делались как in-house разработка, в «гараже», индивидуальный проект.

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 24.01.2021 20:01

Так тогда уже определись, что имеется в виду. Технологический стартап, где главное — это идея и скорость в ущерб качеству, или рутинная разработка проекта для большой компании. Это принципиально различные вещи.

Ну и плюс расхожее мнение по гаражные продкукты несколько, хм, преувеличено. За каждым мальчиком-в-водолазочке всегда стоят невидимые серьезные дяди в костюмах

Andrew Frolov 24.01.2021 20:29

Согласен, есть проблема терминологии. В моём понимании, технологический стартап — это когда создаётся нечто принципиально новое, чего нет на рынке и что повлияло на потребительский и/или корпоративный рынок. Например, в своё время был таковым Скайп — бесплатные голосовые и видеозвонки, Youtube — видеохостинг, мобильные операционные системы конца 2000-х (взамен морально устаревшим десктоп-клонам типа Nokia Symbian).

А почитаешь многие галерные вакансии сейчас и раньше — облачная CRM/ERP для ветеринарных клиник, очередная CRM, очередной бэкенд для гэмблинга, очередное кастомное решение для электронной коммерции — это просто «распил», мамкино стартаперство, а не инновации.

Dmytro Lapshyn Chief Technology Officer в Telmie 25.01.2021 11:52

Ну вот, например, есть
www.clean.io

Разрабатывается командой из Sigma Software. В основателях — люди с большим опытом в AdTech бизнесе.

В вашей классификации — это «распил», или, всё-таки, инновации?

Andrew Frolov 25.01.2021 12:13

Это что-то узконишевое, корпоративное, если судить из лэндинга. Насколько я понял, продажа каких-то подписок на промежуточный инструментарий, который сам по себе не генерирует добавочной стоимости или снижения расходов. Во всяком случае, продать реальному кастомеру контракт с подпиской на подобный сервис на несколько лет — задачка ещё та. Потому как бизнес, который получает деньги от конечного потребителя, часто стремится минимизировать использование платных сервисов подобного типа.

Т.е. я, возможно, с позиции пессимизма, отнёс бы такой продукт/севрис к категории мамкиного стартаперства.

Dmytro Lapshyn Chief Technology Officer в Telmie 25.01.2021 14:32

Это борьба с вредоносным кодом в Веб-рекламе. Проблема действительно серьёзная, так как «подставиться» с каким-нибудь криптомайнером (а то и чем похуже) во встроенном в чужую Веб-страницу рекламном объявлении не хочется ни одному рекламодателю и ни одной бирже Интернет-рекламы.

Oleksandr Bereziuk Tech. Lead / Scrum Master в GlobalLogic 24.01.2021 20:16

Например, если какая-то крупная голливудская киностудия вдруг решила сделать убийцу Нетфликса, то им вдруг нужно застаффить десятки разработчиков. Т.е. это попытка заняться непрофильным бизнесом, в данном случае, разработкой ПО, продуктово-сервисным бизнесом

Любить — так королеву, проиграть — так миллион, так? Меньше Нетфликсов проектов в принципе не бывает? Например, есть сеть условных пиццерий, которые используют передовую по состоянию на 10 лет назад систему заказов, которая безнадежно устарела и требует замены. Или там гостиничная сеть. Или, любой в принципе %customer name%, бизнес которого не связан ИТ напрямую. Все что им надо — проект на 3-4-6 месяцев, который потом вряд ли будет активно обрастать новыми фичами.

Что делать в таком случае?