Size: a a a

Software Design/Architecture/Zen

2021 June 11

JF

Jorik Fat in Software Design/Architecture/Zen
точнее вместо двух: тесты + фича
источник

SP

Sergey Protko in Software Design/Architecture/Zen
тесты не отрежут необходимость менять еще в 4-х местах.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
если ты "проектируешь систему через тесты и используешь их для формирования контрактов" да, но ты можешь просто уметь проектировать контракты и тогда тот же результат у тебя будет без тестов
источник

JF

Jorik Fat in Software Design/Architecture/Zen
тесты покажут где в новой фиче внести изменения
источник

SP

Sergey Protko in Software Design/Architecture/Zen
не покажут)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
точнее как... либо это сможет показать любой статический анализ либо "написание теста" заставит тебя "подумать как делать фичу".
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ибо если ты не знал что "надо еще там подправить" то тесты тебе это не вскроют если ты не подумаешь про этот кейс
источник

SP

Sergey Protko in Software Design/Architecture/Zen
если тесты пишутся после реализации то и подавно не подумаешь
источник

K

KoBa4oG in Software Design/Architecture/Zen
тесты переоценены
источник

SP

Sergey Protko in Software Design/Architecture/Zen
в целом я вижу следующие проблемы в большинстве команд:

- код ревью - "2 апрува для мерджа а что там в мастере происходит плевать нет времени разбираться"
- accidental coupling - фичи которые нарушают границы хотя объективных причин для этого нет. Вот некоторые фанаты микросервисов сетуют что мол сложнее границы нарушать с ними а потому все должны микросервисы юзать.
- отсутствие явных границ - типичная проблема когда у тебя одна система с которой работают несколько команд.
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
а как рефачить все это дело без тестов? ну тоесть вообще. без. тестов.
источник

DK

Denis Ko in Software Design/Architecture/Zen
Без тестов рафачить-боль
источник

AV

Alexey Vetrov in Software Design/Architecture/Zen
Боль, но это возможно
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
ну тоесть сейчас есть просто куча кода который непонятен. Как его сделать понятным? Я вижу только тесты как первый этап и больше ничего другого
источник

AV

Alexey Vetrov in Software Design/Architecture/Zen
Денег на тесты и рефакторинг не выделили (с)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
it depends.

если есть тест кейсы и люди которые знают как система работает - нанимаешь автоматизаторов/контрактников что бы они максимально быстро тебе закрыли систему через силениумы апиумы end-to-end тестами. Так мы уменьшаем риски при не оч большой стоимости.

если тест кейсов нет и хуй пойми как это работает - то можно попробовать делать через strangler pattern не меняя изначальную систему. Это обычно дороже но альтернативы рисованнее.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
прикол в том что "с херовым дизайном" тесты на уровень ниже приемочных не оч покатательны и "как правило их можно просто удалить"
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Я то прогер, моя вотчина - проект в гите, масштабы совсем другие
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Мне вообще неинтересно понимать как работает код бэка на уровне юай
источник

DT

Dmitriy Tkachenko in Software Design/Architecture/Zen
Мне это не даст точек понимания, т.к. все знания в коде а интерфейс только частный случай использования
источник