У вас, блин, какие-то КЛИЕНТСКИЕ расчеты занимают секунду и вас это не беспокоит, но беспокоит когда и что рисовать?? Вот она - проблема доморощенных программистов без базовых знаний.
Всегда поражало как люди, которые ничего, по факту, не понимают в настоящем программировании пишут всякие статьи на тему «как лучше». Основное правило программирования - код должен быть понятен даже идиоту и даже идиоты должны быть способны его поддерживать.
Все эти for_each, как, кстати, и написано в документации должны УЛУЧШАТЬ читаемость кода, а не использоваться только из-за идиоматичности.
Если не улучшают - нафиг. Все примеры высосаны из пальца, рекурсия вообще не рекомендуется по множеству причин.
В реальных рабочих задачах вас любой лид бы заставил все переписывать и не выпендриваться больше. А дублирование кода в Point это нормально вообще? Хоть бы примеры подобрали адекватные.
Вообще еще надо учитывать время жизни ссылки (30 дней обычно) и были ли клики на неё (обычно ссылку удаляют если 30 дней не было по ней ни одного клика).
Итоговый хэш должен быть максимально коротким и непредсказуемым, чтобы нельзя было вставить что-то свое и получить какую-то ссылку, а нужно было еще перебором найти работающий хэш. Тогда можно сделать блокировку по количеству запросов с одного IP.
То есть предсказуемости в виде первая буква - номер шарда не должно быть. В идеале 5 символов чистого рандома, что дает нам примерно 1 миллиард вариантов. 5 можно заменить на 4 или даже 3 при маленькой начальной нагрузке.
5 символов теоретически хватит для нагрузки 10 миллионов ссылок в месяц.
4 символа можно использовать при нагрузке в 150 тысяч ссылок в месяц.
3 символа при нагрузке 2 тысячи
Значения выбраны с учетом 1% заполняемости, чтобы было не подобрать.
% заполняемости задаем константой, нагрузку считаем обычным счетчиком в памяти, количество отдаваемых букв вычисляем автоматически.
Проверку ссылки на наличие в «базе» делаем с помощью фильтра Блума, без обращения к базе.
Всё же важны бизнес-метрики, а не всё остальное, довольно важная бизнес-метрика, наверное, основная - затраты на поддержку кода. Я про конкретную связку адаптера нарушающего кучу правил хорошего кода для производительности ?сборки? слышу первый раз.
Более того, как уже было много раз сказано даже тут - есть более "правильные" способы достичь этой же цели.
P.S.: NF это, грубо говоря, набор принципов. И они, по сути, могут применяться к чему угодно, ко всему, что подходит к определению модель данных, это верно. Но в обсуждении конкретно тут и в принципе используется уже какая-то "материальная" сущность модели данных. Иначе это будет обсуждение абстрактных единорогов в вакууме :)
И вообще :) Согласно методологии SMART желательно всегда оперировать измеримыми (и остальные SART) метриками, это тоже верно как то, что земля не плоская :)
Программирование вообще не про "скорость работы алгоритмов" или "скорость сборки" или что либо ещё. Программирование - про достижение бизнес-целей. Сеньор от остальных отличается как раз тем, что думает не о том как что и как запрограммировать, а о том, как добиться того, что нужно бизнесу (и продукту). Иногда, решения оказываются даже вне рамок программирования. Например, часто в результате меняется диздок, тз, а не реализуется то, что написано там.
Так же, лидов от остальных отличает наличие собственной философии программирования, тогда начинают появляются вопросы "что я делаю?" и "зачем я это делаю?" (не вопросы экзистенциального характера, а конкретные по продукту и бизнесу).
Моя личная философия (вернее её часть) программирования - код должны быть способны поддерживать даже идиоты, согласно её все "паттерны", "теории" и нормальные формы применяются только для достижения этого. НО я ранжирую выгоду от того или иного решения, грубо говоря, применяю среднее геометрическое взвешенное всех решений, в котором стоимость поддержи имеет больший вес, чем остальные, но скорость, красота, следование паттернам тоже их (веса) имеют.
Умение программировать и проектировать архитектуру это не практические навыки. Они сродни написанию картины или созданию музыки. Это творчество, которое невозможно формализовать. Но, к сожалению, так только у (хотел написать настоящих, но это было бы унижением) опытных программистов...
На мой взгляд опыт программистов по уровню можно разделить на части: 1. Знание синтаксиса языка 2. Знание возможностей языка и стандартной библиотеки 3. Знание паттернов программирования 4. Использование различных библиотек вместо своего кода 5. Знание внутренней реализации популярных контейнеров и алгоритмов 6. Понимание бизнес-логики и бизнес-потребностей 7. Умение обучать других программистов 8. Наличие своей философии программирования
Написал это всё не очень точно, я сейчас пью пиво :)
Я не только считаю, я с этим сталкивался очень много раз. С позиции руководителя и лида особенно. Люди меняются и новички на проекте потом приходят ко мне с вопросами "А это зачем?". Я на 100% согласен про удобство ПОЛЬЗОВАТЕЛЕЙ, но тут достигается не удобство пользователей, а удобство одного конкретного человека со слабым ноутбуком :) Всё же все решения должны быть подчинены эффективности бизнеса, а не чего бы то ни было.
7 лет назад у меня уже был общий опыт программирования 22 года :)
ООП и SOLID это скорее «идеалы» к которым нужно стремиться, но которыми можно пожертвовать ради - ради чего? Производительности - только если итоговая выгода для ПОЛЬЗОВАТЕЛЕЙ продукта существенна и других способов сделать то же самое не нашлось, удобства - возможно, но очень осторожно, ведь что удобно одному неудобно другому.
А вот ради чего точно стоит этим жертвовать, так это ради упрощения поддержки кода сейчас и в будущем. Код должен быть таким, чтобы его поддерживать могли даже идиоты без опыта программирования.
Инкапсуляция же это не идеал, а «ограничитель» как раз для того, чтобы не делать так. Когда ей сознательно игнорируют это всё-равно что отцепить страховку скалолазам чтобы «по-быстрому» или удобнее кое-что сделать и потом обратно.
И я не переходил на личности, так как в моем комментарии нет упоминания или указания на конкретную личность. Есть оценка уровня, но это не является оскорблением или унижением.
Каждый раз когда вы чем-то жертвуете в проекте вы должны чётко понимать - ради чего? В данном посте автор приносит огромные жертвы ради… ускорения сборки проекта и решения проблем с нехваткой памяти. Что первое что второе можно решить заменив ПК и ноутбук на более производительные, либо использовать другие компиляторы типа того же esbuild. Неразумно.
Кстати, нормализация таблиц это тоже идеал, но к реальном продакшене очень мало чисто нормальных схем баз данных. Как минимум, например, потому что даже 1NF требует словарь для таких данных как имя пользователя/клиента/игрока и всё запросы превращаются в гигантские конструкции из десятков JOIN-ов.
Даже если у вас количество повторяющихся данных в кортежах 0.01%, то БД уже не будет соответствовать 1NF, поэтому нормализируют БД не с целью «соответствовать нормальным формам», а как раз с целью повысить эффективность, уменьшить потенциальные ошибки, упростить поддержку схемы и логики приложения.
Ох и горе-программисты же пошли… Во всех книгах типа «10 способов выстрелить себе в ногу» пишут, что это один из способов.
Вы вообще знаете, что такое инкапсуляция и зачем она нужна? Я бы у себя на проектах за такое заставил бы перечитывать все эти книги. Вот оно, поколение JS, люди, которые, не работали ни с C/C++ ни с ассемблером…
Теперь вы не сможете обновить версии библиотек, даже если там найдутся критические уязвимости/ошибки или они перестанут поддерживаться.
Тому, кто будет поддерживать этот код после вас прийдётся туго… Даже разобраться в том, что где и откуда уже непросто, а зачем это было сделано вообще и подавно.
Вы залезли во внутренние типы библиотек и если библиотека решит полностью поменять «внутрянку» с сохранением публичного интерфейса то у вас все сломается. Инкапсуляция как раз про то, чтобы таким образом не стрелять себе в ногу.
В общем, уровень начинающего джуна по моему опыту.
У вас, блин, какие-то КЛИЕНТСКИЕ расчеты занимают секунду и вас это не беспокоит, но беспокоит когда и что рисовать?? Вот она - проблема доморощенных программистов без базовых знаний.
Какой у вас там алгоритм для «расчетов»? O(n^10)?
Всегда поражало как люди, которые ничего, по факту, не понимают в настоящем программировании пишут всякие статьи на тему «как лучше». Основное правило программирования - код должен быть понятен даже идиоту и даже идиоты должны быть способны его поддерживать.
Все эти for_each, как, кстати, и написано в документации должны УЛУЧШАТЬ читаемость кода, а не использоваться только из-за идиоматичности.
Если не улучшают - нафиг. Все примеры высосаны из пальца, рекурсия вообще не рекомендуется по множеству причин.
В реальных рабочих задачах вас любой лид бы заставил все переписывать и не выпендриваться больше. А дублирование кода в Point это нормально вообще? Хоть бы примеры подобрали адекватные.
Раз уж вы упомянули про OPTIMIZE есть еще OPTIMIZE FINAL, который выполняет оптимизацию сразу.
Вообще еще надо учитывать время жизни ссылки (30 дней обычно) и были ли клики на неё (обычно ссылку удаляют если 30 дней не было по ней ни одного клика).
Итоговый хэш должен быть максимально коротким и непредсказуемым, чтобы нельзя было вставить что-то свое и получить какую-то ссылку, а нужно было еще перебором найти работающий хэш. Тогда можно сделать блокировку по количеству запросов с одного IP.
То есть предсказуемости в виде первая буква - номер шарда не должно быть. В идеале 5 символов чистого рандома, что дает нам примерно 1 миллиард вариантов. 5 можно заменить на 4 или даже 3 при маленькой начальной нагрузке.
5 символов теоретически хватит для нагрузки 10 миллионов ссылок в месяц.
4 символа можно использовать при нагрузке в 150 тысяч ссылок в месяц.
3 символа при нагрузке 2 тысячи
Значения выбраны с учетом 1% заполняемости, чтобы было не подобрать.
% заполняемости задаем константой, нагрузку считаем обычным счетчиком в памяти, количество отдаваемых букв вычисляем автоматически.
Проверку ссылки на наличие в «базе» делаем с помощью фильтра Блума, без обращения к базе.
Всё же важны бизнес-метрики, а не всё остальное, довольно важная бизнес-метрика, наверное, основная - затраты на поддержку кода. Я про конкретную связку адаптера нарушающего кучу правил хорошего кода для производительности ?сборки? слышу первый раз.
Более того, как уже было много раз сказано даже тут - есть более "правильные" способы достичь этой же цели.
P.S.: NF это, грубо говоря, набор принципов. И они, по сути, могут применяться к чему угодно, ко всему, что подходит к определению модель данных, это верно. Но в обсуждении конкретно тут и в принципе используется уже какая-то "материальная" сущность модели данных. Иначе это будет обсуждение абстрактных единорогов в вакууме :)
И вообще :) Согласно методологии SMART желательно всегда оперировать измеримыми (и остальные SART) метриками, это тоже верно как то, что земля не плоская :)
Программирование вообще не про "скорость работы алгоритмов" или "скорость сборки" или что либо ещё. Программирование - про достижение бизнес-целей. Сеньор от остальных отличается как раз тем, что думает не о том как что и как запрограммировать, а о том, как добиться того, что нужно бизнесу (и продукту). Иногда, решения оказываются даже вне рамок программирования. Например, часто в результате меняется диздок, тз, а не реализуется то, что написано там.
Так же, лидов от остальных отличает наличие собственной философии программирования, тогда начинают появляются вопросы "что я делаю?" и "зачем я это делаю?" (не вопросы экзистенциального характера, а конкретные по продукту и бизнесу).
Моя личная философия (вернее её часть) программирования - код должны быть способны поддерживать даже идиоты, согласно её все "паттерны", "теории" и нормальные формы применяются только для достижения этого. НО я ранжирую выгоду от того или иного решения, грубо говоря, применяю среднее геометрическое взвешенное всех решений, в котором стоимость поддержи имеет больший вес, чем остальные, но скорость, красота, следование паттернам тоже их (веса) имеют.
Умение программировать и проектировать архитектуру это не практические навыки. Они сродни написанию картины или созданию музыки. Это творчество, которое невозможно формализовать. Но, к сожалению, так только у (хотел написать настоящих, но это было бы унижением) опытных программистов...
На мой взгляд опыт программистов по уровню можно разделить на части:
1. Знание синтаксиса языка
2. Знание возможностей языка и стандартной библиотеки
3. Знание паттернов программирования
4. Использование различных библиотек вместо своего кода
5. Знание внутренней реализации популярных контейнеров и алгоритмов
6. Понимание бизнес-логики и бизнес-потребностей
7. Умение обучать других программистов
8. Наличие своей философии программирования
Написал это всё не очень точно, я сейчас пью пиво :)
Я не только считаю, я с этим сталкивался очень много раз. С позиции руководителя и лида особенно. Люди меняются и новички на проекте потом приходят ко мне с вопросами "А это зачем?". Я на 100% согласен про удобство ПОЛЬЗОВАТЕЛЕЙ, но тут достигается не удобство пользователей, а удобство одного конкретного человека со слабым ноутбуком :) Всё же все решения должны быть подчинены эффективности бизнеса, а не чего бы то ни было.
Инкапсуляция - сокрытие реализации если говорить простыми словами. А у вас какое понимание?
7 лет назад у меня уже был общий опыт программирования 22 года :)
ООП и SOLID это скорее «идеалы» к которым нужно стремиться, но которыми можно пожертвовать ради - ради чего? Производительности - только если итоговая выгода для ПОЛЬЗОВАТЕЛЕЙ продукта существенна и других способов сделать то же самое не нашлось, удобства - возможно, но очень осторожно, ведь что удобно одному неудобно другому.
А вот ради чего точно стоит этим жертвовать, так это ради упрощения поддержки кода сейчас и в будущем. Код должен быть таким, чтобы его поддерживать могли даже идиоты без опыта программирования.
Инкапсуляция же это не идеал, а «ограничитель» как раз для того, чтобы не делать так. Когда ей сознательно игнорируют это всё-равно что отцепить страховку скалолазам чтобы «по-быстрому» или удобнее кое-что сделать и потом обратно.
И я не переходил на личности, так как в моем комментарии нет упоминания или указания на конкретную личность. Есть оценка уровня, но это не является оскорблением или унижением.
Каждый раз когда вы чем-то жертвуете в проекте вы должны чётко понимать - ради чего? В данном посте автор приносит огромные жертвы ради… ускорения сборки проекта и решения проблем с нехваткой памяти. Что первое что второе можно решить заменив ПК и ноутбук на более производительные, либо использовать другие компиляторы типа того же esbuild. Неразумно.
Кстати, нормализация таблиц это тоже идеал, но к реальном продакшене очень мало чисто нормальных схем баз данных. Как минимум, например, потому что даже 1NF требует словарь для таких данных как имя пользователя/клиента/игрока и всё запросы превращаются в гигантские конструкции из десятков JOIN-ов.
Даже если у вас количество повторяющихся данных в кортежах 0.01%, то БД уже не будет соответствовать 1NF, поэтому нормализируют БД не с целью «соответствовать нормальным формам», а как раз с целью повысить эффективность, уменьшить потенциальные ошибки, упростить поддержку схемы и логики приложения.
Ох и горе-программисты же пошли… Во всех книгах типа «10 способов выстрелить себе в ногу» пишут, что это один из способов.
Вы вообще знаете, что такое инкапсуляция и зачем она нужна? Я бы у себя на проектах за такое заставил бы перечитывать все эти книги. Вот оно, поколение JS, люди, которые, не работали ни с C/C++ ни с ассемблером…
Теперь вы не сможете обновить версии библиотек, даже если там найдутся критические уязвимости/ошибки или они перестанут поддерживаться.
Тому, кто будет поддерживать этот код после вас прийдётся туго… Даже разобраться в том, что где и откуда уже непросто, а зачем это было сделано вообще и подавно.
Вы залезли во внутренние типы библиотек и если библиотека решит полностью поменять «внутрянку» с сохранением публичного интерфейса то у вас все сломается. Инкапсуляция как раз про то, чтобы таким образом не стрелять себе в ногу.
В общем, уровень начинающего джуна по моему опыту.