Мне кажется сначала надо явно сказать про каких архитекторов мы в статье говорим, потому что мифы будут на каждом уровне разные. А так в начале сказали про виды архитекторов и потом все равно всех смешали.
У меня есть замечание к статье - оно в разделе "Выбор базы данных"
На настоящем System Design собесе вас как раз попросят объяснить выбор PostgreSQL и ответ типа:
> Будем использовать реляционную СУБД PostgreSQL. Потому что наша таблица имеет строгую структуру и нам важна быстрота
Вас не спасет. Как раз это тот вопрос и то место, которое точно "будут качать", а по формулировке почти любая БД вам подойдет (плюс непонятно при чем тут строгая структура).
Второй важный момент, который упущен, это то, как вы будете генерировать уникальные короткие ссылки - ответ на этот вопрос как раз влияет на архитектуру и нагрузку очень серьезно.
Вот эти два момента - они основные и вам надо их доработать. А статья написана аккуратно, читать приятно было.
Вот где вы написали про "Когда оборачивать ошибку не лучшая идея" По сути все в том, что изменился тип ошибки (как вы и написали) и вызывающий код теперь ничего не знает о том, что возвращается.
Но! Это (кмк) не проблема - потому что раз ошибка поменялась, значит и реакция должна поменяться, если же это не так, то скорее всего надо делать ошибку более общую (тогда и менять ее не надо) - например ValidateError.
Поэтому тут особой проблемы я не вижу (если работать через As также)
В общем, я не совсем понял в том месте вашу идею и мысль.
Зависит от области эксперта. Выделение областей ответственности, закрепление за ними людей (не джунов) и постоянное прохождение, взаимодействие этих людей в своей области - вплоть до мини демо узким кругом. Сбор статистики по задачам эксперта и прохождению этих задач другим человеком по следам эксперта, по направлению каждому выделить и сделать хотя бы задачу одну новым замещающим , выключение эксперта из процесса разработки - влияния активного, желательно вообще договориться о выходе не за 2 недели, а подольше (за премию).
но все очень специфично, в общем виде я бы так видел.
Все советы довольно очевидные и нет самого главного. Мало сказать «выгружайте информацию из эксперта», «информация должна быть понятна» - это и так очевидные вещи. Важно было раскрыть как провалилировать, что эта область знаний уже не только «у эксперта». Валидация на «новичках» как вскользь было предложено - это неверно. Это бонус, но не является тем, что все ок.
Ну, я об этом примерно и пишу - что это метрика, что что-то не так. Что именно часто зависит от контекста и задачи, поэтому сужать до деления контекстов я не стал, хотя это чаще всего(хоть и не всегда) именно та самая проблема.
Поэтому обычно берут при проектировании на собеседовании лучшие цифры, по максимуму. Но! Это очень хороший вопрос и, например, такое могут спросить в конце при обсуждении железа.
Но при HLD и LLD секциях обычно считать можно очень примерно и идеальные случаи
Не очень понимаю целевую аудиторию для статьи, она больше выглядит как обоснование для менеджера, чтобы мы это сделали. Для разработчика же этот материал почти бессмысленный, на мой взгляд.
Представьте себе популярный магазин, в который постоянно ходят посетители. Все ходят в обуви и, в зависимости от погоды, пол и ковры покрываются грязью. Этот процесс неизбежен и все это понимают. Но тут приходит менеджер и говорит: у нас нет времени и ресурсов на то, чтобы заменить ковры, помыть пол - даже 10 минут не можем выделить! Только фичи (торговля), только вперед!
Через какое-то время становится все сложнее находится в помещении, появляются уже не прошенные жильцы (от грязи), появляется запах и со временем в помещении уже трудно находится. Это приводит к тому, что сначала начинают уходить сотрудники (кто постоянно в этом помещении), а после уже и на посетителей-клиентов это начинает влиять (баги, сложность в поддержании качества продукта, скорость появления новых фич).
Чтобы этого не было вводится некий санитарный час, в рамках которого происходит уборка (есть график дежурств) и проблема решена!
Какой из вариантов выбрать - спросите своего менеджера!
Это все работает и красиво до момента, когда не становится необходимо усложнять пользовательский сценарий и не нужна дополнительная информация.
Когда, например, заказ большой, хочется более подробно о каждой единице посмотреть, что-то исключить может и так далее.
А это неизбежно с ростом пользовательской базы.
Запись в клинику - вполне возможно, что там будет забиты окна и вы будете уже пытаться в них попасть наугад, либо вы хотите быстро переключиться и сравнить два дня по загруженности и так далее, что снова возвращает нас к тому, что надо усложнять вывод, а значит и UX.
В общем, это утопия про минимализм и революционный подход.
Не соглашусь, так как вы же показываете новичку это и явно то, что максимально не будет применяться и по сути является ошибочным показывать не стоит - чтобы не смущать. Лучше показать правильные и используемые варианты (кмк).
Ситуация, когда IT-подрядчик в лице уволенного сотрудника проникает и отключает все - это показывает проблему с информационной безопасностью и ее остроту. Музей либо решил неплохо сэкономить на подрядчиках, либо подрядчик после такого должен быть закрыт и разориться: потому что это уже не просто метрика, это красный флаг, что после увольнения/расторжения договора оказывается не вся интеллектуальная собственность и возможность управление ею осталась у музея.
На мой взгляд, невозможно победить тревогу и ее рост в современно мире - слишком много информации со всех сторон. Но можно контролировать ее, однако для этого необходима самодисциплина и работа над собой: физическая активность, сон и здоровые привычки, уменьшение или исключение алкоголя (депресантов), информационная гигиена, понимание себя - что вас 'накручивает' и насколько вы сами себя можете 'накрутить', избегание этих ситуаций. Возможно, где-то смена работы на более простую и менее стрессовую.
Мне кажется, вариант с абсолютным путем зашитым в коде практически никогда не должен использоваться: в разработке многие используют разные ОС, плюс при переносе в CI/CD надо будет менять снова код.
Мне кажется сначала надо явно сказать про каких архитекторов мы в статье говорим, потому что мифы будут на каждом уровне разные. А так в начале сказали про виды архитекторов и потом все равно всех смешали.
Мне кажется тех, кто не любит систем дизайн стало последнее время больше)
Эта заметка, такое впечатление, что написана "на скорую руку" и цель у нее "чтоб была". Даже примера применения нет.
Особенно странно выглядят операции с деньгами (по сути придуманные - или откуда взятые цифры?),
У меня есть замечание к статье - оно в разделе "Выбор базы данных"
На настоящем System Design собесе вас как раз попросят объяснить выбор PostgreSQL и ответ типа:
> Будем использовать реляционную СУБД PostgreSQL. Потому что наша таблица имеет строгую структуру и нам важна быстрота
Вас не спасет. Как раз это тот вопрос и то место, которое точно "будут качать", а по формулировке почти любая БД вам подойдет (плюс непонятно при чем тут строгая структура).
Второй важный момент, который упущен, это то, как вы будете генерировать уникальные короткие ссылки - ответ на этот вопрос как раз влияет на архитектуру и нагрузку очень серьезно.
Вот эти два момента - они основные и вам надо их доработать. А статья написана аккуратно, читать приятно было.
Вот где вы написали про "Когда оборачивать ошибку не лучшая идея"
По сути все в том, что изменился тип ошибки (как вы и написали) и вызывающий код теперь ничего не знает о том, что возвращается.
Но! Это (кмк) не проблема - потому что раз ошибка поменялась, значит и реакция должна поменяться, если же это не так, то скорее всего надо делать ошибку более общую (тогда и менять ее не надо) - например ValidateError.
Поэтому тут особой проблемы я не вижу (если работать через As также)
В общем, я не совсем понял в том месте вашу идею и мысль.
Зависит от области эксперта. Выделение областей ответственности, закрепление за ними людей (не джунов) и постоянное прохождение, взаимодействие этих людей в своей области - вплоть до мини демо узким кругом. Сбор статистики по задачам эксперта и прохождению этих задач другим человеком по следам эксперта, по направлению каждому выделить и сделать хотя бы задачу одну новым замещающим , выключение эксперта из процесса разработки - влияния активного, желательно вообще договориться о выходе не за 2 недели, а подольше (за премию).
но все очень специфично, в общем виде я бы так видел.
Все советы довольно очевидные и нет самого главного. Мало сказать «выгружайте информацию из эксперта», «информация должна быть понятна» - это и так очевидные вещи. Важно было раскрыть как провалилировать, что эта область знаний уже не только «у эксперта». Валидация на «новичках» как вскользь было предложено - это неверно. Это бонус, но не является тем, что все ок.
В общем, самое главное не раскрыли.
Странно смотреть на статью в формате «как это поможет на работе» (судя по итогу), если в самом начале написано, что он же для подготовки к секции!
Но у этой секции есть плюсы же (но и минусов хватает), разве нет?
Что именно? Сам такой собес как этап?
Ну, я об этом примерно и пишу - что это метрика, что что-то не так. Что именно часто зависит от контекста и задачи, поэтому сужать до деления контекстов я не стал, хотя это чаще всего(хоть и не всегда) именно та самая проблема.
На мой взгляд книге не хватает глубины - останавливаются в ней всегда на самом важном и интересном месте
Ну и про другие направления верно подмечено.
Абсолютно так и есть! Более того, я считаю, что этой книжки вообще недостаточно и это можно только как введение использовать.
Поэтому обычно берут при проектировании на собеседовании лучшие цифры, по максимуму. Но! Это очень хороший вопрос и, например, такое могут спросить в конце при обсуждении железа.
Но при HLD и LLD секциях обычно считать можно очень примерно и идеальные случаи
Не очень понимаю целевую аудиторию для статьи, она больше выглядит как обоснование для менеджера, чтобы мы это сделали. Для разработчика же этот материал почти бессмысленный, на мой взгляд.
Представьте себе популярный магазин, в который постоянно ходят посетители. Все ходят в обуви и, в зависимости от погоды, пол и ковры покрываются грязью. Этот процесс неизбежен и все это понимают. Но тут приходит менеджер и говорит: у нас нет времени и ресурсов на то, чтобы заменить ковры, помыть пол - даже 10 минут не можем выделить! Только фичи (торговля), только вперед!
Через какое-то время становится все сложнее находится в помещении, появляются уже не прошенные жильцы (от грязи), появляется запах и со временем в помещении уже трудно находится. Это приводит к тому, что сначала начинают уходить сотрудники (кто постоянно в этом помещении), а после уже и на посетителей-клиентов это начинает влиять (баги, сложность в поддержании качества продукта, скорость появления новых фич).
Чтобы этого не было вводится некий санитарный час, в рамках которого происходит уборка (есть график дежурств) и проблема решена!
Какой из вариантов выбрать - спросите своего менеджера!
Это все работает и красиво до момента, когда не становится необходимо усложнять пользовательский сценарий и не нужна дополнительная информация.
Когда, например, заказ большой, хочется более подробно о каждой единице посмотреть, что-то исключить может и так далее.
А это неизбежно с ростом пользовательской базы.
Запись в клинику - вполне возможно, что там будет забиты окна и вы будете уже пытаться в них попасть наугад, либо вы хотите быстро переключиться и сравнить два дня по загруженности и так далее, что снова возвращает нас к тому, что надо усложнять вывод, а значит и UX.
В общем, это утопия про минимализм и революционный подход.
Не соглашусь, так как вы же показываете новичку это и явно то, что максимально не будет применяться и по сути является ошибочным показывать не стоит - чтобы не смущать. Лучше показать правильные и используемые варианты (кмк).
Ситуация, когда IT-подрядчик в лице уволенного сотрудника проникает и отключает все - это показывает проблему с информационной безопасностью и ее остроту. Музей либо решил неплохо сэкономить на подрядчиках, либо подрядчик после такого должен быть закрыт и разориться: потому что это уже не просто метрика, это красный флаг, что после увольнения/расторжения договора оказывается не вся интеллектуальная собственность и возможность управление ею осталась у музея.
На мой взгляд, невозможно победить тревогу и ее рост в современно мире - слишком много информации со всех сторон. Но можно контролировать ее, однако для этого необходима самодисциплина и работа над собой: физическая активность, сон и здоровые привычки, уменьшение или исключение алкоголя (депресантов), информационная гигиена, понимание себя - что вас 'накручивает' и насколько вы сами себя можете 'накрутить', избегание этих ситуаций. Возможно, где-то смена работы на более простую и менее стрессовую.
Мне кажется, вариант с абсолютным путем зашитым в коде практически никогда не должен использоваться: в разработке многие используют разные ОС, плюс при переносе в CI/CD надо будет менять снова код.