IA
Size: a a a
2016 December 06
SP
тесты я так понимаю ты не пишешь, потому забудем о них
IA
Почему же
SP
были ли у тебя регрессии, связанные с тем, что ты изменил что-то в цепочке наследования, и где-то что-то отвалилось?
IA
Нет, слежу за этим
SP
Ну да
то есть, боль таки есть?
AK
вообще, надо понимать зачем все. Вопрос в простом внесении изменений. Если в вашу бизнес-логику идет много изменений, то ее надо хорошо покрывать спеками, если хорошо покрывать спеками, то их много, если их много, то они медленно гоняются из-за количества. Если ваша бл еще трубует какую-то лишнюю инфраструктуру(базу, http, fs), то еще в тестах идут задержки и на эту ерунду
SP
или ты во всем винишь "авторов изменений"?
SP
Нет, слежу за этим
как так то? А баги кто фиксит?
IA
Никого не виню, принимаю как естественный процесс мироздания
AK
Нет, слежу за этим
а сколько SLOC в проекте? Именно вашего кода, который поддерживаете, а не 3rd
IA
Баги и костыли всегда были и будут независимо от модели разработки
SP
в целом да - главное уяснить что если требования меняются часто (у меня например недавно был проект где требования менялись несколько раз в неделю причем клиент скрывал от нас часть своих планов, либо просто не знал что ему нужно)
SP
Баги и костыли всегда были и будут независимо от модели разработки
да, так и есть. Вопрос в том, как минимизировать ущщерб
SP
если у тебя требования прописаны от и до, и никаких изменений - то фигачь как хочешь, все будет ок
SP
тут как раз подходы в духе "наследуй воруй убивай" работают только в путь
SP
тот же Yii как пример)
2016 December 07
SP
а если требования меняются часто? Или ты понятия не имеешь на данный момент что на что влияет, то нужно вводить избыточность, дробление (декомпозиция если по другому)
SP
что бы минимизировать риски
AK
тут как раз подходы в духе "наследуй воруй убивай" работают только в путь
ну если требований так много, что все за раз в голову не влазят, то тут все-таки не покатит. Потому что по сути изменения требований здесь что-то аналогичное прочтению следующего тома документации)