Для большей ясности можно обратиться к чисто бизнесовым понятиям: есть короткие и длинные деньги. У них разные финансовые показатели и механики. Если утрировать, то всё оказывается просто: «товар» (short terms) — это дёшево сделали и дорого продали, «сервис» (long terms) — это когда первые платежи не покрывают инвестиций, и требуется просчёт положительных и отрицательных бонусов от принимаемых решений. Риски тоже разные. В первом случае главный технический риск — хватит ли начальных инвестиций для того, чтобы продать с прибылью? Во втором — хватит ли будущей оплаты услуг на покрытие начальных инвестиций, учитывая будущие расходы.
Если подходить к разработке с оглядкой на финансовую модель — много и ясно становится, и договориться с заказчиком проще. Но есть пара областей, где это плохо получается. Первая — внутренний заказчик. Обычно хочет чтобы быстро и дёшево, но сильно негодует, что потом оказывается долго и дорого. Проблема существенна, если не удаётся донести соответствие технический решений и финансовых результатов. Вторая область — это нефинансовые отношения. Друзья, опенсорс и т.д. Тут вместо отсутствующих денег начинают играть психологические мотивы. Кому-то хочется попробовать что-то новое, кому-то сделать монументально-крутое, кому-то отделаться от задачи, отказаться от которой нет желания…
Надо ещё понимать, что в любой из ситуаций могут присутствовать косвенные бонусы для все участников, как-то нематериальные мотиваторы (гордость, чувство глубокого внутреннего удовлетворения...), так и потенциальные будущие прибыли (если не стыдно проект в портфолио положить). Но эти инструменты уже очень индивидуальны и склоны меняться прямо в процессе, по не зависящим, так сказать.
Можете начать с того, чтобы поменять заголовок статьи? и tdd из тегов убрать? Чтобы быть честным с читателями. Потому как описываемый вами пример не имеет отношения ни к tdd ни к проблеме тестирования публичных контрактов.
А самое простое решение поставленной проблемы имеет классическое описание: вместо мутной логики в приватном методе делаем публичный класс, в который помещаем ту же самую логику и пишем столько тестов, сколько захотим. Приватный метод превращается в банальное обращение к этому классу и уже не требует собственных тестов.
Реальная же проблема, которая наблюдается в вашем примере, и присутствует в куда более жёстких проявлениях во всякий древних проектах — это макаронный код, где вперемешку логика и работа с внешним состоянием и внешними сервисами. Вот там да, на первый полезный тест можно пару недель убить…
если все знаете, зачем критиковать и изливать негатив?
Ну, как бы это… Заголовок очень расходится с содержанием.
«Важнейшие структуры данных» — скорее основные, не более того, да и то не все…
«которые вам следует знать к своему собеседованию по программированию » — вот тут совсем не правда. Уровень изложения совсем не соответствует тому, что реально могут спросить на собеседовании по программированию. Разве только совсем-совсем джуниору? И да, бонусом, есть примеры вопросов, но без ответов. Видимо предлагается поискать? Но джуну поиск не поможет (например, поиск «Подсчитайте общее количество слов, сохраненных в бору» приводит только на эту статью).
И это если не говорить о том, что простым поиском находится масса более полезной информации, например прямо тут.
публичный класс DbBackupper с одним простым методом CreateBackup(string path), который делает резервную копию БД.
Это плохой пример. Чтобы проверить бэкап нужен или инфраструктурный или интеграционный тест.
Более реалистичный пример — метод, который данные из БД тащит. У него под капотом и подключение к БД, и инициализация команды/запроса, и трансформация данных, и может что-то ещё. При этом полезная нагрузка — это инициализация параметров запроса/команды и трансформация данных. Правильный подход для покрытия тестами — отсечь всю инфраструктурщину, переложив её на кастомный (если надо) адаптер, оставив в изначальном методе вызов трёх методов: PrepareQuery, GetData, TransformData. GetData тестируется интеграционно, а в модульных тестах заменяется на заглушку. Два других метода имеют вполне понятные контракты, которые покрываются тестами. Более того, при таком рефакторинга запросто можно вытащить кучу однотипных методов, которые сольются в один… и станет в коде чище :)
есть метод, не являющийся методом интерфейса класса, но выполняющий нетривиальную логику. покрываешь его тестами так, чтобы быть уверенным в его 100% работе в известных случаях.
А если этот метод сделать публичным или превратить в прокси к публичному классу/методу — то и заморочки с непубличностью пропадут. У вас снова в тестах будут только публичные методы :)
Кстати, по вашей ссылке «Sprout Method» как раз про это.
Иначе говоря — не надо тестировать приватное. Надо сделать публичным и тогда тестировать.
Я говорю, что принцип хороший, но при чрезмерно педантном отношении к нему, может приводить к проблемам.
Чрезмерное отношение всегда плохо, везде.
Как я уже написал, TDD и legacy не совместимы в стартовой позиции, ибо в TDD тесты бы уже были. Их нет — у вас другая проблема. Для её решения есть другие методологии. Если кратко — рефакторинг вас спасёт.
Буду рад любым примерам того, как четкое следование данному принципу приводило к проблемам и снижению мотивации писать тесты у команды разработчиков.
Т.е. вы не только противоречите общепринятым нормам, но ещё и просите у общественности помощи в свержении норм???
Есть многое, что вам можно ответить на этот призыв… Но, пожалуй, хватит одного: «чёткое следование принципам» нередко оказывается итальянской забастовкой :)
Иначе говоря, цель должна определять необходимый инструментарий. Если цель у вас неверная — то и традиционный инструмент будет казаться кривым.
А касательно именно тестов — у вас проблема в другом месте. Вы имеете blackmagic box, который в дебрях своих что-то там делает. Такое не тестируют юнит-тестами. Первое, что нужно сделать, так это опубликовать поведение этого ящика. Должно получится некоторое количество открытых контрактов, которые вместе реализуют бизнес-задачу. Да, если у там и правда сложнозависимый алгоритм — под каждый сценарий придётся писать конфигурацию. Но философия TDD в том, что эта конфигурация есть описание предусловий сценария, а результат теста есть соответствие поведения ожиданиям. И если уж совсем следовать канонам — набор тестов есть ТЗ. Меняются требования — меняется ТЗ — меняются тесты — корректируется код.
И это если не говорить о том, что бы у вас был TDD, описанная проблема была бы совсем невозможна…
Да, легаси без тестов несовместимо с TDD. Даже просто unit-тесты прикрутить — надо постараться, но оно того порой стоит. А если не стоит — не надо ругать TDDЮ, надо выбирать подходящий инструмент — например интеграционные автотесты.
Вот уж и правда, написали бы сначала, какую конкретно проблему решаете и на каких ресурсах.
Потому как и в качестве универсального АПИ ваше решение не годится (о чём уже написали), да и польза от него при работе с MSSQL или Oracle весьма сомнительна. На «больших» СУБД, как уже было замечено, правильные индексы и запросы позволяют движку очень эффективно отбрасывать лишние записи.
И да, на совсем больших датасетах уже приходится строить предвыборки и даже хранить их каким-либо образом, иначе быстро апи не сделать.
Что-то все устали указывать вам на ошибки…
Для начала, ответ на вопрос «в какой ИСО покоится источник света» говорит лишь о том, как можно будет сравнивать эти ИСО относительно этого источника. Самому свету пофиг на обе ИСО.
Далее, попытаюсь пояснить, суть «фокуса» вокруг скорости света на более простом примере.
Предположим, что вы на космическом корабле бороздите космические просторы со скоростью c-100 m/c. Корабль ваш имеет спереду штангу длиной 100 m с зеркалом на конце. Вы делаете эксперимент: светите лазером с мостика в это зеркало. Как быстро до вас долетит отражённый свет? Наивный ответ — через две секунды (это если свет распространяется с постоянной скоростью в окружающем пространстве). Правильный ответ — почти мгновенно (~7e-7, и это если его скорость всё те же 3e+8 m/c относительно вашего корабля). Но вот вопрос: с какой же скоростью распространяется свет? Ведь если скорость света относительно вашего корабля всё та же c, то для внешнего наблюдателя она будет почти 2*c. Фокус в том, что относительно внешнего наблюдателя вы сжимаетесь в размерах, и, более того, меняется ваше локальное восприятие времени. Точнее говоря, для вас лично меняются размеры внешнего пространства и скорость наблюдаемых явлений. А ещё точнее, эти искажения отражают лишь способ сравнения процессов в двух ИСО, двигающихся относительно друг друга. При этом само пространство никак не меняется, как и его ключевые константы.
В вашем эксперименте с платформами вы попытались про эти искажения не забыть (рисуя сжимающиеся платформы), но получилось плохо — про время вы забыли. Попробуйте его добавить в ваши формулы. Для ИСО Б время полёта фотона будет больше относительно того же фотона в ИСО А. Если это нарисовать, то получатся треугольники центр-ловушка-точка «перпендикуляра» на траектории платформы. Эти треугольники связаны через относительную скорость ИСО. Если в одной ИСО вы совмещаете линию от центра до траектория движения платформы и линию центр-ловушка, то во второй ИСО совместить их не получится.
«Т.е. он утверждает, что для неких ИСО – траектория полета фотона будет «неперпендикулярной» — я имел ввиду, что если в ИСО А фотон летит перпендикулярно платформе Б, то в ИСО Б, движущейся относительно ИСО А этот фотон уже не будет лететь перпендикулярно (точнее лететь-то он будет так же, а вот угол между направлением на центр и направлением полёта будет ненулевым). Далее вопрос только в точке отсчёта. Если тот момент, когда две ловушки и центр на одной линии — то фотон пролетит мимо платформы Б…
А что толку менять платформы на электроны? Суть не меняется. Вам уже выше давали ссылку на описание Аберрации. Где ясно описано, что если видимое направление луча таки зависит от относительной скорости ИСО (но не зависит от скорости источника света). Итого, если источник света один, то направление полёта фотона видится разным с разных ИСО (т.е. вектора не на одной линии).
А можете сказать, что за волшебные у вас наблюдатели, которые видят, куда выстрелил лазер до того, как хотя бы один фотон прилетел к ним?
С другой стороны, если за ИСО брать платформу Б, то мимо неё пролетает и платформа А и лазер. И если уж мы на платформе Б поймали фотон, то в момент выстрела лазер ещё не долетел до условного перпендикуляра, соединяющего ловушки.
А если уж у нас есть наблюдатель, стоящий за пультом лазера — то он находится в третьей ИСО…
Короче говоря, вы сначала обоснуйте симметричность ваших наблюдателей, у которые есть большая проблема с одновременностью.
«На самом деле» я хочу разобраться, как этот эксперимент может выглядеть в реальной жизни, без кардиналов и д'артаньянов.
Тут надо и с пространством и временем определяться.
Если с точки зрения платформы Б сфера неподвижна и фотон влетает в ловушку, то с точки зрения внешнего наблюдателя, вспышка была впереди по курсу платформы Б и произошла раньше, чем фотон таки попал в ловушку.
Если фотон с той же вспышки попал в ловушку платформы А, которая с точки зрения внешнего наблюдателя была неподвижна относительно центра вспышки, то с точки зрения платформы Б, платформа А двигалась, но удачно попала под фронт расширяющейся сферы.
Наверно важнее обратить внимание на тот факт, что появление вспышки не одновременно с точки зрения платформ. Между ними есть релятивистский сдвиг.
А я и не говорил, что сфера движется. Но такого видение с точки зрения платформы Б. Реальность же в том, что платформа Б пролетает мимо сферы.
Ровно также с платформы Б кажется, что пролетает и сжимается платформа А, которая на самом деле стоит на месте.
А про фотоны и постоянство скорости света — так речь вроде про то, что скорость испускаемых фотонов не зависит от скорости источника света. В рамках рассматриваемого эксперимента это говорит лишь о том, что не важна скорость источника вспышки. Но если мы движется относительно центра вспышки, то к нам свет долетит с доплеровским сдвигом (он же даёт красное смещение в нашей разбегающейся вселенной).
Я тоже не спец по СТО… но вижу проблему в самой постановке эксперимента.
Во-первых, тут есть три ИСО: две платформы и точка возникновения вспышки.
Во-вторых, т.к. в фокусе эксперимента находятся фотонные датчики, то рассматривать результат события надо именно с их точки «зрения». А для них важно только то, как движутся фотоны. Что там делает вторая платформа — это пусть она сама разбирается.
Т.е. в представленном эксперименте, с точки зрения датчика на платформе А источник вспышки неподвижен, фотон летит прямо в ловушку. С точки зрения датчика на платформе Б источник света движется, а вместе с ним движется и сфера из фотонов, что приводит к непопаданию фотона в ловушку.
Во всяком «лучше» всегда есть прибавки «где» и «когда». Без них ваше «лучше» ничем не лучше остальных :)
Недаром тут столько возражений нашлось — у всякого разработчика с широким опытом есть куча примеров того, как ограничивает и мешает минимизация.
Попытка выделить «главный паттерн программирования вообще» должна была прийти к настолько общей идее, чтобы она оказалась не противоречащей ни сама себе, ни накопленному опыту признанных мастеров. Ведь другие паттерны не на пустом месте возникли…
Если бы я попытался выразить словами такой общий «паттерн», то получилось бы что-то вроде «Главная задача в программировании — это минимизация суммарных затрат на удовлетворение максимальных потребностей, как заказчика, так и исполнителя, включая будущие потребности и затраты».
(можно бы и без явного упоминания будущих, но, как показывает практика, слишком часто про них забывают)
Важно то, что учитывать надо и наши потребности. И не только в зарплате. Технологии поизучать хочется? Пощупать новый фреймворк? Вообще делать что-то нескучное? И время для личной жизни сберечь? И здоровье?
Сама формулировка не сильно новая, примерно так выражается большое число математических задач, в том числе пришедших из чисто практических потребностей. Но есть один огромный нюанс, отличающий программирование. Мы часто имеем деле с неограниченным количеством неопределённых потребностей. Например, задача постройки моста через реку. Там сходу можно накидать сведений по транспортной нагрузке, условиям эксплуатации и даже требований к внешнему виду. Потребностей много, но всё же они перечислимы и большую часть можно точно померять, включая прибыть подрядчика. Задача разработчика — минимизации затрат на строительство и обслуживание. А если мы пишем интернет-магазин, то какие потребности нам учесть? Сколько посетителей/покупателей/товаров/заказов? Да какие вообще планы у бизнеса? магазин-однодневка или будущий алиэкспресс? Код писать будет один разработчик или толпа? а учесть ли финансовый учёт? или заложить меры противодействия взлому/слому со стороны конкурентов? И т.д. и т.п… В реальной жизни хорошо если у заказчика окажется пара готовых ответов. Да и то, он может передумать, когда узнает цену… Поэтому важно умело расставлять рамки, ограничивая поле расчёта, но при этом не оставить за бортом нечто очень важное.
Одна проблема — этот «паттерн» не даёт универсальной рецептуры.
Если подходить к разработке с оглядкой на финансовую модель — много и ясно становится, и договориться с заказчиком проще. Но есть пара областей, где это плохо получается. Первая — внутренний заказчик. Обычно хочет чтобы быстро и дёшево, но сильно негодует, что потом оказывается долго и дорого. Проблема существенна, если не удаётся донести соответствие технический решений и финансовых результатов. Вторая область — это нефинансовые отношения. Друзья, опенсорс и т.д. Тут вместо отсутствующих денег начинают играть психологические мотивы. Кому-то хочется попробовать что-то новое, кому-то сделать монументально-крутое, кому-то отделаться от задачи, отказаться от которой нет желания…
Надо ещё понимать, что в любой из ситуаций могут присутствовать косвенные бонусы для все участников, как-то нематериальные мотиваторы (гордость, чувство глубокого внутреннего удовлетворения...), так и потенциальные будущие прибыли (если не стыдно проект в портфолио положить). Но эти инструменты уже очень индивидуальны и склоны меняться прямо в процессе, по не зависящим, так сказать.
А самое простое решение поставленной проблемы имеет классическое описание: вместо мутной логики в приватном методе делаем публичный класс, в который помещаем ту же самую логику и пишем столько тестов, сколько захотим. Приватный метод превращается в банальное обращение к этому классу и уже не требует собственных тестов.
Реальная же проблема, которая наблюдается в вашем примере, и присутствует в куда более жёстких проявлениях во всякий древних проектах — это макаронный код, где вперемешку логика и работа с внешним состоянием и внешними сервисами. Вот там да, на первый полезный тест можно пару недель убить…
«Важнейшие структуры данных» — скорее основные, не более того, да и то не все…
«которые вам следует знать к своему собеседованию по программированию » — вот тут совсем не правда. Уровень изложения совсем не соответствует тому, что реально могут спросить на собеседовании по программированию. Разве только совсем-совсем джуниору? И да, бонусом, есть примеры вопросов, но без ответов. Видимо предлагается поискать? Но джуну поиск не поможет (например, поиск «Подсчитайте общее количество слов, сохраненных в бору» приводит только на эту статью).
И это если не говорить о том, что простым поиском находится масса более полезной информации, например прямо тут.
Более реалистичный пример — метод, который данные из БД тащит. У него под капотом и подключение к БД, и инициализация команды/запроса, и трансформация данных, и может что-то ещё. При этом полезная нагрузка — это инициализация параметров запроса/команды и трансформация данных. Правильный подход для покрытия тестами — отсечь всю инфраструктурщину, переложив её на кастомный (если надо) адаптер, оставив в изначальном методе вызов трёх методов: PrepareQuery, GetData, TransformData. GetData тестируется интеграционно, а в модульных тестах заменяется на заглушку. Два других метода имеют вполне понятные контракты, которые покрываются тестами. Более того, при таком рефакторинга запросто можно вытащить кучу однотипных методов, которые сольются в один… и станет в коде чище :)
Кстати, по вашей ссылке «Sprout Method» как раз про это.
Иначе говоря — не надо тестировать приватное. Надо сделать публичным и тогда тестировать.
Как я уже написал, TDD и legacy не совместимы в стартовой позиции, ибо в TDD тесты бы уже были. Их нет — у вас другая проблема. Для её решения есть другие методологии. Если кратко — рефакторинг вас спасёт.
Т.е. вы не только противоречите общепринятым нормам, но ещё и просите у общественности помощи в свержении норм???
Есть многое, что вам можно ответить на этот призыв… Но, пожалуй, хватит одного: «чёткое следование принципам» нередко оказывается итальянской забастовкой :)
Иначе говоря, цель должна определять необходимый инструментарий. Если цель у вас неверная — то и традиционный инструмент будет казаться кривым.
А касательно именно тестов — у вас проблема в другом месте. Вы имеете
blackmagic box, который в дебрях своих что-то там делает. Такое не тестируют юнит-тестами. Первое, что нужно сделать, так это опубликовать поведение этого ящика. Должно получится некоторое количество открытых контрактов, которые вместе реализуют бизнес-задачу. Да, если у там и правда сложнозависимый алгоритм — под каждый сценарий придётся писать конфигурацию. Но философия TDD в том, что эта конфигурация есть описание предусловий сценария, а результат теста есть соответствие поведения ожиданиям. И если уж совсем следовать канонам — набор тестов есть ТЗ. Меняются требования — меняется ТЗ — меняются тесты — корректируется код.И это если не говорить о том, что бы у вас был TDD, описанная проблема была бы совсем невозможна…
Да, легаси без тестов несовместимо с TDD. Даже просто unit-тесты прикрутить — надо постараться, но оно того порой стоит. А если не стоит — не надо ругать TDDЮ, надо выбирать подходящий инструмент — например интеграционные автотесты.
— как, опять? Да сколько можно???
— Ну есть ли тут хоть что-то полезное??
— Зато рекламу впихнули :(
Вот серьёзно, этот список вопросов к контрольной по структурам для школы/первого курса вы перевели только для саморекламы?
Точнее говоря, знаю наверняка.
Потому как и в качестве универсального АПИ ваше решение не годится (о чём уже написали), да и польза от него при работе с MSSQL или Oracle весьма сомнительна. На «больших» СУБД, как уже было замечено, правильные индексы и запросы позволяют движку очень эффективно отбрасывать лишние записи.
И да, на совсем больших датасетах уже приходится строить предвыборки и даже хранить их каким-либо образом, иначе быстро апи не сделать.
Для начала, ответ на вопрос «в какой ИСО покоится источник света» говорит лишь о том, как можно будет сравнивать эти ИСО относительно этого источника. Самому свету пофиг на обе ИСО.
Далее, попытаюсь пояснить, суть «фокуса» вокруг скорости света на более простом примере.
Предположим, что вы на космическом корабле бороздите космические просторы со скоростью c-100 m/c. Корабль ваш имеет спереду штангу длиной 100 m с зеркалом на конце. Вы делаете эксперимент: светите лазером с мостика в это зеркало. Как быстро до вас долетит отражённый свет? Наивный ответ — через две секунды (это если свет распространяется с постоянной скоростью в окружающем пространстве). Правильный ответ — почти мгновенно (~7e-7, и это если его скорость всё те же 3e+8 m/c относительно вашего корабля). Но вот вопрос: с какой же скоростью распространяется свет? Ведь если скорость света относительно вашего корабля всё та же c, то для внешнего наблюдателя она будет почти 2*c. Фокус в том, что относительно внешнего наблюдателя вы сжимаетесь в размерах, и, более того, меняется ваше локальное восприятие времени. Точнее говоря, для вас лично меняются размеры внешнего пространства и скорость наблюдаемых явлений. А ещё точнее, эти искажения отражают лишь способ сравнения процессов в двух ИСО, двигающихся относительно друг друга. При этом само пространство никак не меняется, как и его ключевые константы.
В вашем эксперименте с платформами вы попытались про эти искажения не забыть (рисуя сжимающиеся платформы), но получилось плохо — про время вы забыли. Попробуйте его добавить в ваши формулы. Для ИСО Б время полёта фотона будет больше относительно того же фотона в ИСО А. Если это нарисовать, то получатся треугольники центр-ловушка-точка «перпендикуляра» на траектории платформы. Эти треугольники связаны через относительную скорость ИСО. Если в одной ИСО вы совмещаете линию от центра до траектория движения платформы и линию центр-ловушка, то во второй ИСО совместить их не получится.
С другой стороны, если за ИСО брать платформу Б, то мимо неё пролетает и платформа А и лазер. И если уж мы на платформе Б поймали фотон, то в момент выстрела лазер ещё не долетел до условного перпендикуляра, соединяющего ловушки.
А если уж у нас есть наблюдатель, стоящий за пультом лазера — то он находится в третьей ИСО…
Короче говоря, вы сначала обоснуйте симметричность ваших наблюдателей, у которые есть большая проблема с одновременностью.
Тут надо и с пространством и временем определяться.
Если с точки зрения платформы Б сфера неподвижна и фотон влетает в ловушку, то с точки зрения внешнего наблюдателя, вспышка была впереди по курсу платформы Б и произошла раньше, чем фотон таки попал в ловушку.
Если фотон с той же вспышки попал в ловушку платформы А, которая с точки зрения внешнего наблюдателя была неподвижна относительно центра вспышки, то с точки зрения платформы Б, платформа А двигалась, но удачно попала под фронт расширяющейся сферы.
Наверно важнее обратить внимание на тот факт, что появление вспышки не одновременно с точки зрения платформ. Между ними есть релятивистский сдвиг.
Ровно также с платформы Б кажется, что пролетает и сжимается платформа А, которая на самом деле стоит на месте.
А про фотоны и постоянство скорости света — так речь вроде про то, что скорость испускаемых фотонов не зависит от скорости источника света. В рамках рассматриваемого эксперимента это говорит лишь о том, что не важна скорость источника вспышки. Но если мы движется относительно центра вспышки, то к нам свет долетит с доплеровским сдвигом (он же даёт красное смещение в нашей разбегающейся вселенной).
Во-первых, тут есть три ИСО: две платформы и точка возникновения вспышки.
Во-вторых, т.к. в фокусе эксперимента находятся фотонные датчики, то рассматривать результат события надо именно с их точки «зрения». А для них важно только то, как движутся фотоны. Что там делает вторая платформа — это пусть она сама разбирается.
Т.е. в представленном эксперименте, с точки зрения датчика на платформе А источник вспышки неподвижен, фотон летит прямо в ловушку. С точки зрения датчика на платформе Б источник света движется, а вместе с ним движется и сфера из фотонов, что приводит к непопаданию фотона в ловушку.
Недаром тут столько возражений нашлось — у всякого разработчика с широким опытом есть куча примеров того, как ограничивает и мешает минимизация.
Попытка выделить «главный паттерн программирования вообще» должна была прийти к настолько общей идее, чтобы она оказалась не противоречащей ни сама себе, ни накопленному опыту признанных мастеров. Ведь другие паттерны не на пустом месте возникли…
Если бы я попытался выразить словами такой общий «паттерн», то получилось бы что-то вроде «Главная задача в программировании — это минимизация суммарных затрат на удовлетворение максимальных потребностей, как заказчика, так и исполнителя, включая будущие потребности и затраты».
(можно бы и без явного упоминания будущих, но, как показывает практика, слишком часто про них забывают)
Важно то, что учитывать надо и наши потребности. И не только в зарплате. Технологии поизучать хочется? Пощупать новый фреймворк? Вообще делать что-то нескучное? И время для личной жизни сберечь? И здоровье?
Сама формулировка не сильно новая, примерно так выражается большое число математических задач, в том числе пришедших из чисто практических потребностей. Но есть один огромный нюанс, отличающий программирование. Мы часто имеем деле с неограниченным количеством неопределённых потребностей. Например, задача постройки моста через реку. Там сходу можно накидать сведений по транспортной нагрузке, условиям эксплуатации и даже требований к внешнему виду. Потребностей много, но всё же они перечислимы и большую часть можно точно померять, включая прибыть подрядчика. Задача разработчика — минимизации затрат на строительство и обслуживание. А если мы пишем интернет-магазин, то какие потребности нам учесть? Сколько посетителей/покупателей/товаров/заказов? Да какие вообще планы у бизнеса? магазин-однодневка или будущий алиэкспресс? Код писать будет один разработчик или толпа? а учесть ли финансовый учёт? или заложить меры противодействия взлому/слому со стороны конкурентов? И т.д. и т.п… В реальной жизни хорошо если у заказчика окажется пара готовых ответов. Да и то, он может передумать, когда узнает цену… Поэтому важно умело расставлять рамки, ограничивая поле расчёта, но при этом не оставить за бортом нечто очень важное.
Одна проблема — этот «паттерн» не даёт универсальной рецептуры.