АГ
ну как бы фабрика и билдер разные вещи в принципе
Size: a a a
2021 December 17
AM
Лучше объяснять термином идемподентность (и как метод запроса с этим связан). Но рест тоже в тему
AM
+
A
Согласен, поэтому видимо буду кидать в ответах скрины из книги по патернам.
Когда класс только зародился и содержит пару методов, сложно дать ему слишком специфичное имя.
Повторюсь что смущает слишком сильная уверенность и директивность в требованиях по исправлениям, особенно учитывая что они основываются на субъективном понимании решения, а не на бест практис
Когда класс только зародился и содержит пару методов, сложно дать ему слишком специфичное имя.
Повторюсь что смущает слишком сильная уверенность и директивность в требованиях по исправлениям, особенно учитывая что они основываются на субъективном понимании решения, а не на бест практис
SP
в смысле не обращаться к истории? ты шо.
SP
если у тебя это все в одной ветке то в чем проблема сквошнуть коммиты? я понимаю если бы ты за счет этого сокращал разрыв между своей веткой и мастером. Но тут явно не тот случай.
SP
все коммиты должны быть атомарны. Описанные (тесты, имплементация, рефакторинг) не совсем атомарны. То есть тесты например да можно долить отдельным коммитом. А вот имплементация/рефакторинг уже подразумевают интеграцию изменений и как бы нет гарантий что все работает в каждом отдельном коммите.
я на это смотрю с позиции "для каждого коммита в мастере должен быть зеленый статус CI - а если у тебя зеленый статус только на мердж коммитах то фу"
я на это смотрю с позиции "для каждого коммита в мастере должен быть зеленый статус CI - а если у тебя зеленый статус только на мердж коммитах то фу"
КГ
DE
Это не только в мастере, а вообще ко всем коммитам можно применить.
DE
Можно сначала закоммитить тесты, помеченные как incompleted или тегом WIP, а потом следующим коммитом докинуть имплементацию.
KN
Это действо происходит только когда приходит кто-то и такой "а мы вот эту таску выложили или нет?". Причём таска должна быть месяц+ давности
КГ
В каждой компании процессы разработки, деплоя и релизов зачастую сильно различаются. Поэтому все эти набросы не имеют ценности без понимания как в твоём конкретном случае устроены эти процессы.
В твоём случае это "если только приходит", у остальных не так.
Впрочем я в гит не умею, не надо меня слушать
В твоём случае это "если только приходит", у остальных не так.
Впрочем я в гит не умею, не надо меня слушать
SP
ну у меня только мастер (trunk based development). я частенько игнорирую другие модели "ветвления"
SP
ну или "блин там баг ревертни а" или "надо вот эту фичу черепикнуть в релиз ветку" - или же "так а в рамках чего делали эту шляпу" - все это просто часть процесса разработки. И если там бакфиксы это может быть исключением из правил то...
КГ
Просто ты тоже в гит не умеешь, смирись
SP
угу, чего это линукс не по гитфлоу пилят
AN
а как его пилят кстати? по trunk based development?
DE
Отправкой патчей по емэйлу
SP
