Раз на несколько статей хотели разнести историю успеха, могли бы как раз подвесить интригу в цифрах.
Что-то вроде метрик Старый Стек vs Новый Стек. Причём по слоям. А в следующей статье уже добавить подробностей замена чего на что какой прирост дало. Хотя, и следующей статьи не понадобилось бы тогда.
Имея такие цифры на руках, сами себе бы и ответили, а стоило ли менять прям весь стек. Или достаточно было бы решить вопрос с БД. И не тратить время на замену ЯП.
И как тут уже писали , ни один ЯП не ускоряет выполнения одного и того же запроса к БД. Скорость самого SQL запроса не зависит от ЯП, который его вызывает. А про оптимальность таблиц, индексов, настроек БД под ваши нужды.
Что-то здесь порядок рассмотрения претензий попутан. Экспертизу проводит за свой счёт продавец, если не согласен с недостатком товара. И если экспертиза выявит, что претензия необоснованна, то бремя оплаты экспертизы ложится на покупателя. И только после этого потребитель идёт заказывать независимую «липовую экспертизу».
Нет, Вы, как потребитель не обязаны ждать сначала экспертизы от продавца. Можете сначала сделать самостоятельно, и с ней прийти сразу с претензией. А продавец может до или после этого свою экспертизу.
Верно, так и должно быть. Сначала идёт проектирование (DDD), а потом уже код.
Возможно, ошибочно сложилось впечатление, что от Вас посыл был несколько в обратном, что DDD не нужен. Хотя такая методология как раз и дает ответы на вопросы. Чтобы потом не приходилось переписывать код множество раз.
Никакой DDD и прочие заумные практики разработчикам уже не нужны (микросервисы и так обеспечивают bounded contexts)
Микросервисы это обеспечивают как раз потому, что есть такие «заумные» практики как DDD. Которые и помогают понять, как разделить предметную область на подобласти, а их уже на сервисы.
Спасибо за ответ! Конечно, точных цифр не ожидал услышать. Хоты бы порядок. Чтобы иметь представление по Вашему опыту, сколько времени уходит на подготовку к разработке/рефакторингу (непосредственная целенаправленная работа с кодом). Так как, повторюсь, для 10-ти летнего легаси рефакторинг за 3 месяца (пусть даже может и не все на самом деле, но большую часть отрефакторили) считаю отличный срок. Значит, подготовка была достаточно основательная. Поэтому и решил задать этот вопрос.
При синхронном чтение весь пишется в память. Если он у вас >= Гб, быстро память закончится.
Даже если меньше, и их у Вас несколько, но они читаются параллельно, тоже можете упереться в память.
Раньше в вакансиях не редко было (и сейчас бывает): «пилим монолит, есть легаси проекты… надеемся, ты тот, кто не боится легаси…»
Теперь будет: «… легаси победили, остался/появился ВайбКод… надеемся, ты тот, кто не боится править ВайбКод….».
думаю, они ждали Ваш комментарий.
«О, точно! А вот же что мы ещё забыли включить в разработку авто»…
И в следующем релизе новостей получите ответ на свой вопрос о ттх :))
Видимо, нужна статья «16 статей, о которых должен знать каждый Node.js разработчик, которые не надо переводить, и постить на Хабре».
Как минимум, для сотрудников Otus.
Srp принцип в действии.
Не все поймут, не многие вспомнят :) а цитируемый фильм великолепный.
Раз на несколько статей хотели разнести историю успеха, могли бы как раз подвесить интригу в цифрах.
Что-то вроде метрик Старый Стек vs Новый Стек. Причём по слоям. А в следующей статье уже добавить подробностей замена чего на что какой прирост дало. Хотя, и следующей статьи не понадобилось бы тогда.
Имея такие цифры на руках, сами себе бы и ответили, а стоило ли менять прям весь стек. Или достаточно было бы решить вопрос с БД. И не тратить время на замену ЯП.
И как тут уже писали , ни один ЯП не ускоряет выполнения одного и того же запроса к БД. Скорость самого SQL запроса не зависит от ЯП, который его вызывает. А про оптимальность таблиц, индексов, настроек БД под ваши нужды.
Поддержу вопрос.
Честно говоря, в статье много обобщённого, никакой конкретики.
По сути сводится к: «у нас что-то медленно работало. Решили сменить стек полностью. Вроде заработало быстрее».
Ответа на вопросы из заголовка статьи в самой стать к нет.
Нет, Вы, как потребитель не обязаны ждать сначала экспертизы от продавца. Можете сначала сделать самостоятельно, и с ней прийти сразу с претензией. А продавец может до или после этого свою экспертизу.
Верно, так и должно быть. Сначала идёт проектирование (DDD), а потом уже код.
Возможно, ошибочно сложилось впечатление, что от Вас посыл был несколько в обратном, что DDD не нужен. Хотя такая методология как раз и дает ответы на вопросы. Чтобы потом не приходилось переписывать код множество раз.
Правило думали.
Микросервисы это обеспечивают как раз потому, что есть такие «заумные» практики как DDD. Которые и помогают понять, как разделить предметную область на подобласти, а их уже на сервисы.
Да, есть.
Преподносить инспекцию кода, code review как инстурмент мщения - это совсем не командная работа.
Или это такой скрытый юмор в статье?
инспекция кода
code review
командная работа
Спасибо за ответ! Конечно, точных цифр не ожидал услышать. Хоты бы порядок. Чтобы иметь представление по Вашему опыту, сколько времени уходит на подготовку к разработке/рефакторингу (непосредственная целенаправленная работа с кодом).
Так как, повторюсь, для 10-ти летнего легаси рефакторинг за 3 месяца (пусть даже может и не все на самом деле, но большую часть отрефакторили) считаю отличный срок. Значит, подготовка была достаточно основательная. Поэтому и решил задать этот вопрос.
А так же интересно, сколько времени ушло на этапы: инициализация, планирование, анализ, проектирование.
Хотя бы в сумме. Но лучше в отдельности :)
Так три месяца на рефакторинг звучит, конечно, круто и достойно. Но и предыдущие этапы не пару дней заняли? :)
Спасибо Вам, что подхватили поддержку публикации дайджеста. Очень полезно!
Плюс к этому, там же (у developer.mozilla.org), что это ещё экспериментальная вещь.
А здесь в статье ни слова об этом. Хотя бы ссылку на поддержку браузеров.
При синхронном чтение весь пишется в память. Если он у вас >= Гб, быстро память закончится.
Даже если меньше, и их у Вас несколько, но они читаются параллельно, тоже можете упереться в память.
На node js у Вас должно получиться что-то вроде (условно):
где:
Тогда у Вас и не будет создаваться куча объектов Promise (db.readString) в цикле
В любом случае, обработку (а это могут быть разные операции: чтение, парсинг строк/json etc) файлов лучше решать через Stream API NodeJs.
Возможно пригодится и Worker Threads API NodeJs (недавно появились).