🐴
так согласен
Sergei
аргументируй
Аргументирую.
Git - сервис, существующий за пределами нашего влияния, и изменить его поведение затруднительно. Он _уже_ предоставляет сервис, изменить/исправить который мы де-факто не можем.
Всякое наше приложение в любых раскладах будет использовать существующие возможности Git.
Создавая класс, организующий общение с Git, есть смысл определить поведение (созданием интерфейсного класса) - с набором методов, которые позволят нашему (дальнейшему) приложению общаться с Git.
Интерфейс оный что-то должен будет "делать", и иногда "возвращать".
Вот в этом месте неминуемо нам тут же необходимо договориться/пообещать, что именни и в какой форме будет этим нашим программным интерфейсом (фасадом к "настоящему" Git) возвращаться. Здесь естественным образом возникает определение структур данных, в терминах которых произойдёт общение с Git.
Далее, мы реализуем имплементапию этого интерфеиса - получаем git communication library.
Далее (хотя можем ирпараллельно, если интенфейс уже определён) мы пишем уже "клиентское приложение", которое интенфейсом пользуется.
🐴
но на более нзком уровне ДТО это все равно принадлежность интерфейса
Sergey
я выше привел ссылку на gist - глянь, совпадает с твоим пониманием проблемы?
Sergei
Гм
🐴
мне кажется у меня прояснились некоторые вещи
Sergei
Sergey
вся соль в изоляции и декомпозиции
Sergey
ну то есть ты можешь просто на бумажке рисовать схемки из операций... что тебе надо и т.д
🐴
вся соль в изоляции и декомпозиции
я фразы типа этой ежедневно слушаю через ютуб по дороге на работу
🐴
и обратно
Sergey
тип "сначала надо то-то то-то"
Sergey
потом "то-то то-то"
Sergey
ну мол... просто попробуй вместо того что бы сразу ебашить составить список того что надо сделать
🐴
только понимания не сильно добавляется
Sergey
ну мол "нужна хрань которая из git-а забирает лог"
Sergey
потом "нужна хрень которая из лога отфильтрует что-то"
Sergey
ну и т.д
Sergey
на этой задаче с гитом уже не так интересно тренироваться... можно попробовать придумать другую небольшую задачку
Sergey
желательно что-то что ты раньше не делал
🐴
мне очень интересно
🐴
я хочу ее довести до нормальной реализации
Sergey
я к тому что ты уже код написал и упражнение будет смазанным)
🐴
а
Sergey
хотя кто его знает
🐴
так я как написал так и сотру
🐴
я уже раза четыре заново начинал
Sergey
составь список "как это должно примерно работать". Не структуру классов, а тупо последовательность действий примерную. Атомарные операции отдельные которые нужно провернуть
Sergey
если не знаешь как что-то делается, то просто оставляй пункт "хрень которая умеет это делать"
Sergey
главное понимать что надо делать
Sergey
не придумавый имена операциям, не придумывай слоев
Sergey
тупо список действий))
🐴
а как называется херня, которая связывает приложение с представлением? контроллер?
Sergey
да
Sergey
но его не пиши
Sergey
вообще ничего про UI в этот список пока не пиши
Sergey
тебе сейчас надо приложение само по себе описать как работает
Sergey
юзер стори + критерии приемки
🐴
да мне бы импрементацию гита описать сначала
Sergey
ну вот я об этом и говорю
Sergey
только приложение
Sergey
без UI
🐴
а
🐴
т.е. сверху вниз строить структуру
Sergey
причем пиши абстрактно
Sergey
именно
🐴
сначала с пустыми интерфейсвами
Sergey
сверху вниз
Sergey
ну например... задача - надо сделать програмку которая формирует рейтинг коммитеров
🐴
вот конкретная задача - вывести спосок коммитов, добавленных в указанный тег
🐴
она уже сложная что пиздец
🐴
как ее реализовать?
Sergey
вот конкретная задача - вывести спосок коммитов, добавленных в указанный тег
- какая-то хрень должна забрать историю коммитов между двумя тегами
- какая-то хрень должна с этой историей что-то сделать
🐴
да
Sergey
ну вот, у тебя уже есть два сервиса)
Sergey
по сути сервис который сделает git log tag1..tag2
Sergey
и нормализует структурку возможно минимально
Sergey
и другая хрень которая на основе этой истории что-то сделает
Sergey
еще нужна будет хрень которая будет уметь выполнять команды
Sergey
что бы не через exec везде и всюду
🐴
еще надо получить список тегов
🐴
определить последний
Sergey
а тупо $this->process->run("");
🐴
или указанный
Sergey
главное что бы у тебя соблюдалось одно простое правило
🐴
то есть мне получается не нужен один интерфейс на GitGateway, а нужно ISP на каждую операцию?
Sergey
если тебе надо сделать работу, и есть более одног оспособа это сделать, лучше вынести эту операцию в отдельную хрень
Sergey
Sergey
может быть и 10
Sergey
кто тебя знает
Sergey
класс может быть один
🐴
ну вот я и говорю
🐴
нужен ISP
Sergey
возможно
Sergey
а еще тебе надо избавиться от exec-ов в гейтвее
🐴
это я уже сделал
Sergey
пусть за выполнение команд отвечает отдельная хрень