Ещё забыли что SP — средство не брать на себя обязательств больше чем можно осилить. Для того чтоб перевести SP в часы нужен KPI за прошлый период. Например, спринт. Типа, сколько SP осилит тот или иной конкретный разработчик за 40h? А сколько команда? Из этого следует что/сколько можно пообещать/взять обязательство заделиверить на конец итерации. Нарушать обязательство — плохо, в бизнесе так не делается. Иначе вы (а именно лицо, компания, которую вы представляете) будете считаться плохим партнёром. Именно для того чтоб этого избежать и этим управлять существуют методики и SP. Хотя по факту чаще просто идёт маппинг SP 1:1 к часам и сейлы просто умножают на два — тогда конечно, SP не работают.

Ниже уже частично затрагивали эту тему, но:

задача инженера — составить пошаговый Implementation Plan

и

нужно прописать все изменения

Так получается это займёт столько же по времени Senior/Lead разработчика сколько заняло бы у этого разработчика реализовать фичу. Наверное это имеет смысл отдавать на разработку только не к новым разработчикам, а, скажем, если реализацию предыдущей фичи разработчик ну очень сильно затянул (x2, x3 estimate) или ну очень сильно не туда завернул — чтоб поставить его на нужные рельсы и с каждой новой таской давать описание всё более и более абстрактно. С целью в идеале вообще убрать из процесса старшего товарища и ставить таск в виде BDD feature/story. Чтоб задачи могли зразу от BA/PO/PM или кто там её ставит попадать напрямую разработчику после planning’а, в котором действительно участвует вся команда, например играя в покер и тем самым утрясая подводные камни кто какие видит.
Когда-то давно слышал легенду что от какого-то не особо крупного немецкого заказчика кому-то пришло такое т.з. Разработчик был рад и счастлив — думать ничего не надо, только взять и по каждой строчке т.з. код написать. Это же деньги на шару. Я тогда подумал: «а зачем такое детальное т.з. ещё кому-то отдавать? Это ж обман клиента получается. Он то по сути сам всю работу сделал. А ему ещё и денег платить кому-то.» А так вы, получается, дважды биллите кастомера. Первый раз за синьёра который опишет

все изменения

в плоть до файла/поля что надо изменить и второй раз — за джуна (продажей и его как синьёра не балуетесь? С таким то тз...) который всё закодит. И, если это не инвестиции в развитие джуна чтоб потом получить самостоятельный юнит, а реальный плановый процесс — это ппц. Хотя, если кастомеру это продали...
Касательно

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

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

1. Это точно происходило после общего планнинга (типа покера иже с ними)? Или кто-то подумал и решил что это займёт столько-то?
2. Наблюдения действительно реальны, не может быть это выдаванием желаемого (то что методика работает) за действительное (методика жрёт столько же или больше платного времени как если бы её не было)?
3. Сравнивали на реальных примерах? Например дать двум синьёрам, хорошо знакомым с проектом, с одинаковым KPI, максимально близким/схожим по прочим показателям производительности, один и тот же таск, только одному на реализацию сразу, а другому на детальный, построчный, пофайловый план и с реализацией джуном? Реально второй закончит за день и ещё день будет джун возиться и первый все два дня просидит? Чёт слабо верится. Скорее, если второй и выдаст план за 8h то первый спушит за 6h или меньше.
4. Пробовали сразу дать таск на реализацию и после пуша провести детальное ревью тем инженером что в вашей методике составлял бы план? По платному времени должно быть столько же или меньше.

открыто в браузере в нативном приложении

с локальной машины

У вас же столько точек где можно расставить приёмку того или иного плагина. Зачем было городить iFrame? Вы же сами знаете что это адски ресурсо-затратно:

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

И ладно если нужно отрендерить форму оплаты от PCI-Compliant processing’а — тут и вариантов особо то нет — чтоб не проходить compliance самим нужно рендерить форму «на стороне процессинга». Но зачем вы сами такое навешиваете? Почему не проставить просто html в div из того же бандла и не таскать iFrame?

кто-то бесшовно поломает всю систему

Нет же, если делать приёмку. Если прогонять html/js/css lint тучи которых существуют, рендерить на стороне приёмки и считать сколько места оно занимает, и только после этого enable’ить bundle к загрузке пользователям на локалку (очень оценил такой ход — смелые вы) и, соответственно, интеграцию. Ещё можно трейсить в нативе и штрафовать/disable’ить bundle’ы за ошибки js/css/выход за разрешенное пространство.
Кастомеры явно же захотят превратить вашу панель в брата-близнеца панели iBox’а или чего подобного с миллионом плагинов. Если бизнес принимается за интеграции — их уже не остановить.
А что предлагает ваша платформа? Не боле 4х интеграций? Потому что с пятой начинаем тупить? И это на таком сильном (относительно мобильного рынка) девайсе как яблоПад?

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

Что это за костыль? А если приложение тупит т.к. там уже 4 интеграции от нерадивых разработчиков? Думаете такого не будет? Так что, заказ вообще нельзя будет закрыть? Как можно завязываться на абсолютное значение по времени in-process? Вы же не по сети ходите. У вас же не может быть потери пакетов. Натива либо работает либо нет.

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

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

1. Откуда данные по закупкам? Как проверить достоверность? Вы с 1С (или что там на ваших рынках, Salesforce сотоварищи?) интегрировать собрались? Аппу, которая бегает локально на ипаде?
2. Как узнать у какого поставщика закупки дешевле?
3. И самое главное: как сравнить качество?

У вас счёт выставлен на 270 рашкоублей, вы списываете 150 чего-то (сумма без указания валюты не имеет смысла) и получаете к оплате 120грн. Как это вообще работает? Какой клиент на это согласился? Тот, что платит за капучино 110USD? Но то ладно, демо цены. Но как так — в разных валютах и без курсов?

Это для работы с гопсударством или с контрагентами? Если с контрагентами — их тоже надо будет подсадить на ваш продукт чтоб с ними работать? Если дело дойдёт до суда и контрагент заявит что «небыло ничего, ничего не было ©» ваша ЭЦП имеет какую-то силу? И в какой юрисдикции? Или всё просто пока есть взаимное согласие?
Т.е. вы просто подписываете PDF’ки и как-то умудрились на это выбить $400k+? Где вы таких лоинвесторов выпасаете? Вот уж поистину «смелость» — второе счастье.
Более того: вы несколько раз меняли команду чтоб заделиверить просто подпись PDF’ок с web-мордой? И эти лоинвесторы не потребовали свои деньги обратно?
Да, это таки саксесс стори. Зависть-зависть.

Будет вести себя так как, ведет бинарное дерево, на котором описывают унарную операцию. Это проблема не ФП.

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

• Operation — это только Add и Multiply
• Head — это только операция из описаных выше или литерал
• Node — это структура из трёх (хардкожено) элементов или ничто

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

Перечитайте пожалуйста исходный коммент. Он не о том что задачу можно решить в меньше строк кода. Он о примитивной задаче модульности. Я же даже упрощённый бизнес-кейс привёл с задачей продажи по модулям. Даже с таймингом чтоб ленивым не надо было искать его во всем полуторачасовом докладе.
И если в OOP эта задача решается элементарно то в FP на столько тривиального решения нет — ну не можете вы ничего добавить без добавления case’а в match. И да, решение может быть, но оно не на столько тривиально как при использовании ООП.
Далее, в вашем же примере вы выстроили себе ловушку

Val (right, head, left)

как она себя будет вести при добавлении унарной операции типа квадратного корня? Так же как Lit — тоже добавлением кастомного кейса? А правильно ли это? Очень вряд ли — оно ведь операция, хоть и унарная.

И нет, я предпочитаю не использовать Object algebras даже на Scala.
Статью япривёл для того чтоб показать что даже на столько тяжёлая вещь как изменение контракта — решается. Да, не тривиально, но решается.

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

2 + 3 — 4

Используя FP мне нужно отделить состояние от операций и каждый раз матчить что это такое и только потом выполнять с ним заточеную именно под этот тип операцию.
Используя ООП мне нужно только предоставить контракты листа и узла. Опционально — корня. Сказать так же что каждый из этих контрактов — Printable. Далее — как ходить по дереву и как печатать — говорит уже сам узел. Ты ему только отдаёшь команду.

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

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

Разумеется, сразу можно привести пример что если кроме операции печати выражения (рисования форм в примере Дяди Боба) вдруг появится требование новой операции, например eval выполняющее выражение (describe shape в примере Дяди Боба) — то всем будет одинаково плохо и больно вносить туда изменения. Но на то это и изменение контракта. Но и на это как в FP так и в OOP есть решения.

Идеальный чтоб писать? Сомневаюсь. Чтоб читать? Да вот, пожалуйста. Писали уже и далеко не раз.

Почему не использует? Он же явно пишет о том что пользует опшналы только хочет их использовать просто как врапперы, ref-envelope’ы. Да ещё и mutable.

любой

я достаточно часто захожу внутьрь Play framework’а — да, не спринг, да и вряд ли им станет, но и безизвестной поделкой на коленке его назвать нельзя. Так там достаточно правильного использования опшнала. Собственно, везде где null, теоретически, может появится.

спринг считается крайне чистым кодом

ну как,
как у вас такое в голове умещается когда вы же парой комментов выше пишете:

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

что явно говорит о Open-Closed violation а значит никакого Clean там и в помине нет.
Ладно, назвать его оправданым, ладно авторитетным от людей с пхд — кстати, тоже упоминаний об этом нигде не встречал. Но называть его чистым когда в индустрии уже устоялся этот термин? Как?

При написании кода, например. На джаве.

Достаточно map. По хорошему то что один раз до Optional lift’или дальше до границы приложения из него не выходит.

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

У вендоров это как раз таки давно завезли. Иначе не было бы водможности делать что-то такое или такое. Просто в Java многие ждбц-хибернейтщики привыкли блокировать на пустом месте. Коллбэки им, видите ли, не удобны, с фьючерами только с восьмёрки начали учиться работать, даже по http большинство ходит через блокирующий url-connection хотя давно есть Netty-based AsyncHttpClient.

Да, на его родине его называют джуйс, но в наших то широтах он под этим именем чаще всего встречается.

нету instanceof? Или может быть проще — вы не пишите код?

В Java коде уже давно нет. В Scala есть значительно хуже — match/case но там это фреймворком обусловлено типизированой версии которого в проде ещё долго не будет.

Потому что проект продает перчатки?

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

Всі

?

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

а чем стрёмно то? Давно уже в проде, не первый проект написан и уж что-то но Play так точно всё тортее и тортее

Optional.isNotPresent()

когда это вообще может понадобится?

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

а потом ивенты станут distributed и начнут выходить за рамки одной JVM и такая реализачия станет очередным JUL