Comments 14
это должен быть калькулятор?
Мне кажется, Domain Driven Design здесь описан вообще не к месту. Давайте разберемся:
Спустя полчаса после запуска «работающее ПО» внезапно рухнуло из-за непредусмотренного (а значит, и неуправляемого) наплыва большого количества одновременных пользователей. Клиент считал, что менеджер по продукту и команда разработки должны немедленно устранить критическую проблему. Запуск был отменён.
Вопрос "Сколько одновременно ожидается клиентов на пике и сколько в среднем в минуту/час/день" никакого отношения к DDD не имеет и относится скорее к теме Scalability/Highload. Менеджер обязан был озаботиться им в любом случае, когда задача только ставилась. Надо было проводить нагрузочное тестирование и профилирование приложения. Если этого не делать, то даже написанное идеально с точки зрения DDD решение рухнет сразу после релиза.
«Я верю вам, но вы не ответили на мой вопрос: проектировали ли вы продукт на основании сценариев работы пользователей?», — ответил менеджер.
«Но вы не дали нам никаких сценариев. Мы проектировали продукт для поддержки любого пользовательского сценария. Пользователи могут делать всё, что хотят», — гордо заявил руководитель команды разработки.
Это опять же не связано напрямую с DDD, а скорее напоминает модную среди менеджеров идею под соусом перехода к DevOps разогнать к чертям команды бизнес-аналитиков и тестировщиков. Такие подразделения имелись в компаниях разработки задолго до появления DDD в природе. Также, как и стремление менеджеров срезать косты, сократив эти части проекта. Даже если бы разработчики написали все на DDD, это никак бы не спасло.
Подводя итог - DDD - это офигенная вещь, но она не имеет никакого отношения к истории, которая приводится как аргумент в ее пользу.
Это и есть источник логического долга: несовпадение ментальных моделей между теми, кто создаёт продукты и теми, кто его покупает, кто платит за решение своих проблем.
Мне кажется, что тут просто делали рукожопы и все. Не вижу смысла искать какою-то мораль в этом месте, так как рукожопость все объясняет
Беда в том, что в современном мире рукожопость возведена в культ и стандарт. Написать нерукожопый продукт дольше и дороже, чем обычный, потому рынок этого не приемлет. Весь вопрос коммерческого успеха в том, чтобы держать тонкий баланс между рукожопостью продукта и долготерпением пользователей. Но выдержать этот баланс удается не всегда.
Ну, такое. В реале писать нерукожопый продукт не всегда дольше. Просто есть условно 1-2 способа, как все хорошо. И миллион способов, как все делать рукожопо. Чтобы делать вс правильно - надо уметь. Но это совершенно не значит, что это дольше
Вот смотрим на примере
Спустя полчаса после запуска «работающее ПО» внезапно рухнуло из-за непредусмотренного (а значит, и неуправляемого) наплыва большого количества одновременных пользователей
Простой вопрос, "сикоко пользоватей бывает в природе" совершенно не занимает времени и легко может быть задан на начальном этапе. Если его не задали - проблема именно в рукожопости, но правильный путь совершенно не требует дополнительных затрат.
Дальше это число, и для надежности задав еще пару вопросов про рост бизнеса и умножив полученный результат на 3 (к примеру) - легко получить таргет, к которому надо стремиться
------------------
Мы выпустили то, что максимально возможно, исходя из использованных технологий. Во фреймворке API 13.19.9 был патч с серьёзными изменениями
Это и подобное уже откровенный трешак, который вряд ли имеет отношение к реальности. Но я допускаю, что есь "рога и копыта", где такое возможно
Я хочу лучше разобраться, покажете мне логическую структуру, позволяющую нашему продукту делать всё, что пожелают пользователи
Опять же, есть этап сбора требований. Если кто-то не знает, как это делать - пичалька. Так как иногда оказывается, что собрав требования, вместо реализации 10 кейсов, проще и быстрее сделать общее параметрическое решение ценой 4 кейса, и еще за пол-цены одного кейса настроить все. Но это надо смотреть чуток вперед и моделировать систему а не тупо писать что видишь.
-------------------
Поэтому каждому свое - можно держать баланс рукожопости и еще чего-то, а можно просто этого не делать. Вот к примеру, как часто рукожопый код сильно меньше хорошего кода, который делает тоже самое. Почти никогда. Ну правда. Размер кода не становится больше, если он хороший. А вот время на его написание напрямую зависит от скилов и опыта.
чтобы создать максимально нерукожопый продукт, необходимо получить от заказчика чёткое и ясное - что он хочет получить.
а то постоянно, в процессе разработки дрейфующие в произвольных направлениях и рывком меняющие эти направления мысли заказчика, что бы он хотел, да подешевле да побыстрее. желательно позавчера.
Ну так требования к квалификации аналитиков и архитекторов никто не отменял, а также ПМов. Чуда ж нет, если разработчики хорошие, а все остальные "так себе" - продукт выйдет "так себе"
И кстати, заказчик НЕ знает, что он хочет. Сорян, но именно так чаще все и происходит. Либо он знает "очень крупными мазками"
Задача команды, базируясь на своем опыте, знании рынка и отрасли предложить конкретные решения и убедить заказчика, что это оно. Причем реально убедить, а не старательно обмануть себя, что получилось "впарить".
---------------
А вот если сидеть и ждать четкого и ясного от заказчика - дела не будет. Это кстати в любой отрасли работает, где делают проекты (т.е. нечто уникальное).
чтобы создать максимально нерукожопый продукт, необходимо получить от заказчика чёткое и ясное - что он хочет получить.
Ага, надо слушать заказчика и относиться к его словам всёръёз, а не "да мы лучше знаем, а заказчик чушь несёт"
Рукожопость объясняет вообще все. Но в реальном мире всегда есть нюансы. Например, между заказчиком и программистами сидят несколько рядов аналитиков, менеджеров по работе с клиентами и т.д. В итоге я клиента и в глаза никогда не видел.
При этом в любой проблеме, конечно, виноват программист. Просто потому, что ему не на кого вину скинуть.
А что поделать. Разработчики (а также аналитики, менеджеры, ПМы, ИТ-директора) меняют свое место работы в среднем раз в 2-3 года. Чтобы и от рынка не отстать, и опыт прокачать. Хотя мне приходилось быть свидетелем и смены менеджмента с интервалом всего лишь в один год.
Срок разработки большого корпоративного продукта - те же самые 2-3 года. В результате, очень даже реальна ситуация, когда те, кто проектировали и разрабатывали, в момент внедрения будут уже в другом месте.
Если рассуждать цинично, то ИТ-шники, которые нацелены на последующую смену работы, как раз и заинтересованы чтобы проект был как можно более монструозным. Гораздо комфортней работать, пока проект не используется пользователями.
Логический долг гораздо разрушительнее технического