А ти точно senior?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да. И что?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Те що ось це

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

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

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

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

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

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

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

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

понятно.

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

всегда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Employers subject to the Fair Labor Standards Act ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

в Украине?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

або навіть Spring

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PostgreSQL 13 PL/pgSQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А как же

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

уже ответили

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот это

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

и вот это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Загуглить как рассчитывается наработка на отказ

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

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

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

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

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

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

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

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

ну да, ну да

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но вы зашли сразу «с козырей» :)
И дальше ничего удивительного -все по выбранной себе роли :)

Ну вот видите, всего пару моих фраз порождает текстовое недержание. Представляете что случится, если я, не приведи Ктулху, начну на открытые вопросы отвечать? ))

Вы ж повелись.

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

Представляете что случится, если я, не приведи Ктулху, начну на открытые вопросы отвечать?

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

Например вот из этой:
УН0. Оскорбления
Это низший уровень несогласия и, пожалуй, самый распространенный. Мы все видели комментарии вроде
«Вот же ты козлина!!!!!!»
Важно также осознавать, что более многословное оскорбление имеет такой же вес. Комментарий вроде
«Это написал дилетант с завышенной самооценкой»
— просто пафосный способ сказать «Вот же ты козлина!»
Пол Грэм. Как правильно возражать

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

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

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

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

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

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

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

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

Хорошо. Вот у вас есть условный проект. Ну, не знаю там, 10 модулей, 5000 строк кода, или 20 модулей и 20000 строк, не принципиально. Каким образом вы можете хотя бы очень примерно оценить качество кода? Желательно в измеримом виде, а не «я ревьювил, все Ок, отвечаю». Или эта информация тоже НЕ НУЖНА ?

P.S. Ну и без демагогии на тему «видел проект с хорошим покрытием, но внутри ужасный» — такие случаи тоже бывают. Но их много меньше обратных. Хотя бы потому, что при достаточном количестве нормально написанных юнит тестов, стуктура проекта скорее всего будет более-менее вменяемой, с минимумом функций с запредельной цикломатической сложностью и гвоздями прибитых зависимостей. Иначе написать нормальные тесты либо очень трудозатратно, либо просто невозможно. Вот именно это и есть главный плюс, а не абстрактное число в 63.5% на выходе

Первый раз слышу о таком правиле.

Это было от Д. фон Неймана

Это просто переворот в теории надежности.

фон Нейман да, кретин.

Каким образом вы можете хотя бы очень примерно оценить качество кода?

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

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

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

Увлечение метриками — анализом кругов на воде — это ж и есть работа менеджера :)

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

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

Их-то снесут первыми, чтобы не мешали

...случай знаю. недавно общался с приятелем в реале. джавистом.
он в компании имеющей свой внутренний продукт. Компания с США, система на Джаве, что-то там с домами, арендами. федерального уровня кажется.
Давно написана.
спросил для порядку о тестах. Не, смеется, нету. Были, и сейчас болтаются. но поломаны давно, и никто и не пытается их чинить.
А зачем? бизнес стабильно и неспеша растет. Фичи не спеша и аккуратно добавляем. как и баги — находим, и фиксаем.
— и тестировщики проверяют?, спрашиваю я
— не, отдел тестирования у нас есть, но он толком не знаю чем занимается. сами все и тестим. проджекты — американцы в основном.
все всех устраивает.

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

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

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

свой внутренний продукт.

что-то там с домами, арендами

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

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

да, очень часто бывает.

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

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

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

Ты им не объяснишь :(

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

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

Беда только в том, что этот подход плохо (если вообще) масштабируется.

Хочешь написать тест, способный работать на боевой базе

Что есть «боевая» в данном контексте? Потому как присутствие в одном предложении слов «тест» и «боевая» несколько смущает

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

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

Часто это руками, но для процессов с серьёзной нагрузкой и вовлечением людей для этого нужны ПРОЦЕДУРЫ

Совершенно верно.

В случае АВРАЛА так и делают. Разумеется, с косяками.

В результате — хрестоматийный пример — кто-то пытается максимально быстро что-то пофиксить, в нервной обстановке аврала, пишет UPDATE ... WHERE с опечаткой в условии. Или передает некорректный параметр в хранимку. И просто проблема превращается в большую проблему.

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

при том что все логические неувязки придется разруливать простому программисту, когда начинает:
if (

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

Т.к. не кодерское это (как правило) дело — спецификации писать/самостоятельно изменять.

золотые слова!

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

Само наличие хранимых процедур — это баг кода.

мнение кодеров конечно нужно учитывать.

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

это да, на доу мы детсадовцы в меньшинстве

как и в жизни :)

В сложных системах — кодерки не в курсе всех деталей реализации системы

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

но это от них и не требуется,

да, естественно.
так и выстраивалась разработка.

Да, если ты пишешъ программу, уровня сложности «показать 3 формы пхп»

не знаю, не писал
но видел, да. обычно это вебремесленники с фриланс биржи

ты сам и закодишь, и спецификацию составишь

воооот тут уже интереснее, и писал уже в этой теме :)

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

Примерно тем же занимаются бизнес-аналитики — в области софта для финансов/банков.

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

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

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

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

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

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

тесты тебе не нужны

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

с кодерка — требуют. ну, так всегда ж
it depends

Кодер решает в том, что касается кодирования.

да и то, правила для линтера, код стайл обычно не он пишет :)

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

бывает и так. от дизайна системы зависит, компетенций, самих задач.

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

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

и так бывает.
it depends

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

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

вам вот с другой стороны монитора видать о моем текущем проекте куда больше! даже того что я не вижу :D

А у нас всё работает и «зелёное»...

да, верю, у вас багов на проде не бывает.
потому что юнит-тесты проходят

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

Ну, то есть, мы говорим о подходах к разработке в каком-то гараже, в котором о code review и pull request’ах никогда не слышали? Если так, то я на этом моменте откланяюсь, поскольку обсуждать такое неинтересно.

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

«Ой, всё!» ©
Авторы domain-driven design нервно курят в сторонке, слушая речи непризнанного гения.

Слушай, ну скажи, пожалуйста, где ты увидел в моих словах хоть намёк на бюрократию? Или ты называешь оной code review и pull request’ы? Я без всякого троллинга сейчас, хочу просто «карты мира» согласовать.

DDD — тоже ни разу не бюрократия, это же вообще не про процессы.

нанимаются исполнители, работающие «без возражений».

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

Обычно, всё же, между такими исполнителями и теми, кто давит сверху, есть ПМ / тим лид / архитектор. А на такие роли (особенно, две последние) обычно не нанимают исполнителей, работающих «без возражений», разве нет?

Ну, или мне повезло работать в компаниях, где на такие роли не нанимают yes-man’ов.

не твоя обязанность разгребать последствия.

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

мне повезло работать в компаниях, где на такие роли не нанимают yes-man’ов.

Я, чесно кажучи, саме через це тільки віднедавна «видихнув» і став писати більш-менш розслаблено, а до того з самого 2008 (коли я тут зарегався) чекав якихось ударів з-за рогу. Ну і раз чи два то навіть притягнуло анонімного «доброзичливця»...

Та б’ють по якихось слабких місцях у кар’єрі, для цього достатньо щось десь про це чути.

Розумію, але я саме про ДОУ. З кодом у мене все добре.

І що? Ну от дізналися чи знає людина про це чи їй доведеться колись 20 секунд витрати щоб дізнатися. А як визначити чи підходить вона компанії/проекту?

Это азы «плюсов». Уровень даже не миддла, а начитанного джуна.

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

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

а раніше би провалив інтерв«ю на сінйора :)

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

ЗЫ: на самом деле вопросов за виртуальный декструктор и вообще виртуальные функции более чем достаточно для понимания есть ли понимание или же ж есть просто заученное по методичке а реальной практики разбирательства 0.0

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

Для мене ці питання про якісь нюанси наче ми на іспиті на 3-му курсі виглядають дивно — людина потрібна як довідник з С++, чи може щоб робити щось осмислене все ж таки?

Как по мне тут тонкий лед. С одной стороны вопросы типа «порядок, тип и количество аргументов, передаваемый в условный strcpy?» попахивают идиотизмом. С другой стороны — незнание о существовании виртуальных деструкторов может привести к тому, что софт потечет памятью. Потому что при таких раскладах можно договориться до «человеку не обязательно знать, что нужно удалять память после выделения в системах без garbage collector.» Ну или «человеку не обязательно инициализировать переменные»

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

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

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

Ну ще скажи що Пітон не Пітон бо усе публічне

self.__priv = «Hello»
А вот protected как в плюсах там реально не хватает

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

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

В С нет деструкторов и сборки мусора. Деструкторы только к С++ завезли, и это была киллер-фича — остальное спокойно делалось (и делается до сих пор) ручками в С.

Впрочем, полиморфизм тоже реализуется на «си» — но сложно.

не не сложно просто берёшь таблицу «методов» и всё

почти весь линукс так и построен а скажем «файловый дескриптор» или handle в win32 api суть есть всё та же ж «абстракция системного полиморфизма на прикладном уровне»

По-моему, это очевидный подход, на уровне «виртального деструктора» для С++ джунов.

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

А чем тут foo->functions->put(foo, x, y) хуже, чем foo->put(foo, x, y)? Или вы о чём-то другом?

Наприклад ці таблиці можна динамічно модифікувати і тоді простим читанням коду буде дуже складно відстежити які самі методи викликають.

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

ну да але те саме працює і для будь якого «класичного ооп поліморфізму»

Отсеять дурачков которые вписали себе в тайтл — Senior, а по факту сыпятся на глупейших вопросах

А якщо цей сеньйор писав в останнє на С++ 15 років тому і може перевернути список за пару хвилин?

А это я узнаю на сессиях с open-ended questions, которых у меня с продакшена за пару лет накопилось вагон и маленькая тележка

Тоді чому одразу не почати з цих питань?

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

О, у нас физик такой был, которому весь поток в конце каждого семестра вставал и аплодировал (в буквальном смысле, из года в год).
На экзамене был лимит кажись на 5-10 минут на использование литературы. Типа если знаешь где искать, то найдешь и воспользуешься. А если весь семестр клал на учебу — то и не будешь знать куда смотреть.

Віртуальні конструктори були на Дельфі

В чому сенс їх задавати? Можна ще про кольори веселки спитати.

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

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

Он самый

Ну и это ж само собой «минимум» — то есть на джуна гдето.......

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

З іншої сторони ... чим відрізняється досвід зрілого розробника 1 рік технології Х від 5 років? Як на мене, той що 5 років працює буде знати ну від сили на 15-20% більше і то далеко не факт.

Винятки з попереднього є (в основному науковомісткі, чи мож hardware близькі), але точно не у вебі.

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