все равно не понимаю, чем этот аргумент плох. усилия должны быть пропорциональны их необходимостью и на коротких проектах смысла напрягаться нету. вообще не понимаю почему такая сильная забота о подерживаемости. ну то есть хорошо, когда вносить изменения легко и просто, но и обратная ситуация тоже не так уж и плохо. возможно во мне говорят годы работы над легаси проектами и над проектами живущими не больше года-полутора, мне казалось это общее состояние всего энтерпрайза. вы приходите на проект, дружно активно пилите в первые полгода год, а дальше ленивый фикс багов пока всех с проекта не заберут на очередной такой корабль.
ну то есть лично меня всегда восхищало, когда что то реализовано красиво в моих глазах - какие то высокоэффективные алгоритмы или написано на столько интересно и запутанно, что пока распутаешь - весь блокнот покроешь таинственными символами. лично мне это интересно и совершенно не понятно, как может вообще кого то интересовать писать например юнит тесты что бы они что то отображали и как то документировали. ну то есть возращаясь к фейк объектам - все усилия потраченные на фейкобъекты на мой взгляд лучше потратить на стремные юнит тесты с моками и на человеческую документацижю написанную на естесственном языке. ее хотя бы можно читать.
> все усилия потраченные на фейкобъекты на мой взгляд лучше потратить на стремные юнит тесты с моками и на человеческую документацижю написанную на естесственном языке. ее хотя бы можно читать.
Документация устаревает, при этом ни компилятор ни линтеры никогда не проверят ее на актуальность, все это ложится грузом на команду. Неактуальная дока хуже отсутствующей, так как ведет исключительно к заблуждениям, и потом все равно придется смотреть в первоисточник. Стремные юнит тесты же — хуже чем вообще их отсутствие, мало приятного при написании кода ловить и фиксить еще и фолс-позитивы. Если по нормальному юнит тесты не пишутся, лучше уж заложиться в тесты уровнем выше — АПИ, там, регрессионные, е2е...