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

P>>1 непосредственно удаляет, делает все виды работ
P>>2 всего лишь создает отложеные операции типа "удалить док по хешкоду", "выгрузить данные в s3 с ттл 1 месяц"
P>>С т.з. пользователя это ровно одна и та же функция. Ваши бизнес-требования не менялись.
·>Не понял, чем отличается 1 от 2? "все виды" это разве не "удалить"+"выгрузить"?

Разница в слове "отложенные". У вас недавно была проблема с этим словом. Решилась?

P>>Важно, что str.length() инлайнится гораздо эффективнее аналога для мутабельного контейнера или мутабельной ссылки. Вы слишкмо много придираетесь к каким то ничтожным деталям.
·>Не знаю что значит "гораздо эффективнее", но инлайнится она ровно так же. Ещё раз. Инлайн это убирание фрейма стека, ничего общего с мутабельностью.

str.length() можно заменить на str.chars.length и это будет какой то инлайн.
Если вы вызвали str.length() 100 раз у вас есть варианты:

1 везде проставить str.chars.length и это будет работать.
Но это совсем мало.
Компилятор может лучше и делает лучше!

2 можно один раз вызвать str.chars.length и в 99 остальных случаев прописать именно это значение как константу.

Собственно второй вариант возможен исключительно в потому, что str.chars во всех 99 случаях будет одна и та же. В джава строке именно так. Если вы делаете мутабельную строку, ну вот вздумалось вам, то компилятор не сможет вычислить, можно ли применять кейс 2, т.е. более глубокую оптимизацию, т.к. у него нет информации, что там в каждом из 99 случае.

P>>Пример как раз про функцию которая ломает ссылочную прозрачность.
·>Тогда это пример не про инлайнинг, а про иммутабельность.

Джава компилятор на основании иммутабельности умеет вводить кое какие оптимизации. Строки — одна из таких вещей.

P>>Щас вы конечно же скажете, что у вас такого никогда не бывает, и вы дизайн на все кейсы, возможные и невозможные, проектируете на 100 лет вперёд.
·>Можно, конечно. Но это не происходит непрерывно сто раз на дню как ты тут заявлял выше. Да, возможно раз в месяц надо поискать боттл-нек и как-то порефакторить.

"как то" Не как то, а вручную вместо работы компилятором и ИДЕ.

P>>Не любое. Изменение конфига сюда не подходит.
·>Конфиг это не код. Выделил жирным.

А протаскивание такого конфига — тот еще код. Особенно когда это все инжектится

P>>Изменения внутри одной функии — тоже.
·>Ну у меня внутри функции изменение и было для добавления кеша.

А LRU кеш связаный с конфигом, которые надо тащить через dependency injection не считается, да?

P>>Мемоизацией, естественно. Даже если LRU кеш с конфигом придется протащить — зависимости будут идти чз контроллер, а не абы где.
·>Итак, продолжаем разговор. Что будет ключом мемоизации для nextFriday(now)?

Про мемоизацию я трохи погорячился. Вам Синклер рядом ответил.

P>>Смешно. Вам нужно тестировать компонент без кеширования, и компонент с кешированием, просто потому что вы всунули всё это внутрь.
·>Вам тоже нужно.

Нет, не нужно — функция где БЛ никак не изменилась, ни внутри, ни снаружи. Изменилась исключительно интеграция.
В вашем случае вы перепахали внутрянку той самой функции

P>>А что мешает это без моков сделать?
·>Просвети как, с учётом того, что ты предложил использовать Time.now. КОД покажи.

Time.now будет приходить всегда снаружи. В чем вопрос, объясните?

P>>>>Вводится изоляция — вместо низкоуровневой зависимости на репозиторий появляется абстракция. Ровно то же делает фаулер, 'src/restaurantRatings/topRated.ts'
P>>·>Зачем? И чем это стало лучше?
P>>Проще код, больше контроля. Даже те же моки можно прикрутить безо всяких фремворков.
·>Почему он проще? Мне показалось ровно наоборот. А моки можно прикручивать без фреймворков в любом случае. Правда количество кода увеличивается.

С каких пор низкоуровневые приседания стали проще?

P>>Никуда не испарилась. Все один в один, как и у вас.
·>В mock({}).whenCalledWith('getTopRestaurants', 'ляляля').returns(restaurants) оно правда сможет вывести типы?! Что-то не верится...

У Фаулера код на жээсе. Я вам показал на жээсе. Теперь вы придираетесь, что де на Тайпскрипте будет чтото еще.
Вы все время тратите время на мелкие придирки.
Вот вам типы в TypeScript:

mock<AnInterface>().whenCalledWith('getTopRestaurants', 'ляляля').returns(restaurants)[/tt]

Что теперь, попросите показать как это всё типизуется?

P>>Это сказки вида "у нас проблем на проде не бывает"
·>Цитаты нет, ты опять врёшь. Опять свои фантазии помещаешь в кавычки и пытаешься выдать за мои слова.

Я вам много раз приводил примеры, ради чего нужно запускать такое, но вы упорно видите в этом исключительно доказательство проблем в разработке.
Тесты на проде нынче вариант нормы.

P>>Ну так чего вы конкретно просите показать?
·>Код на ЯП. Для тебя наверное это новость, но сообщаю: кукумбер — это не яп.

Это ЯП, декларативный, высокого уровня

P>>·>По-моему это про то как сопоставить тесты с требованиями. Я спрашивал о том, как узнать, что в списке требований ничего не упущено.
P>>Или код ревью, или некоторая формализация с последующей генерацией тестов, чтото навроде
·>Код ревью не укажет на пробелы в требованиях. Формализация — практически анреал, очень редкий зверь.

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

P>>Потому я и говорю, что лучше брать время прямо из реквеста.
·>Что значит "лучше"??! Это будет клиентское время, его можно подделывать. Более того, структура запроса диктуется требованиями внешнего api, а не желанием левой пятки, поэтому там его в принципе может не быть.

Структура запроса диктуется много чем кроме внешнего апи — протокол, фремворк, рантайм, операционка, итд. Всегда и везде технологических деталей в десятки раз больше чем бизнеслогики. В случае с хттп там разве что кофе не готовится

P>>Смотря какой этот один. Если тот, что только сравнивает выхлоп из базы — то нет, слабовато.
·>Сильнее, чем у тебя, т.к. хотя бы синтаксис запроса проверяют.

Ну и логика, как набор А, будет сильнее двух наборов А и Б ?

P>>Вы неверно понимаете тесты. Сначала вы находите свойство — это происходит в вашей голове. Потом находите, что его надо сохранить между версиям. Это тоже в вашей голове. А вот само сохранение это тест + процесс разработки, что там у вас, код ревью, итд.
·>Это "свойство" не эквивалентно работоспособности программы.

Нет такого "проверка работоспособности" — это менеджерский сленг. Есть выполнение сценариев А...Z, тесты для всевозможных ...ility, итд итд
То есть, находим конкретные свойства, которые покрываем тестами на том или ином уровне, в зависимости от вашего инструментария

P>>·>Вы не знаете, что такое кукумбер? Забавно. https://www.google.com/search?q=cucumber+glue+code
P>>Здесь будут примитивы вида резервирование, время операции и тд. Что коннкретно вы хотите узнать?
·>Как выглядит код.

Зачем?

P>>Именно. Только не обязательно приватные методы, это просто методы видимость которых ограничена некоторым модулем или пакетом.
·>Ты сам заявлял, что эти методы видны только с целью использования их в тестах: "fn1 и fn2 должны быть видны в тестах, а не публично". Т.е. твои тесты тестируют никому более невидимые внутренние кишки реализации. Это — отстой.

Голословно. Любой большой кусок кода нужно в первую очередь тестировать непосредственно. А вы предлагаете всё делать наоборот.

P>>Т.е. такие тесты это способ снимать инфу с прода в критические моменты, т.к. в дебаге, стейдже итд у вас точно этой инфы не будет.
P>>Не зеленую галку менеджерам показывать, а обнаруживать те вещи, которые в других условиях не видны
·>Верно, но это не единственный способ. И, мягко говоря, не самый лучший.

Вероятно у вас — не лучший. Зато куча компаний использует именно такой подход. Он сообщает куда больше проблем, чем ваши точечные пробы.