Comments 21
А skipLibCheck не помогал?
Посмотрите esbuild. Написан на Rust, мой проект билдит за секунду, в то время как tsc секунд 40.
Я смотрел, действительно круто, но он еще мне кажется не готов для продакшена, слишком многое меняется, плагины устаревают. Месяц назад пробовали и не смогли все что нужно прикрутить
Swc написан на Rust. А esbuild написан на Go (https://esbuild.github.io/faq/#why-is-esbuild-fast)
Потребление памяти-то вы снизили. Но теперь ответственность за правильные типы библиотек - на вас. Изменится зависимость, а вы не поправите свою обертку с типами - что-нибудь упадет.
Кстати, такой способ импорта не очень совместим с ES Modules. Если в зависимости прописаны точки входа exports в package.json , то импортировать можно только из этих точек входа. https://nodejs.org/api/packages.html#package-entry-points
У нас зафиксированы версии в package.json, обновляем редко и при большой нужде, даже changelog смотрим.
Про es modules Вы правы, там еще импорт директории запрещен, нужно указывать index.js. Но для этого хотя бы можно написать plugin, а с прописанными exports я даже не знаю, что и делать.
Moжно делать для package собственные патчи при помощи yarn patch/pnpm patch
https://yarnpkg.com/cli/patch/
Ох и горе-программисты же пошли… Во всех книгах типа «10 способов выстрелить себе в ногу» пишут, что это один из способов.
Вы вообще знаете, что такое инкапсуляция и зачем она нужна? Я бы у себя на проектах за такое заставил бы перечитывать все эти книги. Вот оно, поколение JS, люди, которые, не работали ни с C/C++ ни с ассемблером…
Теперь вы не сможете обновить версии библиотек, даже если там найдутся критические уязвимости/ошибки или они перестанут поддерживаться.
Тому, кто будет поддерживать этот код после вас прийдётся туго… Даже разобраться в том, что где и откуда уже непросто, а зачем это было сделано вообще и подавно.
Вы залезли во внутренние типы библиотек и если библиотека решит полностью поменять «внутрянку» с сохранением публичного интерфейса то у вас все сломается. Инкапсуляция как раз про то, чтобы таким образом не стрелять себе в ногу.
В общем, уровень начинающего джуна по моему опыту.
Лет 7 назад я тоже верил в китов ООП, SOLID, и ругался, когда находил в БД ненормализованные таблички.
Инкапсуляция здесь нарушается, Вы правы. Но я не считаю её незыблемым правилом, которое нельзя нарушать ни при каких условиях. Есть минусы, которые Вы описали - будет сложнее переход на новую версию библиотеки при обратно несовместимом изменение апи. Есть плюсы.
Можно представить это как адаптер и инверсию зависимостей. Если hubspot изменит свое api, нужно будет поменять адаптер - hubspot.js, hubspot.d.ts и реализовать старые методы через новый апи, а не шерудить по всему проекту.
Конечно, нужно было бы просто выкинуть @redis/client и взять более подходящую библиотеку, уверен в npm есть что-то годное. Но, скорей всего, в проекте уже есть зависимости на определенные особенности этой библиотеки (абстракции протекают) и они сломаются при переходе на другую библиотеку. Может память немного протечь, может гонка начнется. Это может произойти и при переходе на новую версию, поэтому мы фиксируем версии зависимостей и переходим только если ооочень надо.
Добавлю в код комменты для других разрабов, возможно оно действительно неочевидно, зачем.
Переход на личности весьма неприятен, и не обоснован, я намног больше воспитан C#, чем js, с ассемблером, слава богу, не работал, а вот с C/C++ довелось, и не думаю, что это хороший язык для воспитания хорошего вкуса у программиста, слишком много на нем очень плохого кода.
7 лет назад у меня уже был общий опыт программирования 22 года :)
ООП и SOLID это скорее «идеалы» к которым нужно стремиться, но которыми можно пожертвовать ради - ради чего? Производительности - только если итоговая выгода для ПОЛЬЗОВАТЕЛЕЙ продукта существенна и других способов сделать то же самое не нашлось, удобства - возможно, но очень осторожно, ведь что удобно одному неудобно другому.
А вот ради чего точно стоит этим жертвовать, так это ради упрощения поддержки кода сейчас и в будущем. Код должен быть таким, чтобы его поддерживать могли даже идиоты без опыта программирования.
Инкапсуляция же это не идеал, а «ограничитель» как раз для того, чтобы не делать так. Когда ей сознательно игнорируют это всё-равно что отцепить страховку скалолазам чтобы «по-быстрому» или удобнее кое-что сделать и потом обратно.
И я не переходил на личности, так как в моем комментарии нет упоминания или указания на конкретную личность. Есть оценка уровня, но это не является оскорблением или унижением.
Каждый раз когда вы чем-то жертвуете в проекте вы должны чётко понимать - ради чего? В данном посте автор приносит огромные жертвы ради… ускорения сборки проекта и решения проблем с нехваткой памяти. Что первое что второе можно решить заменив ПК и ноутбук на более производительные, либо использовать другие компиляторы типа того же esbuild. Неразумно.
Кстати, нормализация таблиц это тоже идеал, но к реальном продакшене очень мало чисто нормальных схем баз данных. Как минимум, например, потому что даже 1NF требует словарь для таких данных как имя пользователя/клиента/игрока и всё запросы превращаются в гигантские конструкции из десятков JOIN-ов.
Даже если у вас количество повторяющихся данных в кортежах 0.01%, то БД уже не будет соответствовать 1NF, поэтому нормализируют БД не с целью «соответствовать нормальным формам», а как раз с целью повысить эффективность, уменьшить потенциальные ошибки, упростить поддержку схемы и логики приложения.
С точки зрения теории я с Вами согласен, все так и есть.
С одной стороны возрастающая сложность, с другой удобство пользователей. (У сервиса компиляции пользователи - программисты)
А на практике, в конкретном случае, вы действительно считаете, что это приведет к большим проблемам? Мне кажется, вероятность мала, а проблемы незначительны. Оценка, конечно, субъективна и зависит от проекта.
Я не только считаю, я с этим сталкивался очень много раз. С позиции руководителя и лида особенно. Люди меняются и новички на проекте потом приходят ко мне с вопросами "А это зачем?". Я на 100% согласен про удобство ПОЛЬЗОВАТЕЛЕЙ, но тут достигается не удобство пользователей, а удобство одного конкретного человека со слабым ноутбуком :) Всё же все решения должны быть подчинены эффективности бизнеса, а не чего бы то ни было.
Хорошо написанный комментарий решит проблему?
Ноутбук не слабый, i7 10 серии, 16Гб. Но криво написанные библиотеки (а в случае redis это именно что криво и слишком вычурно) иногда непомерно тратят ресурсы.
Бизнес это в том числе про скорость багфиксов и выкатки фич, в том числе про удовлетворенность процессом разработчиков.
Использование адаптера для увеличения скорости = совершенно валидный паттерн, как и денормализация некоторых таблиц БД, когда мы жертвуем ради скорости необходимостью поддерживать ее консистентность (кстати, NF применяется к модели данных, а не к физическим БД, поэтому, когда мы говорим об эффективности, мы должны указывать метрики, которые мы решаем).
Программирование - не магия следования AbstractBuilderFactoryAdapter, а инженерная/архитектурная практика. Например, если проект собирается 10 минут (ангуляр проект какой-нибудь), а после - 5, вы можете сами себе посчитать импакт на T2L.
Всё же важны бизнес-метрики, а не всё остальное, довольно важная бизнес-метрика, наверное, основная - затраты на поддержку кода. Я про конкретную связку адаптера нарушающего кучу правил хорошего кода для производительности ?сборки? слышу первый раз.
Более того, как уже было много раз сказано даже тут - есть более "правильные" способы достичь этой же цели.
P.S.: NF это, грубо говоря, набор принципов. И они, по сути, могут применяться к чему угодно, ко всему, что подходит к определению модель данных, это верно. Но в обсуждении конкретно тут и в принципе используется уже какая-то "материальная" сущность модели данных. Иначе это будет обсуждение абстрактных единорогов в вакууме :)
И вообще :) Согласно методологии SMART желательно всегда оперировать измеримыми (и остальные SART) метриками, это тоже верно как то, что земля не плоская :)
Программирование вообще не про "скорость работы алгоритмов" или "скорость сборки" или что либо ещё. Программирование - про достижение бизнес-целей. Сеньор от остальных отличается как раз тем, что думает не о том как что и как запрограммировать, а о том, как добиться того, что нужно бизнесу (и продукту). Иногда, решения оказываются даже вне рамок программирования. Например, часто в результате меняется диздок, тз, а не реализуется то, что написано там.
Так же, лидов от остальных отличает наличие собственной философии программирования, тогда начинают появляются вопросы "что я делаю?" и "зачем я это делаю?" (не вопросы экзистенциального характера, а конкретные по продукту и бизнесу).
Моя личная философия (вернее её часть) программирования - код должны быть способны поддерживать даже идиоты, согласно её все "паттерны", "теории" и нормальные формы применяются только для достижения этого. НО я ранжирую выгоду от того или иного решения, грубо говоря, применяю среднее геометрическое взвешенное всех решений, в котором стоимость поддержи имеет больший вес, чем остальные, но скорость, красота, следование паттернам тоже их (веса) имеют.
Умение программировать и проектировать архитектуру это не практические навыки. Они сродни написанию картины или созданию музыки. Это творчество, которое невозможно формализовать. Но, к сожалению, так только у (хотел написать настоящих, но это было бы унижением) опытных программистов...
На мой взгляд опыт программистов по уровню можно разделить на части:
1. Знание синтаксиса языка
2. Знание возможностей языка и стандартной библиотеки
3. Знание паттернов программирования
4. Использование различных библиотек вместо своего кода
5. Знание внутренней реализации популярных контейнеров и алгоритмов
6. Понимание бизнес-логики и бизнес-потребностей
7. Умение обучать других программистов
8. Наличие своей философии программирования
Написал это всё не очень точно, я сейчас пью пиво :)
Опыт программирования 29 лет и сокрытие = инкапсуляция. Ну ну... Каким боком тут инкапсуляция? :/
Самый простой способ ускорения компиляции TypeScript'а - сразу кодировать на JavaScript'е ;)
Один из способов ускорения компиляции TypeScript