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

Я вмешался в процесс, сказал, что в данном случае лучше разбить, потому что мы же не объединяем всё приложение в один файл index.php, как делали наши деды, а всё же скачем по классам и методам.

Сказать-то я сказал, однако такое объяснение с дедами не очень-то объективно. Оно основано скорее на опыте и интуиции. И тут я задумался, а нельзя ли рассмотреть код как структуру данных, а процесс программирования - как алгоритм поиска места для вставки кода.

Не то, чтобы я продумал эту мысль до конца, просто наброс для размышления.

В случае, когда весь код в одном файле (или в одной большой функции) - это полный перебор, т.е. сложность O(n). Если же есть какая-то структура папок, файлов, методов, то это дерево, а поиск по дереву будет примерно O(log n). (Я тут не настоящий сварщик, поправьте меня в коментах, если я гоню лажу).

И дураку ясно, что быстрее всего было бы искать нужную строчку в бинарном дереве, т.е. чтобы каждый метод вызывал максимум два других метода.

Тут прикольно отметить, что примерно так и советуют в Чистом коде, цитата: “Функции не должны быть большими. Лучший размер для функции — 2–3 строки”.

Однако, в отличие от Роберта Мартина, абсолютное большинство программистов не готовы так упарываться, и на это есть какая-то причина.

Тут я не уверен, но думаю, что у человека просто не хватает оперативной памяти в мозгу, когда он скачет по дереву исполнения. Представьте, что в коде есть некоторая формула для расчета зарплаты, которую надо изменить, чтобы пофиксить баг. Если для исправления бага нужно понять её всю целиком, то мозгу будет сложнее, если каждая ее часть будет лежать в отдельной функции, а таких частей будет десяток. Говорят, что человек может запомнить за раз 5-7 единиц информации.

Т.е. это обход дерева с очень жёстким ограничением по памяти.

В итоге мы логично приходим к принципам SRP и high cohesion.

Т.е. один класс (или один метод, модуль - не важно) должен делать что-то одно (чтобы не перегружать поиск нужного участка кода), но при этом вещи из одной области бизнес-логики не должны быть сильно разбросаны по разным концам дерева.

Т.е. если вернуться к нашему примеру, формула для расчета зарплат должна быть по возможности видна в коде целиком, но при этом другие формулы или работа с выводом результата - точно должны быть отделены.