Мы все были там. Вы работаете над продуктом, и есть такая часть бизнес-логики, которая кажется достаточно общей, скажем, функция plural(x, noun), которая принимает число x и существительное noun и возвращает соответствующую форму единственного/множественного числа этого noun в количестве x
Так вот, эта функция обычно задумывалась в рамках бизнес-логики, которая сначала потребовала ее, но, очевидно, можно было бы сделать вывод:
«Хм… это кажется достаточно общим, чтобы служить утилитой. Давайте переместим его на /utils!»
Достаточно скоро вы можете обнаружить громоздкий файл utils, в котором собраны все эти служебные функции, которые, возможно, не имеют общего контекста.
Теперь прилежный программист мог бы разделить файл utils по логическим областям, таким как математика, работа со строками и функции базы данных. Однако такое разделение создает ложное ощущение модульности — разделение здесь связано только с файловой иерархией, а не с владением кодом. Что я имею в виду? скажем, теперь у вас есть другой проект, для которого требуются некоторые из этих утилит. По моему опыту, в условиях реальных сроков, загруженности или просто лени можно было бы просто скопировать /utils в другой проект, тем самым совершив смертный грех не-СУХОЙ код!
Чтобы добиться истинной модульности, вам следует разделять и властвовать над этой мешаниной утилит, извлекая их в независимые модули кода, а именно в пакеты NPM для JavaScript или любой тип упаковки, предлагаемый вашей языковой экосистемой.
