Плюсы работы на enterprise проектах?

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

Для меня минусами были:
— Огромная бюрократия куча менеджеров на стороне галеры и куча менеджеров на стороне клиента и необходимость любой чих согласовывать с ними, бесконечные бестолковые митинги (даже были такие моменты, что решение вопроса занимало 15 минут максимум, а обсуждалось это 10 человечками 3 часа).
— Нереально раздутый штат разработчиков, там где спокойно могут работать два сеньора и один джун, по факту было 2 сеньора, 5 мидлов и 5 джунов, как следствие необходимость в митингах чтоб согласовать каждый чих со всеми остальными, дичайшие мерж конфликты и куча бесполезной работы.
— Зацикленность на процессах, типа пулл реквест может быть смерджин если его заревьювит тех лиад со стороны клиента, и в итоге ПРы неделями весят, так ТЛ все время на митингах. Попытки везде, впихнуть скрам. Абсурдные ситуации когда оценку сторей проводят в часах, причем сеньоры и джуны одновременно
— Отсутствие как токового технического роста, и интересных задач, все однотипное.

Были и плюсы:
— Можно было неделями нечего не делать и ни у кого вопросов не возникало. Главное на митингах набрасывать тем для обсуждения.

А какие у вас плюсы и минусы крупных проектов?

👍НравитсяПонравилось0
В избранноеВ избранном2
LinkedIn

Лучшие комментарии пропустить

А какие у вас плюсы

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

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

Допустим, стоит задача хранить вводимую юзером строчечку в бд (заведомо упрощаем).
Как думает типичный 23 летний синьор в модном стартапе iRoga-&-MacKopita:
1) CREATE TABLE strings (s varchar, long id, PK id AUTOINCREMENT)
1) PUT /strings/{s} —> INSERT s INTO strings;
2) Ясделаль! Затобыстра! Работаетжи!
3) Что нужно еще? Удаление? Пффф DELETE /strings/{s} —> DELETE FROM strings WHERE s=? Ясделаль!

Как думает разработчик, прохававший кровавый ентерпрайз:
1) предпосылки необходимости хранения данных:
— какую задачу решает данное хранение? — дает ответ на вопрос — какие смежные задачи могут быть в будущем интегрированы с данным функционалом.
— что в реальности представляют собой данные строки? — дает ответ на вопрос — какие структуры данных могут быть извлечены из данных строк? Даты? Логин-пасы? Названия продуктов? Могут ли данные строки хранится в не-строчном виде для облегчения анализа? Как они будут анализироваться? Обработка дублирования — запрет / схлопывание дубликтов / явное хранение дубликатов?
2) интерполяция этих данных с данными в других системах. Возможная необходимость применять какието MDM-подходы для очистки / дополнения записей.
3) вопросы связанные с непосредственным хранением — длительность хранения, активность записей, архивация / удаление старых записей, авторство записей, возможность редактирования.
4) продумываются права на проведение тех или иных действий
В результате создается структура, слегка отличная от первого варианта:
CREATE TABLE strings (
uuid BINARY,
s VARCHAR NOTNULL,
created TIMESTAMP NOTNULL,
lastModification_uuid BINARY,
validFrom TIMESTAMP NOTNULL,
validTo TIMESTAMP NOTNULL,
isActive BOOLEAN NOTNULL,
creator_uuid BINARY NOTNULL,
PK uuid)

CREATE TABLE stringsModification (
uuid BINARY,
s_old VARCHAR NOTNULL,
s_new VARCHAR NOTNULL,
lastModified TIMESTAMP NOTNULL,
modifier_uuid BINARY NOTNULL,
PK uuid)
Думаю дальше понятно.

Далее в самом коде создаются заглушки под всевозможные интеграции, листнеры и возможность добавления сайд эффектов для реагирования на ивенты создания/модификации/др. На выходе получается обдуманная, предсказуемая, консистентная взрослая система, которая легко интегрируется с чем угодно, легко поддерживается и легко расширяется. Для построения таких систем придумали концепции разного уровня — DDD как верхний уровень, EIP как средний уровень и OOP как нижний уровень реализации. Все это и есть ентерпрайз. В этот момент 23 летний синьор из iRoga-&-MacKopita поперхнулся смузи и принялся взахлеб рассказывать что это все ненужное дно, что он только что написал монады на новейшем функциональном яп и что его сервер на ноджс стартует за 0.01 наносекунду и что это все что нужно клиентам.

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

дичайшие мерж конфликты

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

по факту было 2 сеньора, 5 мидлов и 5 джунов

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

А

два сеньора и один джун

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

даже были такие моменты, что решение вопроса занимало 15 минут максимум, а обсуждалось это 10 человечками 3 часа

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

Плюсы
— адекватное планирование и релизы
— CI/CD процесс настроен и налажен
— миф о том, что в энтерпрайзе лютое легаси, или устаревшие технологии лишь наполовину правда (зависит от проекта и менеджмента), а так, если технология подходит под задачу — proof of concept и поехали использовать в бою
— стабильная зп и бонусы, а не «ну вот короч, скоро выйдем на нный раунд инвестиций и тогда заживем»

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

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

— хороший коллектив
— стабильность проекта
— зп на уровне рынка
— - если зп не повышают, то пусть хотя бы индексируют
— овертаймы — лютейшее исключение
— 2/3, а то и 3/4 задач делается спинным мозгом, вследствии чего домой можно пойти не через 8 часов, а через 6
— даже если через 8, то тогда половина рабочего дня уходит на гонку чаев, сидение в интернетах, всякие спортивные активности. В особо вопиющих случаях и при наличии двух мониторов — в одном ИДЕшка, в другом какой-нибудь фильм крутится.
— нету черного/белого списка сайтов

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

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

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

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

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

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

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

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

потом привыкли

Бульбу навчилися ростити?

У вас она какая-то особенная?

На Марсе же получилось)

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

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

В основ Энтерпрайз Клауд и покупает — даёт на откуп управление своими датацентрами , не будучи компаниями айти профиля — стандарты все в Клауд можно имплементирован аналогично он прему. Таких кейсов немеряно в финансах, консалтинге, логистике и транспорте, промышленности — где угодно
aws.amazon.com/solutions/case-studies
azure.microsoft.com/en-us/case-studies

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

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

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

Напевно, з цього і треба починати, правда? Ви намагаєтеся мене переконати простою логікою. Гаразд. Порахуйте самі: є проект, який витрачає 1 млн баксів на рік в клауді. Залізяк на цей 1 мільйон буде стільки, як треба в клауді для реалізації цього проекту (перевірте, в мене виходило +/- так). Помножте на 5 — стільки років має працювати в середньому залізяка. ВІдповідно, за 5 років ви сплатите 5 млн на клауд. Отакої. Вартість інженерів на 1 рік супроводу заліза: 2 тушки рівня системний адміністратор з досвідом 3+ років роботи. В США таке добро коштує від 60 тис., в ЕС дешевше, в Індії ще дешевше. Клауд-інженери коштують дорожче, бо вони ближче до девелоперів, Депопси ще дорожче, бо це і є девелопери :) Так де Ви побачили дешевше? Я не бачу. Зручно, швидко, функціонально — так, але не дешево.

Что-то много разных домыслов, все комментить лениво, но возьми средненькую VM в cloud за $80/мес. Год это порядка $1k. При этом ты не знаешь нужна она тебе будет через год или нет. Ежику понятно, что свое железо в стабильном бизнесе в долгосрочной перспективе дешевле. А что если нужны, например машины с GPU для ML, при чем потребность в них может варьироваться от 10 до 300 машин в на конкретный час. Держать в парке 300 машин, которые буду большую часть времени простаивать? Так тоже дешевле получится? Глупый какой-то аргумент, что свое железо всегда дешевле. Нужно иходить из задачи, имеющихся ресурсов и ожидаемого роста.

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

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

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

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

Все это автоматизируется и тем более не имеет никакого отношения к тому, что политики на создание веток или любые другие моменты в разработке проще организовать в прем чем в Клауд.
Вот хорошая статья по поводу банков в облаке
www.google.com/...​yes-banks-do-use-aws/amp

Если ей верить J.P. Morgan вообще процессинг делает в облаке — то что у вас выше описано как требование уровня физической безопасности, крупнейшая банковская группа делает в облаке.

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

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

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

Розкажіть, будь ласка, як організувати періметр в клауді з логуванням всього, що було взято і покладено в клауд :) (цю задачу вирішує наш мережевий департамент разом із Майкрософт вже який місяць поспіль)

А как вы это делаете в онпрем?

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

Как писали ниже, cloud, on-premise, какая в yaml разница. Развернул k8s и разработчику пофик куда оно будет деплоиться (в каком-то приближении).

Code-review же никто не отменял 🙂.

Это если не уметь в условия выхода 🙂.

скорее тесты с деплоем на staging

да какой угодно, если не прод) если в yaml накосячили, деплой свалится

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

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

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

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

Ну да, зеленое становится теплым, я мягкое начинает пахнуть ландышем. Ох...

Що таке ентерпрайз?

Тут проговорили dou.ua/...​rums/topic/29254/#1741286. Бизнес, скорее большой, скорее B2B.

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

С точки зрения работника продуктовой компании — это когда он работает над тем что называется Enterprise solution — софт обеспечивающий внутренние процессы работы корпораций. Я делал такой софт внутри компании из 10 человек, но нашими основными клиентами была именно корпорации от 100 человек пользователей.

Тоді з т. з. співробітника продуктової, у нас — це ентерпрайз, але без перерахованих топік-стартером плюсів-мінусів від яких тхне тупо галерою. Основана відмінність від звичайної(?) контори — це розуміння того, що будь-яка бага, нехай і маловірогідна, якщо потрапить у реліз, то обов’язково у когось вилізе через закон великих чисел. І якщо не буде воркераунда, то це не просто роздратує якогось Васю, а стопорне комусь бізнес з усіма з того наслідками, зважаючи, що працювати доводиться на висококонкурентному ринку.

зажрались наши кодеры.

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

что еще нужно чтобы достойно встретить старость?

А какие у вас плюсы

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

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

Допустим, стоит задача хранить вводимую юзером строчечку в бд (заведомо упрощаем).
Как думает типичный 23 летний синьор в модном стартапе iRoga-&-MacKopita:
1) CREATE TABLE strings (s varchar, long id, PK id AUTOINCREMENT)
1) PUT /strings/{s} —> INSERT s INTO strings;
2) Ясделаль! Затобыстра! Работаетжи!
3) Что нужно еще? Удаление? Пффф DELETE /strings/{s} —> DELETE FROM strings WHERE s=? Ясделаль!

Как думает разработчик, прохававший кровавый ентерпрайз:
1) предпосылки необходимости хранения данных:
— какую задачу решает данное хранение? — дает ответ на вопрос — какие смежные задачи могут быть в будущем интегрированы с данным функционалом.
— что в реальности представляют собой данные строки? — дает ответ на вопрос — какие структуры данных могут быть извлечены из данных строк? Даты? Логин-пасы? Названия продуктов? Могут ли данные строки хранится в не-строчном виде для облегчения анализа? Как они будут анализироваться? Обработка дублирования — запрет / схлопывание дубликтов / явное хранение дубликатов?
2) интерполяция этих данных с данными в других системах. Возможная необходимость применять какието MDM-подходы для очистки / дополнения записей.
3) вопросы связанные с непосредственным хранением — длительность хранения, активность записей, архивация / удаление старых записей, авторство записей, возможность редактирования.
4) продумываются права на проведение тех или иных действий
В результате создается структура, слегка отличная от первого варианта:
CREATE TABLE strings (
uuid BINARY,
s VARCHAR NOTNULL,
created TIMESTAMP NOTNULL,
lastModification_uuid BINARY,
validFrom TIMESTAMP NOTNULL,
validTo TIMESTAMP NOTNULL,
isActive BOOLEAN NOTNULL,
creator_uuid BINARY NOTNULL,
PK uuid)

CREATE TABLE stringsModification (
uuid BINARY,
s_old VARCHAR NOTNULL,
s_new VARCHAR NOTNULL,
lastModified TIMESTAMP NOTNULL,
modifier_uuid BINARY NOTNULL,
PK uuid)
Думаю дальше понятно.

Далее в самом коде создаются заглушки под всевозможные интеграции, листнеры и возможность добавления сайд эффектов для реагирования на ивенты создания/модификации/др. На выходе получается обдуманная, предсказуемая, консистентная взрослая система, которая легко интегрируется с чем угодно, легко поддерживается и легко расширяется. Для построения таких систем придумали концепции разного уровня — DDD как верхний уровень, EIP как средний уровень и OOP как нижний уровень реализации. Все это и есть ентерпрайз. В этот момент 23 летний синьор из iRoga-&-MacKopita поперхнулся смузи и принялся взахлеб рассказывать что это все ненужное дно, что он только что написал монады на новейшем функциональном яп и что его сервер на ноджс стартует за 0.01 наносекунду и что это все что нужно клиентам.

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

дичайшие мерж конфликты

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

по факту было 2 сеньора, 5 мидлов и 5 джунов

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

А

два сеньора и один джун

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

даже были такие моменты, что решение вопроса занимало 15 минут максимум, а обсуждалось это 10 человечками 3 часа

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

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

Типовий кривавий YAGNI. Так і родяться криваві ентрерпрайзи, у яких мільйони опцій в конфігу, ледве не на кожний if, ще пару сот тисяч різних шарів абстракцій, ієрархії сервісів з десятками абстрактних конверторів фабрик. Хоча проект то міг би бути простий, надійний і приємний для розробки. А так ніхто не знає нащо оці непотрібні навороти були зроблені, як ними користуватися теж ніхто не знає, видалити ніхто не наважується.
Гарний приклад того, як писати не треба і чому наша індустрія скотилася в канаву. Сучасні 23-х річні сіньйори роблять все те саме, тільки піднялися на новий рівень. Вони, тепер, закладують на майбутнє не таблички а цілі інфраструктурні куски, типу кубернетесів в хелоуворлдних проектах.

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

Ну аналіз різний буває. Так то я згідний, звісно, спочатку треба проаналізувати задачу.

Так то я згідний, звісно, спочатку треба проаналізувати задачу.

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

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

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

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

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

Скажем так, есть некий конечный результат, который нужен.
«Сделать правильно» = 1 работа на 2 недели, скажем.
«Сделать минимально» = 10 работ по 1-2 дня.
При примерной соизмеримости конечного результата + стоимости:
— в первом случае ты типа нарушаешь ягни
— во втором случае ты получаешь не целостный компонент, а маленького карманного питомца франкенштейна, состоящего из центрального функционала, обклеенного фиксами, костылями и скотчем.

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

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

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

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

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

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

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

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

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

Я другой пример обычно

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

Бытенько делаем поле у сущности — и уменьшаем, увеличиваем, да и все
1. через время работы в продакшене:
надо добавить функционал который добавляет какой-то бонус за активность.
то есть на сейчас итог 0, но каждый день +1000, −1000 в день
ну и отчетик нам, для инвестора, как у нас по периодам накапливалось-уменьша
2. ой, нужно отменить изменения итога, которые были сделаны в определенный период времени,
3. ...но не все, а сделанные по таким-то условиям.
4. а позавчера — сколько было?

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

Я уже джва года жду такую игру

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

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

Принцип-то при чем? Он не виноват что им оправдывали говнокод, на его месте мог быть каждый :)

Сам принцип может и не причем.
Ссылка на него у меня ассоциируется вот с тем что я написал

если бы YAGNI-девелопер делал не «просто» а «хорошо»

Вот где та грань между «хорошо» и тем, что называется over-engineering?..

Грань субъективна и тонка, согласен.

YAGNI о том, чтобы принимать архитектурные решения как можно позже, когда ты уже точно знаешь требования

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

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

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

Если вам надо вывести Hello world!
YAGNI — ну так выведите
Обобщенно: разложите фразу на символы, напишите способ задания символов, напишите функцию, которая выводит буквы.

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

«Можно ли процедурами работы заменить компетентность персонала?»

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

YAGNI точно то что нужно если
— проект явно будет закрыт после непродолжительного старта в продакшене по бизнес причинам — «попил бюджета, бреды маркетологов, ...»
— у проекта ресурсов ощутимо меньше типичных для такой сложности проектов: — «наймем с пяток фрилансеров — они нам запилят фейсбук. Для начала — на Wordpress’е»
— никто на проекте понятия не имеет как раскладывать «Hello world» на символы: «уникальность проекта, нет проверенных методологий анализа предметной области»

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

Наверное, соглашусь в плане бизнес-логики, и то, только применительно к enterprise — в стартапах это правило не работает от слова «никогда».

Но вот закладывать гибкость вида «а вот тут мы добавим слой абстракции от базы данных, потому что вдруг через пять лет клиент захочет перейти с MS SQL на Oracle» — это ИМХО именно то, что должно отсекаться бритвой YAGNI

в стартапах это правило не работает от слова «никогда».

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

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

Но вот закладывать гибкость вида

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

добавим слой абстракции

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

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

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

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

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

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

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

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

Дешевизна не означает «из говна и палок»
Дешевое может быть как добротным, так и хлипким.

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

шансом на выживание

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

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

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

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

когда смогли показать инвесторам:
смотрите, у нас уже «100 000» активных пользователей, использующих сайт больше полугода

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

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

MVP пользователям и даром не нужен.
А инвесторам нужна уверенность что проект кому-то реально нужен.
Мало того, инвесторы еще и техническую экспертизу проведут, и все эти говно и палки вскроются.

так что байки это все, про инвесторов которые одаривают десятками миллионов баксов «MVP из говна и палок»

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

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

не MVP, картинку они уже видели на презентации.

Кагбэ, обычное бранчевание с переделкой движка. На старом движке неспеша выкатываются фичи, пока пилится новый движок. Потом копируется трафик из прода на новую имплементацию, она фиксится. Потом переключают 1% юзеров, потом 5%, потом — 100%, и старый движок убирают. Я это должен шефу описывать?

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

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

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

я вот с детьми занимаюсь, у них на старте именно такая уверенность
если что не знаю — на ютьюбе посмотрю и буду знать!

На старом движке неспеша выкатываются фичи, пока пилится новый движок.

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

и какое еще не спеша? это стартап а не ТНК, срок неделя, уже как-то долго. «Уже три дня ничего нового на сайте!!! Где постоянная выкатка фич??»

Я это должен шефу описывать?

у инвестора свои эксперты есть. ему ничего описывать не надо:
«Вот мои SEOшники, они вам предоставят метрики для установки на фронтенд»
«А вот мой эксперт по бекенду. Предоставьте ему доступ к репозиторию кода. Только реальному, там где вся история комитов за последний год видна.»
(у нас уже дважды была, пока, фух, эксперты говорят что код и проектные решения — вполне годные)

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

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

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

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

Если Вы заполучили инвестора, который лезет в технические детали и рассказывает программистам, как им программировать — Вам либо в недавнюю статью о ПМах, либо сюда en.wikipedia.org/...​l_and_business_operations

Так суть же в том, чтобы забить на багфикс

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

раскрути потом — второй раз тот же проект :)

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

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

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

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

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

В этом и суть MVP.

MVP — это для первой встречи.
а не когда проект в проде.

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

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

Еще раз — байки все это про то что инвесторы просто ведутся на презенташки и MVP

Вам либо в недавнюю статью о ПМах ... либо сюда

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

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

Вам может стоит коучем каким стать, по наставлению стартапов? ;)

MVP

== Minimal Viable Product == is a version of a product with just enough features to satisfy early customers and provide feedback for future product development.
Это должно быть рабочей штукой, а не „для встречи”

ну, вам конечно видней, что должно быть
у вас какие-то скрижали от Бога том что должно быть :)

а ну да.

и ютьб не нужен. прочел википедию — и эксперт в вопросе :)

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

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

Как правило, в реальности происходит один или более резких разворотов в направлении дальнейшего развития продукта (pivoting), в результате которых решение либо очень сильно переделывается, либо вообще выбрасывается и делается новое.

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

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

это именно то, что нужно рынку.

если нет аналогов.
а если есть аналоги — то нужность рынку уже проверена.

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

а капитальное сооружение и не нужно.

потому что ПО — это вообще не сооружение.

У нас достаточно много стартапов среди клиентов

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

а если не понимать что:

в реальности происходит один или более резких разворотов в направлении дальнейшего развития продукта (pivoting), в результате которых решение либо очень сильно переделывается, либо вообще выбрасывается и делается новое.

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

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

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

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

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

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

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

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

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

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

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

они описаны у многих, я ж не гений :)

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

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

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

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

как в шутке «цифровые стихи»
138 5 15
12 8 45
17 19 20
4 225

смысла никакого, а как вписывать понятно

ну или Гло́кая ку́здра ште́ко будлану́ла бо́кра и курдя́чит бокрёнка

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

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

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

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

ниче не понял.
just another layer of indirection — общеизвестно но плохо.
эзотерика — хорошо, но о ней никто не знает, и ее нельзя описать словами..

о ней знают и используют. называют просто по разному.
или считают очевидным и ествественным делом.

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

ниче не понял.

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

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

Я вот тоже ничего не понял.
Если честно — похоже на речь О. Бендера (зиганул) про нью васюки.

Есть конкретные примеры?

Есть конкретные примеры?

полно.
Самый яркий из этого семейства подходов, хоть и не ставший мейнстримом
DSL

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

Если честно — похоже на речь О. Бендера (зиганул) про нью васюки

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

подробности еже есть во тьме книг на сотни страниц.
Начиная с первой прочитанной многой толстой книге — 1го издания Гради Буча.

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

и может даже не gaperton’ом:
Архитектура програмного продукта это не инженерная конструкция, а свод правил описания системы, причем нередко еще и не описанных нигде, и немножко — правил по описанию домена

а у vit-rа было как-то, резкий он товарищ,

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

Не сваріться. Буває і так, і так, і зовсім по-іншому. І інвесторів, і клієнтів, і партнерів доводиться переконувати в речах зовсім очевидних. Більшість з них адекватні люди. Але не всі, і не завжди. А деколи переконуєшся сам в тому, що розумів не все. Стартап вбирає кумулятивна неадекватність. І страх, і жадібність, як завжди. Відсутність стратегії. І недооцінка ризиків і технічні проблеми також — от Боїнг ніби і не стартап, а як вляпався, і інших за собою потягнув. Та й інші причетні.

И это то, чем ентерпрайз как раз и учит, имхо.

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

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

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

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

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

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

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

безинициативным исполнителем с как можно меньшей ответственностью и вовлеченностью.

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

через призму своего опыта.

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

через призму своего опыта.

всего делов то

это бывает я проверял ))

Вы же понимаете, что это неправильно.

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

если сделаешь более правильнее и лучше, выйдя за рамки ТЗ,

Ещё один ИМХО важный и очень тонкий момент. Выход за рамки ТЗ оправдан тогда, когда ты с высоты накопленного опыта можешь с достаточной точностью предугадать, что в проекте в такой-то предметной области и вот с такой-то спецификой понадобятся a), b) и c).

В таком случае, я бы не считал это нарушением принципов YAGNI, потому что предварительно заложиться на поддержку этих самых a), b) и c) — это разумная инвестиция, которая подкреплена предыдущим практическим опытом.

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

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

Вот, это именно то, что я хотел сказать.
Сказал, значит, изначально неудачно.

YAGNI же, как мне кажется, призван бороться с «архитектурными астронавтами»

тут да, согласен.

у меня он звучит так
При анализе задачи —
шаг 1: попробуй добавить +1 уровень абстракции сверху и снизу. Если какой-то лишний, не добавляй его. может оба лишние, но главное — подумай, попробуй, а не сразу пиши лобовое решение.
шаг 2: Задумался о +2 уровня? либо: перечитай о чем YAGNI, либо займись полным описанием требований, дополнительным выяснениями, ищи бизнес-аналитике в себе или вовне, .... потому что
+2 и больше уровня абстракций — должны иметь четкие формальные обоснования.

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

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

Типовий кривавий YAGNI

Я вообще не согласен с YAGNI. Вернее не полностью согласен. Если грамотно собрать требования, то вполне можно определить, что не понадобится совсем, а что понадобится завтра точно, но не выставлено в тз.

+ есть ряд нюансов, которые в типичном энтерпрайзе нужны ВООБЩЕ ВСЕГДА — софт делит и возможность восстановления «удаленных» данных, трекинг всех действий кем/когда/почему сделано, временные ограничения от-до на большинство бизнес-сущностей и моделей, получение данных по разным полям, пагинация. То, что будет нужно в 99,99% даже если тебе сказали просто сохранить строчечку в базу.

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

Хоча проект то міг би бути простий, надійний і приємний для розробки.
Как думает типичный 23 летний синьор в модном стартапе iRoga-&-MacKopita
agile bigdata cloud docker kubernetes buzzword engineer

:)

А так ніхто не знає нащо

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

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

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

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

Господа, підійміть руку хто таке бачив? Працював від шараг до топових компаній і жодного разу таке не бачив. Максимум це якісь вікі з howto в дусі як обновити компонент А, якісь спеки по черговим вундерфічам. Все це, звісно, ніяк не систематизоване — просто набір веб-сторінок. Ні разу не схоже на мануал по ремонту Жигулі, в якому легко знайти потрібний вузол і марку масла яке у ньому бігає.

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

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

Зробити просто, а потім ліпити спагеті з підпорками у виді хот фіксів? Якщо завдання складне то і робити тре відповідно. А не будувати залізничний міст по технології собачої будки.

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

Та да. Міст на юзерах не потестуєш...

Це та провокація беніних чи кого там коли молотами побили скло?

там коли молотами побили скло

А звідки інформація? Бо сам Віталік казав що з автомата стріляли ))

А не будувати залізничний міст по технології собачої будки.

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

Fifa от EA Games, если ты понимаешь о чем я)))

Зробити просто, а потім ліпити спагеті з підпорками у виді хот фіксів?

Ну походу треда видно, что таки большинству импонирует этот подход.

Перекручування. Мова не йде про підпірки. Мова йде про простоту, як одну з головних якостей програми. Як казав (ну майже так) Блох, просту програму легше адаптувати ніж складну. Криваві ентерпрайзи типовий приклад того, що костилі та пластилінова архітектура значно частіше трапляється у вашому таборі.
Практично всі класики (починаючи від Дейкстри та МІТ-хакерів і закінчуючи сучасними «молодими» представниками) завжди твердили що простота є все, що це головна задача розробника — боротися із зайвою складністю. Я от тільки в Java-таборі підхід «чим складніше тим крутіше» зустрічав. Ну ще JS на це дуже схоже, але то особлива каста.

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

Иногда это единственный вариант изменения и поддержки, который помещается в выделяемые клиентом бюджеты и сроки. Вам очень повезло, если вам никогда не встречались клиенты вида «Рефакторить? Переписать?! Вы что, с ума сошли??? Нужна новая фича, на вчера! А то, что будут костыли и подпорки, так это меня не волнует».

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

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

А противоречие в том, что «растить нового жеребенка» это не про

Бизнес приносит деньги сейчас и срочно, а не через 10 лет, когда вы все порефакторите. Более того, то, что продается сегодня может перестать продаваться завтра.
никогда не встречались клиенты вида "Рефакторить? Переписать?! Вы что, с ума сошли??? Нужна новая фича, на вчера!

С такими проще не работать.

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

непонятно при чем тут энтерпрайз

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

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

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

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

Есть понятия SMB — small-medium business. Существуют разные интерпретации критериев этого понятия, но условно это небольшие бизнесы, для которых есть определенная специфика покупки-продажи, поддержки и все остальное. Условно говоря, если вы делаете программный продукт для такой аудитории, то основной тип продаж — это человек на стороне бизнеса нагуглил ваше решение, увидел в рекламе или услышал от знакомых, зашел к вам на сайт, ввел кредитку и купил.

Есть понятие SME — small-medium enterprise — там уже работает более 100 людей, обороты больше, уже есть юристы в компании, они будут с вами составлять договор, и покупка будет осуществляться через контакт с продажником в вашей компании. Ясно, что это замедляет процесс продажи, и добавляет заметно больше требований.
В некоторых таких компаниях уже будет прям отделы юристов, специальный procurement отдел, они будут изучать предложения конкурентов, торговаться, выбивать наилучшие условия.
В больших энтерпрайзах это уже будет обязательно и еще более налажено и сурово в процессах. Еще медленнее и затратнее для компании.
В разных сценариях компании имеют разные приоритеты при выборе продукта, и могут оценивать совсем разные параметры.
И да, для больший энтепрайзов в целом будет нужна гораздо большая гибкость, намного детальнее требования, которыми нельзя пренебречь, все это увеличивает уровень сложности системы на несколько порядков.

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

Хз, мне гугл вот такое выдал www.quora.com/...​siness-and-an-enterprise

There is no defined demarcation between a business and an enterprise — or there are those that make the designation, but there are thousands of others making a different designation.

Я потому так и написал

Существуют разные интерпретации критериев этого понятия

Действительно понятие расплывчато.
Во общем давай примем что это такой градиент в понятии, но условно если у тебя в продукте нет сеттингов на несколько страниц с кучей кнопочек и чекбоксиков то никакой это не энтепрайз :))

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

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

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

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

интересно как ты сам различаешь оба два? ))

это зрелый машстабный продукт

<=>

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

это точно не про энтерпрайз

Или тогда define энтерпрайз

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

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

И все это для очередного плагина к вордпресс?

угу узнаю брата колю (к) (тм)

validFrom TIMESTAMP NOTNULL,
validTo TIMESTAMP NOTNULL,
isActive BOOLEAN NOTNULL,

записи могут быть валидны но неактивны а как так а х.з. как там причём поля валидности при это оба два NOTNULL как заполнять а х.з. как заполнять ща чонить накостыляем побыстрому там какой-нибудь мажик дэйт ну скажем до 83-го года никто же ж не может иметь дату от 83-го года потому что в 83-м году ещё точно ничего не было о профитЪ! две премии этому чуваку!

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

ага классика моя любия после которой я перестал их запоминать ну и ходить тоже )) "у нас сегодня накопился принципиально важный сложный слаборазрешимый вопрос который требует длительного обсуждения с непременным участием всех команд нам надо куда-то сложить файлы в какую-то папку и надо решить как мы её назовём? чувак предложивший очевидное логичное тупое как дверь название уже ранее вот прямо в соседней прямо папке применяемое как шаблон по традиции вылетает в окно бугога ))

угу узнаю брата колю (к) (тм)

Ага, щас посмотрим

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

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

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

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

именно потому кровавый ынтыпрайз (к) (тм)

данные и к ним ещё +100500 флагов инструкций канцеляров поставновлений указов внутренних распорядков и прочего «жизненного цикла функционала» включая

иметь енум жизненного цикла, влияющий на полноту функционала.

именно это же ж я и поимел в виду ))

это проекция твоего опыта проблем солвинга

всё так всё так и всегда можно найти кого-нибудь крайнего ))

ещё +100500 флагов инструкций канцеляров поставновлений указов внутренних распорядков и прочего "жизненного цикла функционала"

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

нет конечно )) откудова мне вообще знать как устроенный кровавый ынтырплайз? ))

Встречается, но редко.

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

validFrom TIMESTAMP NOTNULL,
validTo TIMESTAMP NOTNULL,

А если мы хотим бесконечность? ^_^

Максимальную дату, которая помещается в TIMESTAMP. Периоды, ведь, проще выбирать просто сверяя даты, а не балуясь с NULL-ами.

С точки зрения UX? Разве что проверять на нулл и пихать туда максимальную дату. Но зачем, если можно оставить нулл?

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

WHERE @p BEWTWEEN (validFrom, validTo)
Вместо
WHERE validFrom IS NOT NULL AND validTo IS NOT NULL AND @p BEWTWEEN (validFrom, validTo)
Но каждый может грызть кактус как ему нравится.

Вернее даже

WHERE validFrom IS NOT NULL AND @p > validFrom AND (validTo IS NOT NULL AND @p < validTo OR validTo IS NULL)
Чушь, короче.

Как-то уже упоминалась сортировка по nullable полям как вариант. А UI сам может сконвертировать даты как надо

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

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

Вот это

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

и вот это

Если это ентерпрайз здорового человека

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

а писать даошки

их не надо писать, их надо генерировать макросами

и контроллеры

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

Есить гораздо более удобные и совершенные вещи для достигания всего чего надо.

Я правильно понимаю, что дальше планировалась проповедь о рекурсиях, монадах и функциональщине в идеальном мире на котлине и скале?

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

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

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

Насколько я себе представляю, в FP контроллер никуда не девается, просто он представляет собой финальную композицию функций, завёрнутых в IO / Reader (потому как побочные эффекты как получения данных для выполнения операции, так и для сохранения её результатов, никто не отменял).

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

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

.

Под «писать контроллеры» обычно подразумевается писать первое. А ещё хорошо бы сравнить как работает MVC из 3-х чёрных ящиков(в общем случае с состоянием внутри) и непонятной взаимосвязью, и набор из типа Data, типа Action, функции (Data, Action) => Data, и функции Data => View. Я думаю что второе очень сильно отличается от первого.

лапшокодная нечитаемая спагетина в виде класса

Вам не приходило в голову, что на ООП тоже можно писать красиво и грамотно? Мне самому нравится ФП, но я категорически против предвзятого отношения вида «ООП == спагетти-код с нарушением инкапсуляции и размытыми границами ответственности между классами»

Вам не приходило в голову, что на ООП тоже можно писать красиво и грамотно?

Это уже получается discipline driven development(что всегда очень ненадёжно). Не благодаря, а вопреки. В разы проще сделать косо-криво чем красиво и грамотно. Я же предпочитаю, чтобы было проще сделать красиво и правильно чем косо-криво. ООП это очень нестрогая штука, все принципы начиная с ИНП до паттенов описаны туманно и размыто, примерно настолько же конкретно как принцип действия гипердвигателя в космоопере.

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

Это только 2 проблемы ООП которые лежат на поверхности, но их гораздо больше.

одним словом почитайте DDD, и вы поймете как можно моделировать объекты реального мира не перегружая при этом модель. Если вы не умеете в ООП то я могу процитировать классика «Нечего на зеркало пинять коль рожа крива»

Справедливости ради, хорошо и правильно умеют в DDD тоже очень и очень немногие.

Мне кажется, тут дело не в холиваре ФП против ООП, а в том, что писать красивый надёжный читаемый код непросто в любой парадигме.Но если у ФП порог вхождения сам по себе довольно высокий, и преодолевшие этот порог давно уже выросли из «штанишек» говнокодинга (хотя, при желании, и там можно извратиться и устроить global variable hell, обмениваясь изменяемым состоянием через ту же монаду state), то в «типа» ООП стиле можно начинать писать с адовыми костылями и с нарушением всех известных принципов и практик, и оно даже как-то будет работать.

Справедливости ради, хорошо и правильно умеют в DDD тоже очень и очень немногие.

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

Справедливости ради код на том же OCaml весьма читабелен. Меня заплюют, но, имхо, в Haskell чудовищный синтаксис (кастомные операторы, программно определяемый приоритет операторов и направление ассоциативности, часть операторов из стандартной либы читается справа-налево, как-то compose и bind, часть слева-направо, как-то map и apply, частичное применение, бесточечная нотация, плюс зависимость от отступов, плюс по-факту один namespace на модуль, и далекая от изящной система импортов). В сочетании с, и так непорстой, системой типов, чистотой, и ленивостью — это когнетивный адов ад. Т.е., чтобы добраться до семантики происходящего, необходимо решать китайский кроссворд синтаксиса, каждый раз. И для реализации простой рутинной задачи — исполнять изящный пируэт с тройным сальто. Оно-то, конечно, красиво, но к плохому синтаксису привыкнуть и не замечать его можно. А к необходимости его постоянно сознательно парсить — нет.

частичное применение, бесточечная нотация

Ну вот именно эти две штуки не являются особенностью Haskell, и вообще делают функциональное программирование намного приятнее :)

Здравствуй, член секты свидетелей фаулера.

и вы поймете как можно моделировать объекты реального мира

вы читать умеете?

В программе мы никогда не можем иметь дело с объектами реального мира — только с данными о них.

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

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

Любая программа — это строгая теория описывающая преобразования данных, это не модель

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

Какой вопрос, такой ответ — данные о железке.

в напряжение на тормоза и свечи зажигания

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

ОК, у тебя

Любая программа — это строгая теория описывающая преобразования данных, это не модель

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

На пальцах см. programming languages theory. DDD это про красивый SOLID и поддерживаемость, и в фп, как единственном адекватном подходе это, хотябы, возможно (см. либу zio, например). Хотя сейчас как-то модно в одну кучу сильную типизацию и фч, хотя они, тащемта, ортогональны.
Другое дело, в эмбедед вряд-ли необходимы издержки ради удобства и стоимости поддержки и развития больших проектов.

Для пущей определённости о чём речь: en.wikipedia.org/wiki/Expression_problem

Это все — какая-то слишком сложная теория. У меня нет образования, необходимого, чтобы это усвоить.

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

Что характерно, как и большинство проблем, решается в ООП костылями («kinda» solve в статье).

конечно. НЕ костылями проблемы решают в некоторых науках.

Как там Страуструп говорил
Существуют лишь два вида языков программирования: те, которые постоянно ругают, и те, которыми никто не пользуется

Вот там, в статье, пример на Clojure. Помню лет 5-7 тому ему пророчили больше будущее.

Так что желающие решать проблемы не костылями — могут брать «Clojure» и вперед.

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

С другой стороны, когда проблема возникает — в современных (FP) языках для неё есть решение.

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

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

так и с остальными достижениями в современных (FP) языках

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

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

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

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

Эта проблема вылазит из-за недостаточной энкапсуляции чужого кода. Если бы сразу сделать just another layer of indirection вокруг чужой библиотеки, обложив ее своими классами, то нет проблемы, что не можешь менять уже написанный код. И получаешь жестковатый рефакторинг вместо analysis paralysis.

Ну и, может, у нас разное понятие об ООП. Я учил по GoF (composition over inheritance) и до сих пор не знаю, как расшифровывается SOLID.

just another layer of indirection

Возможно, не совсем понимаю о чём речь. А какой будет интерфейс у этого слоя, если заранее не известно, какой функционал потребуется добавлять?

Свой самописный будет, исходя из текущего понимания вещей.
Тут 2 противоречивых утверждения:
1) У нас ужас чужой код, который нельзя менять
2) У нас непонятно что код должен делать.

Если (1) ужас чужой код, то он что-то уже умеет делать. Возьми оберни его API своими классами, получишь независимость от вендора чужого кода, и заодно примерно поймешь, что надо делать. И всегда сможешь сам поменять свою обертку, когда понадобится изменение поведения базового класса.

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

Возьми оберни его API своими классами

Оо ужас ооп буэээ классы фу фу фу дайте мне монады

А какой будет интерфейс у этого слоя, если заранее не известно, какой функционал потребуется добавлять?

Decorator/Facade/Adapter/Bridge.

SOLID и поддерживаемость, и в фп
In object-oriented computer programming, SOLID is a mnemonic acronym for five design principles
Возможно однажды комьюнити дорастёт до

Возможны, однажды, камуните дорастет хотябы до понимания аббревиатур :)
И не будет приписывать солид функциональщине.

SOLID принцип проектирования, один из наиболее здравых, «функциональщна» — единственная теория вычислений (ООП — крайне костыльная реализация, особенно джавовское). Не вижу противоречий.

Ну, как бы, большинство букв из SOLID можно применять и в ФП.

Насчёт O не уверен, а вот даже L вполне применим, если считать сигнатуру функции (передаваемой в качестве параметра) интерфейсом.

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

I более чем актуален, если понятие интерфейса расширить до «интерфейс модуля», а не только «интефейс класса»

D в ФП применяется только в путь, монада Reader — самый типичный способ внедрения внешних зависимостей в ФП (использовал лично и знаю, о чём говорю).

S — опять-таки, для функций и модулей в ФП прекрасно применим.

Ага. Вот I и D для функциональщины особенно актуальны :)).

I — type classes или модули (их сигнатуры) в Caml, или трейты в Scala
O — final tagless, free monads и им подобные профункторы
D — сочетание вышеперечисленного, плюс наследование интерфейсов в type classes, GADT, и «функторах» ML.
Про S — вполне себе разумно учитывать проектируя как тип, так модуль, и конкретную функцию

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

Забавно что L меньше всего вопросов вызвал, но в целом и тут в языках без сабтайпинга можно притянуть наследование интерфейсов и type classes laws. Хотя в любом ML языке вполне себе сабтайпинг и вполне себе подстановка, разве что раннее связывание.

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

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

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

Тут обсуждается следующее утверждение:

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

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

Модули ФП использует. ФП противоставляет алгебраические типы ООП классам, а инстансы (обьекты) там так же в наличии есть, как ООП.
Скинь мне то, что ты называешь сложный домен на ООП. Сможем глянуть, на практике как его можно упростить используя ФП язык и паттерны. Можем начать с простого — классы с наследованием описывающие домен без поведения. Если останется желание — сможем посмотреть как наделить их поведением.

Модули ФП использует. ФП противоставляет алгебраические типы ООП классам, а инстансы (обьекты) там так же в наличии есть, как ООП.

Тогда у вас в ФП вовсю ООД.

Сложных доменов глубоко не знаю, если хочется заняться камасутрой — держи радиотелефоны:
(первый звонок) www.etsi.org/...​_60/en_300444v020501p.pdf
(кодеки) www.etsi.org/...​0/ts_10252701v010501p.pdf
(параллельные звонки) www.etsi.org/...​0/ts_10252703v010701p.pdf
(payload description) www.etsi.org/...​0/en_30017505v020801p.pdf
Мы делали SIP<->DECT gateway, для SIP использовали pjsip:
www.pjsip.org/...​tml/group__PJSUA__LIB.htm
(базовый протокол) tools.ietf.org/html/rfc3261
Если есть желание — можно обсудить твои предложения. По крайней мере, этот домен я знаю, включая грабли.

Тогда у вас в ФП вовсю ООД.

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

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

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

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

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

давай кусок домена и его представление на ООП, попробуем задизайнить на ФП вместо заниматься демагогией.

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

Какое тебе представление на ООП давать? Хочешь реально сложный домен — вот высокоуровневая картинка для браузера www.chromium.org/...​ulti-process-architecture и вот рендеринг www.chromium.org/...​ing-architecture-diagrams — можешь подумать, как это делать на ФП.

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

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

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

учитывая количество проектов на node.js и пхп — даже холивар static vs dynamic далек от окончания.

выглядит лаконичней

лаконичность — не синоним читабельности
иероглифы лаконичней фонетического алфавита.

иероглифы лаконичней фонетического алфавита.

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

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

Так и скажи, что не умеешь в ООП :-З
Тем более что мы и так это знаем.

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

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

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

Ооо чувак это зашквар ))

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

це репорти, які, як відомо, ооп не вміє :)

Это кому известно? Репорт — не объект?

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

дві з половиною операції

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

Ви почнете моделювати об’єкти ?

Да. В том числе, я соберу информацию о необходимых вариантах выдачи данных и их тоже смоделирую как объекты.

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

Так и скажи, что не умеешь в ООП

Исчезающе малое чилсо людей умеет в ООП. И боюсь что ни вы ни я ни кто либо из этого форума в него умеет.

ни вы ни я ни кто либо из этого форума в него умеет

Почему так думаешь? Просто интересна логика такого вывода.

Просто интересна логика такого вывода.

Всё ооп которое я когда либо видел — либо срывается в физз-базз либо в лапшу. Либо содержит очевидные косяки. Из EO пытались сделать что-то более вменяемое, но опять сначала сделали, потом подумали, и получилось как обычно.

для такого мнения достаточно иметь
— уникальный взгляд на ООП. Свое собственное ООП, желательно идеализированное. Тогда никто не сможет угодить :)
— завышенные ожидания как от ООП, так и от разработки ПО. действительность всегда окажется разочаровывающей
— быть математиком максималистом. по профессии ли, или по мировозрению.

Возможно, имелось в виду Smalltalk-style OOP, где упор делается на сообщения между объектами, а не на сами объекты, или, тем-более, классы. Которое, afaik, позже получило развитие в эрланговские акторы, весьма изящные в своей нише. При создании Java же, использовали «собственное ООП», что и привело к куче проблем. Хотя, может, это была и осознаная жертва ради какой-никакой — статической типизации.

Возможно, имелось в виду Smalltalk-style OOP

Возможно. Только Алан Кей — не Абсолютный Господь, чтобы считать его ООП единственно правильным.

При создании Java же, использовали «собственное ООП», что и привело к куче проблем.

Как по мне при создании Java более весомы другие ошибки чем ООП от Страуструпа. в C# эти ошибки были учтены. Как и Typescript — по моему весьма толков.

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

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

То что она нужна в ЯП видно по вполне распространенному применению рефлексии при программировании на Java.

При чем динамическая типизация и рефлексия? Не уловил мысль.
Рефлексия в джаве применяется не для упрощения строгой типизации.

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

конечно не только для обхода статической типизации :)

При чем динамическая типизация и рефлексия?

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

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

Ни разу не видел.
Рефлексия для обхода инкапсуляции — да. Для нестрогой типизации — нафига?

в потрохах библиотек — очень часто. Да и джавовский type erasure так себе к строгой типизации относится

Ни разу не видел.

постоянно видел.

Рефлексия для обхода инкапсуляции — да

да, это основное применение.

Для нестрогой типизации — нафига?

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

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

хотел нагуглить одно, и нашел еще интересный пример

Что там с JEP-303 или изобретаем invokedynamic
habr.com/ru/post/328240

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

Красиво и правильно — это затраты времени на анализ
Неважно какой метод возьмете — этот анализ потребует времени.

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

Во вторых у ООП-тусовки одержимость писать код «моделируя реальный мир».

Это не у ООП тусовки. Это свойство человеческого мышления — мыслить стереотипно, обобщенно, а не детально.

Это просто неразумно

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

Объекты реального мира — не постижимы в полной мере

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

В программе мы никогда не можем иметь дело с объектами реального мира

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

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

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

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

а в книжках по ООП и не притворяются

а в книжках по ООП и не притворяются

очень даже и.

www.dietmar-kuehl.de/...​nheritance.html#faq-21.11

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

[21.3] Is a parking-lot-of-Car a kind-of parking-lot-of-Vehicle?
[21.4] Is an array of Derived a kind-of array of Base?

про ко- и контравариантность автор не знает, ещё один минус.

И снова, много воды и нет сути.

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

Это всё от того, что никто формальным образом это ваше ООП вводить не хочет.

никому прежде не удавалось сформулировать принципы ООП

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

а то что математикам это не нравится, а идеалисты ждут неестественного, это да :)

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

если принципы сформулированы и неизменны

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

Это всё от того, что никто формальным образом это ваше ООП вводить не хочет.

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

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

ПО даже к инженерному ремеслу сложно отнести

спасибо, поржал. Под определение инженерии с вики вполне подходит.

если принципы сформулированы и неизменны

ООП с момента появления ООП не набирало новых принципов не так ли? к самому ООП

если принципы сформулированы и неизменны

применимо, и тем не менее Формализации нет.

бОльшая же часть ПО разрабатывается на основе неполной информации

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

неполной информации

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

потому что не предложена универсальная формализация

формализаций тьма, и применить можно, и даже для программирования, и даже для разработки ПО. Вон на коке можно вполне рабочие программы писать, а он как раз таки рабочая универсальная формализация программирования(да, там есть и рекорды, и тайпклассы, и модули и всё что нужно). Про разного рода формализации для перекладывания элементов коллекций с места на место и жонглирования условиями уже даже писать не буду.

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

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

на основе неполной информации, или информации которая станет ложной в будущем.

.

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

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

Увы, не можна ж. Оно кодогенерирует неэффективный код — раз. И без пруфов что сгенерированое соответствует спекам — два, доказывать, вроде, отдельно нужно. Плюс стоимость такой разработки будет раз в 20 дороже аналогичной на промышленном языке. Можно на ATS, но по цене разработки будет то же. Проще за разумное время или относительно стабильное но не очень шустрое ФП решение, или шустрое и нестабильное на императивщине.

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

Это про Питон? Почему же на нем пишут?

Про Coq. На нём верифицируют.

Так у Питона не то же самое? Медленное выполнение и динамическая типизация. Тем не менее, очень популярен.

В Coq очень мощная типизация, cutting edge. Но у него нет рантайма :) Программы на нём пишутся не для того чтобы их запускать, а чтобы проверять корректность их типов :)

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

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

ООП не математика.

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

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

не могу согласиться.

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

как следуя
«Художник это его картины»
начинать искать в галареях повешенных на стену художников.

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

программист обычно НЕ деклариурет — вычисление.

а из того что вычислительная машина ничего другого не умеет кроме как — вычислять, и поэтому все что декларируется программистом — вычисление
то это как делать вывод:
мышление это манифестация пищеварения! ведь все ради желудка, в итоге!

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

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

становится ли от этого — рисование тождественным химии?

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

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

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

понимаете, книжки по ООП рассчитаны на взрослых людей

поэтому там не написано как говорят, на плащах Бетмена
«Запрещается использовать для полетов!»

но те кто разбиваются, конечно говорят
Ваш плащ Бетмена не работает!

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

я — веган

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

JS не нужон =P

А во что тогда Elm будет компилиться?

А это аргумент, пожалуй.

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

Упс, как много букв. Все, что сказано выше — это работа архитектора (в т.ч. и прикладного архитектора). Но никак не програмца. А то когда каждый програмец себя будет чтить архитектором, то потом все созданные ими фичи надо будет слепить как-то вместе. Это раз. Два — таких вот структур со временем накапливаются тысячи. И потом, когда надо что-то добавить (исправить), то хочется просто выбросить все в мусорную кучу, т.к. во всех этих множествах структур никто не может разобраться. Ну а три — это когда через полгода-год такие вот структуры (из второго примера) начинают еле ползать — и тут выясняется, что да там же нужно индекс было сделать, а его нет; или есть 5 одиночных индексов, а надо один составной на три. (это я к примеру).
Как раз работа архитектора и заключается в том, чтобы понимать — куда можно (и нужно) прилепить вводимую юзером строчечку. А не плодить никому ненужные энтерпрайзные решения в огромных количествах.
Пы.Сы. Конечно, далеко не во всех командах есть архитекторы. Даже далеко не во всех фирмах. Ну... От этого жизнь ведь не останавливается. Его функции должен кто-то исполнять по факту. Например, лид.
Пы.Пы.Сы. Не хочу сказать, что Dmitry Bugay сказал неправильные вещи по сути. Правильные. Только, на мой скромный взгляд, немного неудачный пример. И палку чуть перегнул — когда некто решает не просто кодить, а создать некую универсальную весчь (которая оказывается, в итоге, вовсе не универсальной).

Его функции должен кто-то исполнять по факту. Например, лид.

Или разрабочик здорового человека 🙂.

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

Согласен, пример вышел неудачный.

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

Ентерпрайз учит думать и коммуницировать во многих измерениях и контекстах, в т.ч. временнОм.

Как думает типичный 23 летний синьор в модном стартапе iRoga-&-MacKopita:

откуда такие про SQL знать будут, он же для динозавров, сейчас в моде NoSQL (или в блокчейн строки пихать) :)

А зачем пихать всю эту информацию в одну таблицу если ее можно хранить в каком нибудь чейнджлоге типа эластика? Как по мне кривой овердизайнед дизайн. Приходилось работать с таким наследием

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

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

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

Палка с двух концов
Грозит нагромождением хреновой тучи не нужных абстракций, нарушением KISS и тд. под казалось бы иногда примитивнейшие задачи. Иногда «задача хранить вводимую юзером строчечку в бд» это действительно хранить вводимую юзером строчечку, не более.
Не зря во всяких FAANG’аг одним из главных требований для сеньйоров является умение бороться со сложностью. Так что наверное важнее будет уметь отличать эти кейсы

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

ха, два рази
лєгєнди нашої Долини
оце так обобщіл так обобщіл, 5 контор як мінімум і всі проекти, всі під одну гребінку вирівняв

Напевно і поміж командами різні стандарти будуть навіть в одній конторі? І хто взагалі ставить стандарти, обирає технології в команді? Є якісь писані корпоративні цінності?

максимум хватало на пол года, потом уходил

Ловите наркомана) Вот из-за кого в компаниях одни убытки, как из соседнего топика.

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

Я как-то месяц ждал креды на репозиторий, в осатльное время пинал куи и делал умное лицо :-)

Сурово!

Чесно кажучи, мені в такі моменти ніколи не було скучно. Заняття я собі завжди знаходив, він банального читання умовного ДОУ і до ковиряння якогось pet project. В любому випадку, набагато цікавіше ніж ковиряти типовий проект.

Приходится и ООП применять, и иерархии классов проектировать,

Краще таке не проектувати.

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

— хороший коллектив
— стабильность проекта
— зп на уровне рынка
— - если зп не повышают, то пусть хотя бы индексируют
— овертаймы — лютейшее исключение
— 2/3, а то и 3/4 задач делается спинным мозгом, вследствии чего домой можно пойти не через 8 часов, а через 6
— даже если через 8, то тогда половина рабочего дня уходит на гонку чаев, сидение в интернетах, всякие спортивные активности. В особо вопиющих случаях и при наличии двух мониторов — в одном ИДЕшка, в другом какой-нибудь фильм крутится.
— нету черного/белого списка сайтов

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

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

Я к тому и веду, что июням там нечего задерживаться.

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

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

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

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

А как можно представить себе разработку сложной системы без совещаний? Да, решение можно сделать за 15 минут, а потом он окажет негативный эффект на целую систему.

Полностью с Вами согласен, есть изменения которые затронут многих пользователей класса\модуля\сервиса, и как раз задача разработчика уметь вовремя выявлять такие изменения и сигнолизивать о них. В некоторых же фирмах есть культ митингов. К примеру у меня сервис, этот сервис дергает свою базу, мне надо поменять размер строкового поля UserName в таблице с nvarchar(max) на nvarchar(256), для лучшей оптимизации базы. Эти изменения не затронут не коим образам внешних пользователей, так как база используется только этим сервисом, на стороне приложения есть уже давно валидация не более 256 символов. Мне же надо только написать апдейт скрипт для стейджинга и продакшена и согласовать этот вопрос с админами базы, все. По факту же организовывается митинг с ПМ, со всей командой, с продуктовнером со стороны клиентом, тех спецы со стороны клиента. Пол митинга решается кто виноват, что создал такое поле, потом решается кто будет исправлять это, я не могу так это не входит в скоуп моих текущих задач, админин тоже не может, так как скрипт должен попасть в репос, чтоб все девы применили изменения, а у него доступа нет к репосу. Потом отдельный митинг, чтоб проистимейтить таску, внести ее в беклог, и понять можем ли мы ее взять в текущий спринт, или надо что-то выкинуть из спринта, если да то что. Вот вам пример из жизни.

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

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

Да, когда в команде trunk-based development с ci/cd то уже реально с ужасом смотришь на все эти согласования каждого шага с кучей невовлеченных и часто не разбирающийся в принимаемом решении всяких факин «стейкхолдеров»

Ну так всё правильно. Поменять дело 15 минут, а вот на что оно влияет — надо обсуждать. И внести в документацию и назначить ответственного. А как же иначе?

А как же иначе?

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

Это не сервис а часть сложной системы

Контракты у этой части сложной системы есть? Если да, то для чего привлекать всех любителей стейков, если контракт не меняется? А если нет, то почему?

За систему отвечает 1000 разработчиков. Изменение требует согласования всех глав команд.

очень сильно от конторы зависит

1. Будешь заниматься технологиями востребованными на рынке труда. Да, они возможно не самые-самые новые(за этим в стартапы), но уволившись с одного проекта ты мнгновенно найдёшь работу в другом. Продуктовые конторы часто-густо сидят на самописном, никому не нужном за пределами конторы фреймворке. Проработал два года — квалификацию потерял.
2. Спокойно. Сравнительно мало незапланированных овертаймов.
3. Не требуется гореть на работе — не надо быть фанатом продукта и всячески это демонстрировать.
4. В энтерпрайзе всё прогнозируемо, если планируются увольнения это заранее видно.

Конечно, это всё в среднем. Бывают исключения

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

Очень редко.

Хватает. Послушай Бобра.

Бобер мазохист

работы определяется софтскилами, а совсем не тем, что и как ты делаешь.

Работа определяется разницей оплаты: за тушку и тебе на руки. Пока она плюсовая волноваться не о чем.

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

Только перенос в оутсорсинг это уже сокращение. Дальше только всех уволить

Как только у меня не будет другой работы :)

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

главный плюс — бабки
все остальное минусы

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

Ой, завжди дивувала така думка)))

На великих серйозних (підкреслюю серйозних) ентерпрайзах працювати одне задоволення, коли досягнув того рівня кваліфікації, що тебе влаштовує. Тобто, коли ти вже знаєш достатньо (так думаєш собі), решту можна собі вже потрошки вчити. Не обовязково знати-вміти кубернетес, angular v23, webpack 4.41.4 чи ще якусь нашумівшу технологію. Продукт такий потрібний, вирішує якісь проблеми, зазвичай доволі непогана компенсація, стиль роботи розмірений, можна працювати, так, щоб ще встигати жити, створюється якась ілюзія стабільності.

Так, багато мітингів, багато незрозумілих розмов, але вони розвивають софт-скіли набагато більше, ніж коли 2 дева, стартап, все з нуля, «давай заюзаємо всьо нове». Чому? Тому, що переконати 20-30 людей заюзати ту чи іншу бібліотеку, переїхати на нову версію джави, десь почати використовувати AWS, а не ті старі IBMські непонятні серваки, заюзати спочатку докер для девелопменту, потім для продакшину, набагато, набагато складніше.
Так, відсутність швидкості на такому проекті може сприйматися мінусом, але з часом хочеться мати життя поза межами IDE))

Плюсы
— адекватное планирование и релизы
— CI/CD процесс настроен и налажен
— миф о том, что в энтерпрайзе лютое легаси, или устаревшие технологии лишь наполовину правда (зависит от проекта и менеджмента), а так, если технология подходит под задачу — proof of concept и поехали использовать в бою
— стабильная зп и бонусы, а не «ну вот короч, скоро выйдем на нный раунд инвестиций и тогда заживем»

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

финансы, или банки
— адекватное планирование и релизы
— CI/CD процесс настроен и налажен
— миф о том, что в энтерпрайзе лютое легаси, или устаревшие технологии

в какой звездной системе эта планета?

Якщо розробником то суцільні мінуси, бо із-за відсутності достатньої практики вміння втрачаються

Мінуси:

  1. Відсутня можливість відразу зробити задачу коли знаєш як, багато часу встратиш на узгодженні
  2. Дуже повільний ріст кваліфікації та винагороди
  3. Застарілі технології і відсутність бажаючих використовувати нові
  4. Відсутність перейти на +$500 без підготовки
  5. Більшість здобутих знань за час роботи актуально лише на цій роботі

Завжди уникав такі проекти і компанії

Уууууу какой ужас ууууу. Не дают играться в кубернетес и монгу. Заставляют делать нужную работу. Уууууу

Docker, Consul, MySQL, Redis, ClickHouse, Go ➡️ поки вистачає іграшок

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

Як кажуть в ентерпрайзі, хіпстери завжди знайдуть собі якусь нову іграшку, а Java то назавжди :D

«Играться» должно быть частью полноценной девелоперской жизни. Потому что, во-первых, All work and no play makes Jack a dull boy. Во-вторых, любая «нужная работа» рано или поздно заходит в тупик когда без качественных изменений (стека, архитектуры итп) уже вырулить невозможно. И тогда те, кто «игрался» могут предложить какие-то решения. А те, кто не игрался, будут предлагать «давайте все дружно сядем и пофиксим тритыщи багов и наступит всем счастье».

10 років назад мені сказали що срібної кулі нема. Я сходив, подивився — дійсно нема. Вже 9 років не шукаю срібну кулю.

А речь не про серебренную пулю, а про понимание вариантов выруливания.

хм
остаются время и силы на собственно жизнь вне работы?
(ладно, фигню написал, извиняюсь)

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

Все что вы описали, и минусы и плюсы — для меня одни сплошные плюсы.

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

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

Сидіти по 3-4-5 і більше років на одному проекті на сьогодні вважаєте дурносмаком і показником того, що людина неконкуретна на ринку праці.

Ну или что ринок праці неконкурентный для работника.

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

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

Опыт не галеры, но продукта.

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

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

А так вообще на любителя, конечно.

задачки на оптимизацию или рефакторинг

по сути самое «вкусное» в айти

Викладувайте, шо ви там оптимізуєте. Sql queries, db schema, а що ще? Видалення тупого коду. Ну а щось more deep? Знання дата стракчерс і алгоритмів пригождаються? Є тонкий тюнінг коду? Де б треба думати як компютер сцяєнтист, а не фреймворк мавпа?

шо ви там оптимізуєте

ну майже все, що відноситься до lamp (+кеши, черги, індексні сервера)

Sql queries, db schema

Після сотень мільйонів записів у таблиці там починається купа смачного, денормалізації, оффлоадінг, index hell, можна займатися хоч усе життя

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

у чистому вигляді — ні. у прикладному — так, ну там треба розуміти як воно там, наприклад, у mysql зроблене, з усіма тими thread contentions та каскадними локами , чи там наприклад , ну не знаю, як правильно зберігати терабайти файлів, щоб файли швидше знаходилися :)

Є тонкий тюнінг коду

буває, хоча у випадку php далі ніж xdebug+KCachegrind не заходило, зазвичай алгоритмічної оптимізації вистачало (ні. авжеж, я балувався з оптимізацією php до cpu ticks, але то для фану)

Де б треба думати як компютер сцяєнтист, а не фреймворк мавпа?

тут я не знаю ні першого (якесь новомодне buzzword) ні другого (бо перші свої запити ще під досівський foxpro писав)

компютер сцяєнтист
якесь новомодне buzzword

ха ха, продолжай)

Подписаться на комментарии