Здравствуйте, MozgC, Вы писали:
MC>1) Иногда функцию просто не стоит уменьшать, с ней и так всё в порядке, даже если её размер противоречит Теории Мартина-Кота2 (превышает 5-30 строк).
я против измерения сложности ф-ии строками. просто одна ф-ия занимается одним делом. бывают такие ф-ии по 30 строк, которые неразумно бить на части, но их очень мало в общем кол-ве. абсолютное большинство безо всяких усилий укладывается в 10 строк. никто не заставляет запихивать ф-ию в 10 строк, это делается совершенно ествественно, просто даже добавить в нее нечего. например, мы открываем файл, проверяем статус, передвигаемся на его конец, возвращаем позицию. все. любая другая операция тут будет лишней.

MC>2) С одной стороны код становился понятнее; с другой стороны, при чтении кода приходилось прыгать по куче функций, чтобы понять, что происходит. Так же часто приходилось пользоваться решарперовским Find Usages, чтобы посмотреть откуда вызывается эта микро-функция, только чтобы увидеть, что вызывается она из одного места. При отладке тоже не нравилось прыгать по куче микро-функций. Не конец света, конечно, но не айс.
маленькие ф-ии это еще полдела. они должны быть названы так, чтобы по названию было понятно, что она делает, не заглядывая внутрь. и сами классы тоже должны быть маленькими и называться не datahelper, а так, чтобы вы могли понять что делает этот класс, не заглядывая в него. так, например, ф-ия работы с временной зоной не должна находиться внутри utils.cs и являться частью класса datetimehelper, она должна называться timezone и находиться в модуле timezone или хотя бы datetime и вам не придется никуда прыгать по коду, так как класс timezone описывает временную зону и странно ожидать там что-то другое

MC>В результате я как-то забросил подход с микро-функциями и все эти субъективные лимиты (в 5-10 строк, полэкрана, 1 экран, 2 экрана, 30 строк и т.д.) и тупо продолжил писать по ситуации: вижу что лучше сделать extract method — делаю, если функция на 1-2 экрана отлично читается линейно или её сложно уменьшить — оставляю как есть.
а тесты?

MC>PS. Для тех, кто еще не решил для себя, каким размером ограничивать функции и стоит ли это делать: можете просто попробовать подход с маленькими функциями в течение нескольких месяцев и сами для себя решите — нравится вам это или нет.
нужно не пробовать подход с маленькими ф-иями, а подход с написанием юнит-тестов. вы быстро выясните, что при привычном подходе вам тестов придется писать еще и больше кода и, постепенно поймете, как разбить все на маленькие назависимые, скомпонованные между собой модули, чтобы изменения в одном не тянули изменений в другом. но скорее всего вы плюнете на эту задумку и оставите только функциональные тесты, время выполнения которых постепенно докатится до 4 часов на коммит и вы, наконец, поймете, в чем разница между юнит тестами и функциональными.