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

Это пушто они книжки не читали нормальные ))

Это пушто они книжки не читали нормальные ))

смотрел много лекций) много думал, есть много хороших знакомых с которыми за пивом можно пофилосовствовать на тему "почему все не так"

что угодно

К алана кея лучше, все - объект :))

К алана кея лучше, все - объект :))

да но люди ж неверно понимают

заметь... почти все его крутые мысли некой двусмысленностью обладают

тип "Так, у нас есть концепт который заключается в message passing и late binding... давайте назовем это ООП"

почти как у Тургве с MVC)

или Тругве... ох и сложное у него имя

а object с зачем делали?

так я ответил на вопрос?

Да спасибо)

Интересно было почитать

Да спасибо)

заходи накидывай еще)

вот я за разработку в целом хочу

накинуть

за test-first approach

p.s. ищу людей которые делают недо-микросервисы. то есть микросервисы но без разделения на отдельные системы с отдельными базами данных. Тот же уровень и принципы изоляции но без усложнений вида "сделаю я это как распределенную систему с IPC или общением по сети"

за test-first approach

норм. основная цель - продумать что ты делаешь и зачем. Основная ошибка большинства - это не про тесты.

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

или Тругве... ох и сложное у него имя

Тругве

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

за test-first approach

Я проникся, когда начал юзать для проектирования. Вместо юмла наверное или еще каких штук. При этом большая часть тестов потом удаляется)

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

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

ну мол test-first это больше про декомпозицию

или Тругве... ох и сложное у него имя

А вот фамилия вообще анриал))

А вот фамилия вообще анриал))

я даже не пытаюсь

но как именно моя штука будет выглядеть внутри - я не знаю. наверно мне нужен будет какой-нить ApiProxy, который будет возвращать какой-то ApiResponseObject (потому что там сложный набор данных), нужен будет типа штука-из-хранилища-репозиторий и прочее

так вот вопрос

но как именно моя штука будет выглядеть внутри - я не знаю. наверно мне нужен будет какой-нить ApiProxy, который будет возвращать какой-то ApiResponseObject (потому что там сложный набор данных), нужен будет типа штука-из-хранилища-репозиторий и прочее

test-fist про то как твоя штука будет выглядеть снаружи

как начать разработку моей херни в стиле тест0ферст

вот да

но снаружи у нее очень много разного поведения

и много с чем она должна взаимодействовать

но снаружи у нее очень много разного поведения

это не та наружка

сложные данные вытаскивать и возвращать

сложные данные вытаскивать и возвращать

давай на концретном сферическом примере

задача этого модуля?

Пробуй test by example

Бери конкретный запрос и конкретный ответ

ну вот пример

И думай как из а пришло в б

делаю интеграцию с внешним сервисом, сквозную авторизацию

если мне в запросе пришел некий токен, я отправляю его в api, и потом ответ апи добавляю к объекту "текущий юзер"

с чего начать?

с интерфейса

забудь пока о том что тебе надо стучаться в апишки и прочее

вот пришел тебе запрос с токеном

что дальше?

как будет называться объект который это хэндлит, как будет называться метод

это легко, это есть

щас чуть больше подробностей накину

щас чуть больше подробностей накину

погоди

у тебя выходит эта штука уже есть

интерфейс есть

сколько публичных методов у этого интерфейса?

один?

один - отпроцессить токен

ну тип "проведи сквозную аутентификацию"

окей

один метод. Интерфейс мы придумали

теперь мы должны как-то через этот один публичный метод проверить что объект который мы реализуем соблюдает контракт

для этого нам надо определить что все работает и выделить "что будет происходить когда что-то не так"

если мы не говорим про принципы типа SOLID и говорим только про test fist то по сути ты через этот один метод проводишь все тестирование

если ты видишь что тебе становится неудобно - надо увеличить уровень декомпозиции

например у тебя есть куча подводных камней при работе с внешним сервисом

ну вот и начинается, я должен определить зависимости, их засунуть в мою штуку и проверить, что она их в нужном порядке дергает

ERROR: S client not available

ну вот и начинается, я должен определить зависимости, их засунуть в мою штуку и проверить, что она их в нужном порядке дергает

эм... не понял

ну суть такая

ну метод типа такого void processToken(string token)

ну метод типа такого void processToken(string token)

а почему void?

он лио кинет исключение либо просто завершится?

он ничего не возвращает

да

а ну ок

то есть по сути нам нужен тест кейс при котором нет исключений и далее будем делать триангуляцию тест кейсами которые кидают исключения

короч...

идея в том что у тебя при тестировании всей твоей жирной логики через интерфейс одного объекта в какой-то момент станет слишком сложным составление тест кейсов и написание тестов

выход - мы можем отдельные вещи вынести в свои объекты (которые будут зависимостями твоего) со своим контрактом и писать тесты на соблюдение объектами этих контрактов.

в этом случае тебе надо лишь убедиться что твой основной объект тупо его дергает

правильно, я так и делаю

и так постепенно у тебя вся логика будет разделяться по объектам отдельным которые удобно проверять и тестить

дада, именно так

но, в чем засада

а потом, когда у тебя в твоем основном объекте не останется логики, и он будет заниматься только делигированием

ты просто удаляешь тот несчастный тест с моками

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

я определил контракты моего ApiProxy и моего скажем UserRepository

и они получились сложными, там много взаимодействия происходит между ответом апишки и репой юзеров

а потом херак и апи поменялся

оказалось, что я все не так как надо напрогнозировал

типа юзер уже не по полю email достается, а по account_id например

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

и они получились сложными, там много взаимодействия происходит между ответом апишки и репой юзеров

кто за это взаимодействие отвечает?

вот эта моя основная штука,

она отвечает

так... у тебя в основной штуке есть if-ы?

есть

плохо