Здравствуйте, Sinclair, Вы писали:

S>Ну вот и я не понимаю, о чём вы говорите, когда пишете, что половина не сделана.

Задача — "сделать отчёт по продажам в PDF". Детали, важные для программиста — это какие данные должны быть в отчёте, критерии отбора, формулы расчёта и т.п. Шаблон того же PDF — будет ли он фиксированным, или должен настраиваться. Если настраиваться, то кем и в каких пределах.
А вот то, делать ли этот отчёт сначала, а систему конфигурации потом, или же наоборот

Если в одной задаче есть сначала и потом, то это две половины. Не слишком сложно?

PJ>>Вот это точно негодный тул, так как по-определению тест должен упасть, пока ты его не исправишь. Или твой тул еще и тест дописывает?
S>Ясно. Вижу, что рефакторинг вы видели только по телевизору. Ознакомьтесь, с тем, как работают реальные, а не воображаемые инструменты: https://www.jetbrains.com/help/resharper/Refactorings__Introduce_Parameter.html
S>Добавление параметра поправит все call sites, включая, естественно, тесты. А иначе нахрена такой рефакторинг нужен?
Ну, я рад, что благодаря jetbrains ты открыл для себя "реальный" рефакторинг, а не застрял на переименовании. Но я не понял, что ты этим хотел сказать? Если функция меняется, то контролирующий ее метод должен упасть. Иначе нафига такие тесты нужны?! А если тест падает, то это неправильный рефакторинг (с) потому что меняет поведение. Видимо он правильный если его делает тул, а так неправильный.

S>(facepalm). Ну ок, пусть будет DTO объект. У нас, к примеру, всё выставлено наружу как JSON. И у этого JSON есть модель — schema. Она, естественно, соответствует той модели, которая внутри. И в этой схеме сказано, что подписка — обязательный атрибут.
Мысль-то продолжи, это я тебе и сам написал, буквально в следующей цитате и было.

PJ>>Конечно является, это часть контракта. Если тебе нужна подписка, то подписка там быть должна. То, что ты сейчас предлагаешь это опять неявное соглашение и предположения. Я тебе говорю, что в одном api не обязательно смешивать мух с котлетами. Подписки отдельно, покупки отдельно. Инвариант один — модель, где либо подписка, либо покупка, а вот производные разные. Либо даже просто новый контракт, но где явно указано, что либо подписка, либо покупка, с разными dto внутри. grpc так позволяет, например, легко делать.
S>Да при чём тут grpc? Вы говорите про самый низкий уровень, неинтересные детали. Речь о том, что от изобретения нового контракта никакая магия не сделает всех клиентов старого контракта совместимыми с новым.
Ну с dto самый низкий уровень. Внезапно. Я думал ты знаешь. С другой стороны читаешь ты явно через специальный фильтр, не то, что я пишу.

S>Оплата — это передача денег. Ордер — это заказ. Если, допустим, пользователь Poopy Joe что-то заказал на 100 долларов, то его баланс уменьшился на 100 долларов.
S>Если пользователь заплатил 200 долларов, то его баланс увеличился на 200 долларов. Это вещи, мало связанные между собой.
S>Есть понятные любому менеджеру инварианты: баланс Джо равен сумме всех его платежей минус сумма всех заказов (пренебрегаем коррекциями).
S>Введение нового типа заказа означает, что либо мы ломаем сигнатуру методов по получению заказов, либо у нас ломается инвариант баланса.
S>Естественно, сломать сигнатуру методов — более хороший способ: таким образом мы получаем fail fast, и несовместимые клиенты падают сразу. А не продолжают молча рассинхронизовывать данные, приводя к утечке денег.
Опиши задачу полностью. Вот есть ордер на подписку. Что с этим знанием делали эти 100500 клиентов которые его получали.

PJ>>Опять не могу комментировать, поскольку я не знаю, что там содержится и что клиенту от них надо. Если клиенту важно знать про покупки, то ему надо переписывать, чтобы получить релевантную информацию.
S>Да, именно об этом и речь — надо переписывать.
А сейчас ты противоречишь ранее сказанному. Судя потому что вы вкорячили бесконечную подписку, на сам факт подписки клиентам плевать. Им надо что-то другое.

S>В том, что чудес не бывает, и если мы меняем модель, то это дорого стоит.
Тут нет никаких чудес, это управление зависимостями и "протечками" модели.

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

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

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

Здравствуйте, Sinclair, Вы писали:

S>Ну вот и я не понимаю, о чём вы говорите, когда пишете, что половина не сделана.

Задача — "сделать отчёт по продажам в PDF". Детали, важные для программиста — это какие данные должны быть в отчёте, критерии отбора, формулы расчёта и т.п. Шаблон того же PDF — будет ли он фиксированным, или должен настраиваться. Если настраиваться, то кем и в каких пределах.
А вот то, делать ли этот отчёт сначала, а систему конфигурации потом, или же наоборот

Если в одной задаче есть сначала и потом, то это две половины. Не слишком сложно?

PJ>>Вот это точно негодный тул, так как по-определению тест должен упасть, пока ты его не исправишь. Или твой тул еще и тест дописывает?
S>Ясно. Вижу, что рефакторинг вы видели только по телевизору. Ознакомьтесь, с тем, как работают реальные, а не воображаемые инструменты: https://www.jetbrains.com/help/resharper/Refactorings__Introduce_Parameter.html
S>Добавление параметра поправит все call sites, включая, естественно, тесты. А иначе нахрена такой рефакторинг нужен?
Ну, я рад, что благодаря jetbrains ты открыл для себя "реальный" рефакторинг, а не застрял на переименовании. Но я не понял, что ты этим хотел сказать? Если функция меняется, то контролирующий ее метод должен упасть. Иначе нафига такие тесты нужны?! А если тест падает, то это неправильный рефакторинг (с) потому что меняет поведение. Видимо он правильный если его делает тул, а так неправильный.

S>(facepalm). Ну ок, пусть будет DTO объект. У нас, к примеру, всё выставлено наружу как JSON. И у этого JSON есть модель — schema. Она, естественно, соответствует той модели, которая внутри. И в этой схеме сказано, что подписка — обязательный атрибут.
Мысль-то продолжи, это я тебе и сам написал, буквально в следующей цитате и было.

PJ>>Конечно является, это часть контракта. Если тебе нужна подписка, то подписка там быть должна. То, что ты сейчас предлагаешь это опять неявное соглашение и предположения. Я тебе говорю, что в одном api не обязательно смешивать мух с котлетами. Подписки отдельно, покупки отдельно. Инвариант один — модель, где либо подписка, либо покупка, а вот производные разные. Либо даже просто новый контракт, но где явно указано, что либо подписка, либо покупка, с разными dto внутри. grpc так позволяет, например, легко делать.
S>Да при чём тут grpc? Вы говорите про самый низкий уровень, неинтересные детали. Речь о том, что от изобретения нового контракта никакая магия не сделает всех клиентов старого контракта совместимыми с новым.
Ну с dto работает самый низкий уровень. Внезапно. Я думал ты знаешь. С другой стороны читаешь ты явно через специальный фильтр, не то, что я пишу.

S>Оплата — это передача денег. Ордер — это заказ. Если, допустим, пользователь Poopy Joe что-то заказал на 100 долларов, то его баланс уменьшился на 100 долларов.
S>Если пользователь заплатил 200 долларов, то его баланс увеличился на 200 долларов. Это вещи, мало связанные между собой.
S>Есть понятные любому менеджеру инварианты: баланс Джо равен сумме всех его платежей минус сумма всех заказов (пренебрегаем коррекциями).
S>Введение нового типа заказа означает, что либо мы ломаем сигнатуру методов по получению заказов, либо у нас ломается инвариант баланса.
S>Естественно, сломать сигнатуру методов — более хороший способ: таким образом мы получаем fail fast, и несовместимые клиенты падают сразу. А не продолжают молча рассинхронизовывать данные, приводя к утечке денег.
Опиши задачу полностью. Вот есть ордер на подписку. Что с этим знанием делали эти 100500 клиентов которые его получали.

PJ>>Опять не могу комментировать, поскольку я не знаю, что там содержится и что клиенту от них надо. Если клиенту важно знать про покупки, то ему надо переписывать, чтобы получить релевантную информацию.
S>Да, именно об этом и речь — надо переписывать.
А сейчас ты противоречишь ранее сказанному. Судя потому что вы вкорячили бесконечную подписку, на сам факт подписки клиентам плевать. Им надо что-то другое.

S>В том, что чудес не бывает, и если мы меняем модель, то это дорого стоит.
Тут нет никаких чудес, это управление зависимостями и "протечками" модели.

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

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

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