Comments 9
4) В отдельный файл info.csv записываем строку с id записи, названием файла, из которого была извлечена функция и хешем функции
5) Загружаем файл info.csv в SQLite и делаем по нему всякие запросы, ведь эта база — не игрушка!
Простите, проорал. Зачем вам файл info.csv?
В остальном отличное исследование, спасибо!
Возможно это небольшое исследование кого-нибудь натолкнет на мысли какие-нибудь мысли о рефакторинге.Учитывая, что самые распространённые функции — это либо заглушки либо однострочные хэлперы, не очень понимаю, что здесь предлагается оптимизировать? Сделать в npm пакет empty_fun.js, чтобы от него пол интернета зависело? :-)
/s
top 2 и top 3 функции – это результат транспиляции Babel или Typescript, они генерируют такой код для import и export.
При желании его можно оптимизировать и взять переиспользуемые модули @babel/runtime или tslib соответственно.
Иногда универсальное решение в принципе недостижимо. Иногда оно бессмысленно, потому что проект внезапно сворачивает в другую ветку эволюции.
Многие участки кода очень похожи, вплоть до копипасты, но у них разная судьба, разный план развития, делаешь универсальный класс и потом начинаешь все равно забивать его кастомизацией, декораторами (в ООП смысле, не в TS), наращивать сложность использования.
Многие функции и методы пишутся для того, чтобы облегчить понимание логики происходящего. Если заменить их на универсальные, читаемость от уровня «технический текст» упадет до уровня «абстрактная формула, которая непонятно что делает в нашем коде»
Некоторые функции очень коротки — настолько, что замена их на универсальную функцию не даст никакого выигрыша.
Вот пример из статьи. На какую универсальную функцию это можно заменить? Насколько короче станет код? В чем выигрыш?
const z=function(){return this};
Но тут я скорее согласен с предыдущим оратором — это похоже на заглушку на будущее, для метода, который хочется вызывать цепочкой с другими.
Но к некоторым примерам вопросов нет, они действительно загадочны. Кто пишет свою обертку для forEach? Почему для читабельности он просто не разносит разные операции над своим массивом по разным методам?
Я полагаю, такой метод может быть оправдан, если кодер думает — «сейчас я использую массив, а потом, может быть, перейду на дерево Меркла, и мне понадобится переписывать проход по нему во всех местах. Сделаю-ка я сразу делегирование прохода в метод — тогда можно будет изменить и коллекцию, и её алгоритм, не повреждая остальной код»
const z=function(a,c){this._array.forEach(a,c)};
Отдельная больная тема — как и откуда брать универсальные мелкие функции? Тащить библиотеку? Добавлять еще зависимость в проект? Потом при обновлении библиотеки проверять, не сломалось ли что-то в билде (или как вариант — сразу чинить, что сломалось)? Вот подумаешь над этим и такой
— Да ну на, лучше я сам скопипащу кодекату с реверсом строки для единственного места, где это нужно, чем буду тащить в зависимости непонятно что с непонятным в будущем результатом. Да, у меня уже есть пара таких копипаст, зато все эти классы легко перебрасываются из проекта в проект, без перетаскивания библиотек, с гарантией работы до тех пор, пока не сломается стандарт самого языка.
Выглядит так, будто бóльшая часть функций — скомпилированный в ES5 более новый код (TS, ES6+).
Из ангуляра:
5911b29c89fa44f28ce030aa5e433327 - Object.copy
05c2b9b254be7e4b8460274c1353b5ad - deepCopy
fcaede1b9e574664c893e75ee7dc1d8b - Object.clone
e743dd760a03449be792c00e65154a48 - Object.clone
4728096fca2b3575800dafbdebf4276a - identity
d98a03a472615305b012eceb3e9947d5 - void
f6822db5c8812f4b09ab142afe908cda - void
27628ad740cff22386b0ff029e844e85 - identity
7d1e7aad635be0f7382696c4f846beae - void
285d00ca29fcc46aa113c7aefc63827d - void
b7081aad7510b0993fcb57bfb95c5c2c - alwaysFalse
d665499155e104f749bf3a67caed576a - Boolean()Из реакта большинство — scoped functions (возвращают значение из верхнего замыкания), видимо скомпилированные arrow functions:
const z=function(){return cache};
const z=function(){return m[k]};
const z=s=>exposed.has(s);Если бы не нужна была обратная совместимость с каким-нибудь IE11, вполне разумно было бы выбросить вот это вот все и заменить на "родные" API.
Меня эта статья наталкивает на мысль разработать утилиту (типа надстройки для yarn / npm / webpack / node) такого себе жесткого tree shaking.
В случае Ангуляра — бОльшая часть "повторяющихся" функций — это выход из tsc с даунгрейдом. Ангуляр, как и сам компилятор тайпскрипт, написан на TS, а автор в статье проверяет уже скомпилированные .js файлы.
Даунгрейд синтаксиса классов и вызовов super() — в прототипы. ES-module в CommonJS.
Вс остальное — это преимущественно "пустышки", которые бессмысленно рефакторить/переиспользовать.
Сборшики работают эффективно
Не, это просто в бандл вошли совсем не те файлы, которые были проаналзированые ранее. По списку самых больших файлов видно, что все это — сама система сборки (typescript, angular compiler, sass).
Только 39% функций в node_modules уникальны в дефолтном Angular проекте