Roman Mejtesпросто примера ради, достался мне 1 проект, в проекте есть файлы по 5к строк кода!
отладка и правка багов в этих файлах превращается в сущий АД. Потому, что перемещаться по файлу, искать нужный код, который уже есть, понимать, что конкретно выполняет этот класс невозможно. Потому, что этот класс делает всё, что угодно. И когда сталкиваешься с таким кодом, приходит чёткое понимание того, почему классы должны быть SOLID и реализовывать только тот функционал, который можно описать 1 предложением.
Все эти 5 тысяч строк кода еще и на регионы разбиты, типа тут у нас методы, тут конструкторы, тут свойства и поля.
Спасает только Bookmarks, навигация по коду и т.д. И то не шибко сильно.
Код выполняет поставленные перед ним задачи. Но сопровождать такой код, полная жопа. При этом, так как у кода высокая связанность, разбить это в данный момент крайне сложно и контрпродуктивно. Я убью кучу часов просто на то, чтоб код стал читаемым и вменяемым. А часов у меня таких нет, от меня требуют решения проблем заказчика, а не решения проблем разработчиков. По этому, этот говно код останется там на веки вечные, пока не закончится жизненный цикл этого приложения.
Всё это не важно, когда пишешь код для себя, но когда пишешь код и знаешь, что его могут поддерживать другие люди, старайтесь ориентироваться на эталонный код. А не считать, что любой код, это говнокод
Значит этот код решает большую, но единственную проблему.
А не то давно бы ты смог его растащить на "классы", нет там никаких классов просто.

Алексей КRoman Mejtes5к строк кода!
отладка и правка багов в этих файлах превращается в сущий АД. Потому, что перемещаться по файлу, искать нужный код, который уже есть, понимать, что конкретно выполняет этот класс невозможно. Потому, что этот класс делает всё, что угодно. И когда сталкиваешься с таким кодом, приходит чёткое понимание того, почему классы должны быть SOLID и реализовывать только тот функционал, который можно описать 1 предложением.Ну будет у тебя 1000 мелких классов с непонятными зависимостями между ними. Думаешь, станет легче?
И они все будут статик.

skyANAАлексей Кпропущено...
Какая разница от кого они приходят. Я говорю о том, что они должны быть чётко сформулированы.
Принципы SOLID для тебя достаточно чётко сформулированы?
Да пофиг.
Есть формальные подходы.
Например, если метод вызывается только из одного метода, то такого метода не должно быть.

hVosttViPRosИ они все будут статик.

Сколько человек из активных разработчиков делали VIPROS? И сколько задействовано сейчас?
ВИПРОС не могут делать "сколько человек" - для этого должно иметь ТЗ на ВИПРОС.
Сейчас на работе несколько ВИПРОСов - трехзвенные, пятизвенные,.. (наша НОВАЯ платформа!!! Еще новее - прикрутили что то туда!!!)
Я веду свой проект ВИПРОС, они свои (растаскивают как могут).

hVosttViPRosНапример, если метод вызывается только из одного метода, то такого метода не должно быть.

Почему?

Потому что.

skyANAViPRosпропущено...

Да пофиг.
Есть формальные подходы.
Например, если метод вызывается только из одного метода, то такого метода не должно быть.
А когда появляется необходимость вызывать метод, которого нет, ещё откуда-то, то просто копипастим код?
Такой подход тоже используете?
Как только появляется нужда копипаста и копипаст не внутри одного и того же метода (там всякие екшны ,функции выручают - когда скорость не так важна), появляется новый метод.
Но, C# уже дошел до вложенных функций (есть делегаты, екшны, функции - но они медленные) и скорее всего я бы пользвался вложенными функциями в основном (но, я сижу на C# 4.0, не дают пользоваться благами).

hVosttViPRosВИПРОС не могут делать "сколько человек" - для этого должно иметь ТЗ на ВИПРОС.

Странный ответ, речь-то про платформу, а не интеграцию.

ViPRosПотому что.

Видимо когда-то Алексей К получил точно такой же ответ на вопрос про размер функции в один экран, и осерчал
Не имеет самостоятельной ценности такие куски.
Они сильно зависимы от контекста вызывающего метода.