Верно, так и должно быть. Сначала идёт проектирование (DDD), а потом уже код.
Возможно, ошибочно сложилось впечатление, что от Вас посыл был несколько в обратном, что DDD не нужен. Хотя такая методология как раз и дает ответы на вопросы. Чтобы потом не приходилось переписывать код множество раз.
Никакой DDD и прочие заумные практики разработчикам уже не нужны (микросервисы и так обеспечивают bounded contexts)
Микросервисы это обеспечивают как раз потому, что есть такие «заумные» практики как DDD. Которые и помогают понять, как разделить предметную область на подобласти, а их уже на сервисы.
Спасибо за ответ! Конечно, точных цифр не ожидал услышать. Хоты бы порядок. Чтобы иметь представление по Вашему опыту, сколько времени уходит на подготовку к разработке/рефакторингу (непосредственная целенаправленная работа с кодом). Так как, повторюсь, для 10-ти летнего легаси рефакторинг за 3 месяца (пусть даже может и не все на самом деле, но большую часть отрефакторили) считаю отличный срок. Значит, подготовка была достаточно основательная. Поэтому и решил задать этот вопрос.
При синхронном чтение весь пишется в память. Если он у вас >= Гб, быстро память закончится.
Даже если меньше, и их у Вас несколько, но они читаются параллельно, тоже можете упереться в память.
Все должно быть в меру.
Проблема большинства, даже опытных программистов, в том, что они считают, что их имена переменным, методам, классам самые понятные для всех :) И поэтому не хотят сопровождать код комментариями вообще :)
Комментарии полезны, если они к месту.
TODO полезны, если они к месту.
FIXME полезны, если они к месту.
Верно, так и должно быть. Сначала идёт проектирование (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 (недавно появились).
Возможно, я не так понял эту мысль:
Не надо весь файл читать!
Если, конечно, метод получения данных из кэша тоже подразумевался асинхронным.
И далее в комментариях подобные примеры приводят с вероятностью, что рано или поздно Zalgo все же вылезет :)
Почитайте про “release zalgo”.
…
// Возвращаем true, если хэш не годен, и true — если хэш годен
…
:)
Прислушайтесь к рекомендациям, которые Вам тут дают.
Не пишите обучающие статьи, пока сами не разберётесь в тематике и инструментах, которые используете (упоминаете в статье).
Проблема большинства, даже опытных программистов, в том, что они считают, что их имена переменным, методам, классам самые понятные для всех :) И поэтому не хотят сопровождать код комментариями вообще :)
Комментарии полезны, если они к месту.
TODO полезны, если они к месту.
FIXME полезны, если они к месту.
(с) Кэп.