на тему "можно или нельзя" - обычно аргумент "если схему поменяем то там сломается" - но этот аргумент по хорошему должено перекрыть наличие приемочных тестов

+ IDE сегодня могут и это дело проверять

ну я не вижу тут связи с DRY или SRP. То есть вот у тебя есть структурка данных которая нужна на запись и для UI. У них будут разные причины для изменений (потому что для UI меняться будет чаще), ну и "дублирование" структур данных это не нарушение DRY.

DRY про принятие решений, про логику, про знание о том че как должно работать. Если у тебя в 10-ти классах надо одинаковое свойство с тайэмстэмпом когда чего менялось то это не повод "убирать дублирование". Люди часто это путают и создают монстров с высокой связанностью на ровном месте просто потому что "нам говорили что дублирование кода это плохо".

Спасибо за наводки! Будем разбираться

Господа, а подскажите, какой язык вы бы выбрали сегодня, не взирая на скилл и знания коллег текущей компании, для построения постоянно меняющегося бэкенда, чтобы поддерживать было максимально удобно?

php 8

Да это забавная и очень точная мысль.  Пока ты молод в тебя старшие коллеги вбивают DRY, и потом с годами тяжело вернуться к нормальному пониманию этого определения.

не пхпшники в этом чате отзовитесь)

такой язык еще не изобрели )

уверен, что большинство проголосовало бы за c#, будь он чуть распространённее

с распространенностью сишарпа есть проблемы?

к слову сказать, максимально гибкая и четко спроектированная, легко расширяемая система - вообще не про язык, а про скилл в проектирование, архитектуру, паттерны и вот это вот все

его не так много на рынке, чуть больше, чем nodejs бека

Да, тысячу раз уже этот разговор поднимался, что язык это инструмент, важно проектирование. Конечно. Но если взять, например, Kotlin и взять Perl 5, то как бы хороша архитектура ни была, на котлине поддерживать будет проще. Потому что статическая типизация, куча плюшек от IDE, асинхронщина и многое другое (в том числе то, что язык не мёртв)

А почему C# и PHP8, а не, например, Scala или Kotlin или F#?

да не знает их тут никто, тут пыхеры одни)

го возможно подойдет

у scala традиционные проблемы с ide и вообще хипстерство, kotlin проект будет испытывать трудности с поиском именно бекендеров
f# - штаны с подворотами

Никогда не воспринимал этот чат как “пыхерский”

просто мы умело маскируемся)