Как насчёт класть каждую функцию в свой файл?

http://www.inpearls.ru/561894

Насчёт остальных языков программирования я не знаю.

using System;
namespace BoxApplication
{
   class Box
   {
      private double length;   // Length of a box
      private double breadth;  // Breadth of a box
      private double height;   // Height of a box
      public void setLength( double len )
      {
         length = len;
      }
      
      public void setBreadth( double bre )
      {
         breadth = bre;
      }
      
      public void setHeight( double hei )
      {
         height = hei;
      }
      public double getVolume()
      {
         return length * breadth * height;
      }
   }
   class Boxtester
   {
      static void Main(string[] args)
      {
         Box Box1 = new Box();   // Declare Box1 of type Box
         Box Box2 = new Box();
         double volume;
         
         // Declare Box2 of type Box
         // box 1 specification
         Box1.setLength(6.0);
         Box1.setBreadth(7.0);
         Box1.setHeight(5.0);
         
         // box 2 specification
         Box2.setLength(12.0);
         Box2.setBreadth(13.0);
         Box2.setHeight(10.0);
         
         // volume of box 1
         volume = Box1.getVolume();
         Console.WriteLine("Volume of Box1 : {0}" ,volume);
         
         // volume of box 2
         volume = Box2.getVolume();
         Console.WriteLine("Volume of Box2 : {0}", volume);
         
         Console.ReadKey();
      }
   }
}

Сегодня эта ссылка указывает точно на метод под названием booleanConditional. А вот на что эта ссылка будет указывать спустя пол года — на это мы посмотрим спустя пол года

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

У ядра есть папка functions, в которой находятся ещё пять папок
arrays
dates
strings

А по такой ссылке никогда не будет другого контента. (Ну только если не снести комит целиком)

Было лень перечитывать все комментарии, потому может быть будут повторения с тем что выше.

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

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

то на продакшене, по хорошему, надо собирать все функции в один файл и загружать его одного вместо кучи файлов.

В целом в этом нет необходимости. Есть opcache. Еще стоит использовать composer-ские инклуды файлов. И писать ничего не надо.

Там уже давно все адекватные люди компилируют исходники различными готовыми инструментами в один файл.

На клиенте это делают для того, чтобы загрузить все файлы одним HTTP запросом, не более того. Скажем с использованием HTTP2 бандлинг уже не так необходим, но к примеру если мы используем модули и tree-shaking можно существенно снизить размер итогового билда.

Но на сервере, для nodejs, никто таким не занимается. Все тупо грузится в память и в целом количество файлов на этом этапе не влияет на производительность.

Теперь найти нужную функцию проекта стало в несколько раз проще

Все относительно. Если вы скажем новый человек на проекте, вы не знаете имен этих функций. И просматривать сотню файлов по 10 строк становится не так уж и удобно. Да и если вы автор всех этих функций, через полгода вы уже не вспомните названия. Но опять же тут уже дело вкуса.

Тут больше проблема стоит в том чтобы все эти файлы подключить. Вы для этого используете некий include_dir, но обычные люди захотят чтобы этим занимался composer. А тому проще скормить список файлов.

Инкапсуляция кода и документации

Повторю простую мысль. Ваш подход нормален ровно до тех пор, пока функции остаются чистыми по своей природе. Как только появляются функции вроде send_email_to_user или event, теряется информация о зависимостях. То есть вы как бы говорите "у меня шлются ивенты но вам придется искать где и как". Вы так же теряете возможность для применения таких замечательных вещей как open/close principle (расширение функционала без внесения изменений в существующий код), SRP (особенно в случае нотификаций на email, что будете делать если у вас там надо шаблон с красивым email-ом отрендрить?). Ну и я не говорю о том что такие функции нельзя адекватно замокать и как следствие покрыть код юнит тестами.

Повторю простую мысль. Ваш подход нормален ровно до тех пор, пока функции остаются чистыми по своей природе. Как только появляются функции вроде send_email_to_user или event, теряется информация о зависимостях...

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

Вы так же теряете возможность для применения таких замечательных вещей как open/close principle (расширение функционала без внесения изменений в существующий код),

Да, я про это написал в одном из комментов к этой статье.

SRP (особенно в случае нотификаций на email, что будете делать если у вас там надо шаблон с красивым email-ом отрендрить?)

Извините, я не знаю что такое SRP, но красивый шаблон в email сообщении у нас имеется, а код функции send_email_to_user выглядит вот так:

<?php

use App\Models\EmailTemplate;
use App\Models\User;
use App\Services\Mailing\TemplateCompiler;

function send_email_to_user($template, User $user = null, $data = [])
{
    if (is_string($template)) {
        $template = EmailTemplate::where('code', $template)->firstOrFail();
    }

    $templatePath = TemplateCompiler::getViewPath($template->code, $user->settings->language_id);

    $data['emailuser'] = $user;

    Mail::send($templatePath, $data, function ($m) use ($user, $template) {
        $m
            ->from('projectname', __('projecttitle', [], [ 'language-id' => $user->settings->language_id ]))
            ->to($user->email, $user->name)
            ->subject($template->getText($user->settings->language_id)->subject);
    });
}

То есть, мы отправляем нужный шаблон нужному пользователю с текстом на том языке, который выбран у него в настройках. В данный момент эта логика работы вполне нормально работает. Да, если будет надо — всегда можно создать ещё один класс-сервис, для отправки писем людям. Это ведь вопрос рефакторинга. Это не так сложно сделать, когда код проекта достаточно опрятен.