Как стать автором
Обновить
10
0
Алексей @RA_ZeroTech

Программист, TeamLead

Отправить сообщение

Верно, так и должно быть. Сначала идёт проектирование (DDD), а потом уже код.

Возможно, ошибочно сложилось впечатление, что от Вас посыл был несколько в обратном, что DDD не нужен. Хотя такая методология как раз и дает ответы на вопросы. Чтобы потом не приходилось переписывать код множество раз.

Правило думали.

Никакой DDD и прочие заумные практики разработчикам уже не нужны (микросервисы и так обеспечивают bounded contexts)

Микросервисы это обеспечивают как раз потому, что есть такие «заумные» практики как DDD. Которые и помогают понять, как разделить предметную область на подобласти, а их уже на сервисы.

Преподносить инспекцию кода, code review как инстурмент мщения - это совсем не командная работа.

Или это такой скрытый юмор в статье?

Спасибо за ответ! Конечно, точных цифр не ожидал услышать. Хоты бы порядок. Чтобы иметь представление по Вашему опыту, сколько времени уходит на подготовку к разработке/рефакторингу (непосредственная целенаправленная работа с кодом).
Так как, повторюсь, для 10-ти летнего легаси рефакторинг за 3 месяца (пусть даже может и не все на самом деле, но большую часть отрефакторили) считаю отличный срок. Значит, подготовка была достаточно основательная. Поэтому и решил задать этот вопрос.

А так же интересно, сколько времени ушло на этапы: инициализация, планирование, анализ, проектирование.

Хотя бы в сумме. Но лучше в отдельности :)

Так три месяца на рефакторинг звучит, конечно, круто и достойно. Но и предыдущие этапы не пару дней заняли? :)

Спасибо Вам, что подхватили поддержку публикации дайджеста. Очень полезно!

Плюс к этому, там же (у developer.mozilla.org), что это ещё экспериментальная вещь.


А здесь в статье ни слова об этом. Хотя бы ссылку на поддержку браузеров.

file.json — каких объемов файл?

При синхронном чтение весь пишется в память. Если он у вас >= Гб, быстро память закончится.
Даже если меньше, и их у Вас несколько, но они читаются параллельно, тоже можете упереться в память.
К тому же, судя по коду, чтение файла происходит всего сразу. Это лишнее. И это совсем не стрим уже.

На node js у Вас должно получиться что-то вроде (условно):
FileReadStream.pipe(ParseStream).pipe(WriteStream)


где:
  • FileRead — читаем файл «кусками», а не весь сразу
  • ParseStream — обработка «кусков» по мере их чтения (у Вас это JSON)
  • WriteStream — если надо, сохраняем куда нужно результат обработки «кусков» (кэш, БД etc.)


Тогда у Вас и не будет создаваться куча объектов Promise (db.readString) в цикле

while(true) {
...
const chunk = await db.readString('\x01')
...
}
У вас сразу идёт чтение файла openSync — синхронно? Зачем?
От целей и задачи зависит. Может весь, может нет.

В любом случае, обработку (а это могут быть разные операции: чтение, парсинг строк/json etc) файлов лучше решать через Stream API NodeJs.

Возможно пригодится и Worker Threads API NodeJs (недавно появились).
Я, вроде, и не предлагал читать весь файл?


Возможно, я не так понял эту мысль:
Тут нужно сначала в один проход заполнить всеми нужными данными кэш, а потом во второй проход синхронно его обрабатывать.
Потоки в ноде.
А чем для этого на устраивают потоки в норде? :)
Не надо весь файл читать!
Только в выше приведённых примерах Kozack это не так.

Если, конечно, метод получения данных из кэша тоже подразумевался асинхронным.

И далее в комментариях подобные примеры приводят с вероятностью, что рано или поздно Zalgo все же вылезет :)
Вот так как раз не надо делать. Функция должна быть полностью синхронной или асинхронной.

Почитайте про “release zalgo”.
И комментарии «забавные»


// Возвращаем true, если хэш не годен, и true — если хэш годен


:)
Так и не исправили.
Прислушайтесь к рекомендациям, которые Вам тут дают.

Не пишите обучающие статьи, пока сами не разберётесь в тематике и инструментах, которые используете (упоминаете в статье).
Статья не протестирована. Есть дубли «кода» :) А именно, чем пп 1.9 отличается от пп 2.7? :)
Все должно быть в меру.
Проблема большинства, даже опытных программистов, в том, что они считают, что их имена переменным, методам, классам самые понятные для всех :) И поэтому не хотят сопровождать код комментариями вообще :)

Комментарии полезны, если они к месту.
TODO полезны, если они к месту.
FIXME полезны, если они к месту.

(с) Кэп.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность