Изменения и гибкость кода

[grigori]

Недавно у меня случился инсайт. Часто говорят: "бизнес-требования меняются".
Этот тезис используют для обоснования идеи, что код должен быть гибким, чтобы адаптироваться под новые требования.

Нет. Бизнес-требования только добавляются и устаревают. Бизнес-логика меняется в пределах значений констант. Бизнес пробует новые идеи и отключает старый execution flow.
Основной объем работы - исправление ошибок. Мы не переписываем код для другой инфраструктуры, мы исправляем ошибки совместимости. Если надо перенести код с Mysql на Postgres - мы добавляем новый execution flow, вводим его в эксплуатацию, потом отключаем старый.
Нам не нужна гибкость кода - нам нужна возможность его отключить и удалить.
Нам не нужно менять существующий код - нам нужно про него забыть, и освободить регистры для рождения нового.

Отсюда желание использовать final, readonly и т.п.

 

[grigori]

С этим тезисом есть одна загвоздка - половина интернета на wordpress и joomla. Когда люди хотят странного - хотят именно менять существующий код, выполнять конструктор предка без конструктора потомка, множественное наследование, добавлять методы через monkey patching.

 

[fixxxer]

Бизнес-требования - они совершенно конкретные в данный момент времени, а код - это их реализация.
Гибкость можно понимать по разному, и ее часто понимают неверно. Если у меня условно в тыще мест захардкожен аплоад файлов по ftp, и для перехода на условный s3 надо пореплейсить в миллионе мест, это говно, тут нужна гибкость в виде отвязки аплоада как абстрактного процесса от реализации.
А когда пытаются сделать "гибкость" вида "а что будет, если завтра надо будет продавать не велосипеды, а винду", и начинаются попытки абстрагироваться от предметной области как таковой - ничем хорошим это не закончится, поскольку в итоге получится убогий и куцый другой язык программирования. На этом же месте обычно нормальный объектный дизайн заменяется манипуляциями с данными по принципу CRUD (ну типа а че, мы же в итоге в базу пишем и читаем, какая разница что) В итоге бизнес-требования просто размазываются слоем соплей по всему коду.

 

[fixxxer]

С этим тезисом есть одна загвоздка - половина интернета на wordpress и joomla

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

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

 

[grigori]

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

 

[grigori]

Вопрос в другом. Не надо думать про изменение бизнес-требований. Нужно думать о том, как добавить. Например, добавить новый storage когда это будет нужно, а не о том, как заменить s3 на mogilefs.
Не надо будет ничего менять. Поддержка какого угодно storage тоже не нужна. Нужна возможность добавлять storage в будущем, но еще не знаем какого именно, и не уверены, что понадобится. В принципе, добавить можно - этого достаточно.

 

[fixxxer]

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

 

[WMix]

странно видеть как "бизнес-требование" - "перенести код с Mysql на Postgres" или "аплоад файлов по ftp, и для перехода на условный s3"
я всегда думал это решение

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

 

[WMix]

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

 

[fixxxer]

странно видеть как "бизнес-требование" - "перенести код с Mysql на Postgres" или "аплоад файлов по ftp, и для перехода на условный s3"

я, наверное, не очень понятно выразился, я наоборот пытался противопоставить

 

[Вурдалак]

@grigori побывал в Перу и выпил отвар Аяуаски, на него снизошло прозрение и он побежал на phpclub повторять то, что мы тут уже много лет обсуждаем

 

[grigori]

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

А вот "добавьте Польшу" - я именно про это. Как обрабатывать несколько валют - это влияет на множество доменных моделей. Отдельный тип Money для денег? На каком этапе разработки делать реализацию поддержки нескольких валют? Я говорю о том, как спланировать развитие низкоуровневой архитектуры приложения.
В российских и американских проектах мало смысла делать мультивалютность, хоть и по противоположным причинам. А в Европе надо заложить возможность. Где, в какой степени закладывать валюту при старте проекта - как тип валюты счета пользователя или как отдельную сущность?
Не надо думать, что валюта будет изменяться, надо только продумать, как добавлять больше валют, если это понадобится. Не надо делать редактирование списка валют в админке, хватит поля. Если это не финансовый сервис - не надо делать выбор валюты пользователя, пока не наберется группа платящих юзеров, которые живут в нескольких странах. Не надо делать пересчет сумм по курсу, лучше задавать цены в конкретной валюте. И так далее.

 

[WMix]

это влияет на множество доменных моделей.

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

 

[grigori]

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