С расчётом на будущее использование - рефакторинг, один из отличных процессов, который несёт кучу профита для самого разработчика и продукта. Это делать нужно с умом, т.к. порой большое убер-бревно вот так не перепишешь, поэтому рефакторинг не простая задача, которая требует подхода.
А то что академические подходы не выживают в коммерции - с этим согласен. Только дополню: в школе, вас учат, и учитесь вы базируясь разным источникам, но не важнейшему - опыту. А лучший опыт, это коммерческий опыт.
Ты говоришь о проектах, с которыми тебе приходится работать, но они уже есть. Это не оправдание что так нужно теперь делать всё. Двигаться нужно вперёд, а не засиживаться на одном месте.
Да, в твоём случае, венгерская нотация, помогла бы, но это не оправдывает её. Т.к. она помогла бы для разбора ужасного кода. Получается что она применима для ужасного кода, и помогает там.
В хорошем и слаженном коде, таких проблем не возникает.
Другой момент, это "философия" и организация работ. И несмотря на твой комент "в зду..", ты потом как раз затрагиваешь эти моменты:
|
И вся его громозкость - результат фиксов багов, добавления функционала ВНЕЗАПНО потребовавшегося заказчику и т.п.
|
Проблема организации проекта. Такого не должно быть. Также, разработка кода с учётом его модульности и возможностей, никак не пострадает от "внезапных запросов", т.к. клиент не попросит писать конкретно вот такие строки, он лишь запросит клёвую фичу, которая потребует лишь дополнительную разработку на уровне бизнес логики, или даже фронт-енда, а это не влияет на сами классы никак, если они разработаны с умом..
Тут уже разговор перетекает в организацию проектов, и лид девелоперов, командную работу..