Услышав от когото, а особенно на сисдизе "темы" и "разделы" вместо топиков и партишнов
Еще от коллег из российского бигтеха я часто слышу "партиции" вместо "разделов". Если кому то это не режет слух - я не против, но, пожалуйста, без меня.
А почему вдруг тут категоричное "или"? Кто помешает одновременно использовать и как очередь и как поток событий?
Никакого категоричного "или" и никто не мешает. Сразу после упомянутой вами цитаты в статье объясняются сценарии использования Kafka и их категоризация для того чтобы менее посвященному читателю было легче понять, что для чего нужно.
можно сразу заканчивать разговор без этого дальше разговор смысла не имеет, т.к. говорящий не знает как оно действительно работает
А я бы (и надеюсь многие другие интервьюеры) продолжил бы разговор с кандидатом, который не удовлетворил вашим требованиям. Kafka - лишь один из компонентов, который может использоваться при построении систем на System Design интервью. Хороший интервьер проверяет как кандидат мыслит и как подходит к решению возникающих вопросов.
Если прочитать статью, то в ней рассказывается какие проблемы, возникающие в распределенных системах решает Kafka, а так же для каких сценариев (и каких примеров задач) ее стоит рассмотреть на интервью:
Вот некоторые ситуации, когда стоит рассмотреть использование очереди сообщений
Потоки полезны в следующих случаях
Если на собеседовании вы можете спроектировать систему без Kafka, решив иным образом те проблемы, для решения которых она предназначена - имеете полное право на это.
Но будьте готовы к ситуации, когда интервьюер хочет услышать от вас именно понимание того зачем нужна эта технология (она с высокой вероятностью может использоваться в их компании). Поэтому если вы упорно полчаса решали задачи обеспечения обработки сообщений по порядку или обработки пиков нагрузки своими силами, у интервьюера может сложиться впечатление, что вы не слышали о Kafka и не знаете об общепринятых в индустрии способах решения этих проблем.
Если я сопру не ссылку, предназначенную для того, чтобы делиться, а ссылку, которая действует 5 минут. Проблема в том, что эта ссылка передается в урле. А значит, ее не получится зашифровать тем же ssl-ем.
Запрос на получение presigned URL - это обычный HTTPS запрос, который под SSL. При генерации presigned URL в открытом виде есть только на сервере в момент генерации и на клиенте, как ответ на клиентский запрос. "В дороге" presigned URL зашифрован SSL.
Что касается похода с клиента уже в облачное хранилище, то при прямом запросе в S3 presigned URL тоже защищён TLS, если ссылка c https. Query string с X-Amz-Signature не передаётся открытым текстом. Риск bearer URL не в пассивном сниффинге HTTPS-трафика, а в утечке самой ссылки из логов, истории, Referer, XSS, malware или TLS-inspection proxy.
тот же, кто может перехватить ваш url, будет по пути к вашему ip-адресу, а значит, сможет его подменить.
Подменить presigned URL подписанный HMAC с секретным ключом? Я надеюсь вы шутите
А может даже, чтобы модифицировать, если ссылка дает такие права. ... Ведь тогда я могу просто с другим валидным токеном (со своим токеном) воспользоваться этой ссылкой.
Мне кажется вы не очень хорошо понимаете как устроен, как работает и что можно сделать с presigned URL. Вы меня извините, но это тема отдельной статьи.
Presigned URL в данном случае - стандарт индустрии, используемый в реальном Dropbox. Впрочем, вы, конечно, в праве произвести революцию, если такое состояние дел вас не устраивает.
Данный вопрос подробно рассмотрен в статье, давайте я вам скопирую сюда
Но что произойдет, если авторизованный пользователь поделится ссылкой для скачивания с неавторизованным пользователем? Например, авторизованный пользователь может, намеренно или непреднамеренно, опубликовать ссылку для скачивания на общедоступном форуме или в социальных сетях, и нам необходимо убедиться, что неавторизованные пользователи не смогут скачать этот файл.
Здесь снова вступают в игру подписанные URL-адреса, о которых мы говорили ранее. Когда пользователь запрашивает ссылку для скачивания, мы генерируем подписанный URL-адрес, действительный только в течение короткого периода времени (например, 5 минут). Затем этот подписанный URL-адрес отправляется пользователю, который может использовать его для загрузки файла. Стоит отметить, что подписанные URL-адреса являются токенами “на предъявителя” (bearer token) - любой, у кого есть действительный, непросроченный URL-адрес, может загрузить файл. Короткий срок действия ограничивает уязвимость, но не полностью предотвращает распространение. Для более строгих сценариев безопасности можно добавить дополнительные ограничения, такие как привязка к IP-адресу, или потребовать использования подписанного URL-адреса в сочетании с аутентификационными файлами cookie.
pre-signed url - это так себе безпоасность. Все данные передаются в урле, а значит, их легко перехватить.
Настоящий Dropbox использует presigned URL. Я не встречал, если честно, таких обсуждений, где требования к безопасности для проектируемой на интервью системы должны быть выше чем у реального Dropbox. Если только это очень конкретная роль Security Engineer, и интервьюер хочет углубиться в эту часть.
Распишите подробнее векторы атаки, что вы делаете с перехваченными в url криптографически подписанными данными, с учетом того, что сами файлы в хранилище зашифрованы?
Кажется, здесь нужно работать со снапшотами, с happens before, с версиями...
Да, вполне, интервьюера могут интересовать вопросы аудита и версионирования, особенно если кандидату придется иметь дело с чем-то похожим в реальной работе. Именно поэтому очень важно очертить требования на этапе их сбора в начале интервью и согласовать с интервьюером. В данном случае, мы явно проговорили, что версионирование за рамками задачи.
Смежный тут очень интересный вопрос - разрешение конфликтов. В данной статье рассмотрена простая стратегия "last write wins". Интервьюер может попросить вас углубиться в этом направлении, и в данной статье это не рассматривается.
Не хочется втюхивать вам рекламу платного ресурса, уж извините, но если вдруг интересно - тема разрешения конфликтов через операциональное преобразование или через CRDT рассмотрена в задаче Google Docs на NowInterview.
судя по схеме, ходим в s3 без авторизации? На схеме стрелка идет мимо apiGW. И перехватив гет-запрос (айдишник то в юрл), или просто посканировав все возможные варианты, мы получаем содержимое чужих файлов?
Лучшим решением будет реализовать и загрузку, и скачивание напрямую из/в S3 используя presigned URL, то есть с авторизацией.
Обычно на интервью достаточно сказать presigned URL и интервьюеру все понятно про суть решения и как обеспечивается авторизация. В статье 3 раздел "Погружений в детали" полностью посвящен обсуждению безопасности файлов, прочитайте, пожалуйста, еще раз.
Это распространненый паттерн, используемый во многих продуктах, подробнее про него есть в статье "Работа с большими файлами" на NowInterview, но она, к сожалению в Premium подписке.
Плюс, вопрос к консистентности папки. Кажется, возможна ситуация, когда каждый файл сам по себе консистентен, но папка - нет. И возможна ситуация, когда часть файлов в папке старая, а часть - новая.
А вот это хороший вопрос, и в статье он не рассмотрен явно.
Действительно, фактически у нас есть основная БД (на наших серверах) которая хранит источник истины для системы в целом, и вероятно, на клиенте есть небольшая БД этого клиента, которая все знает о локальных папках и файлах. Наша задача - поддерживать эти БД в согласованном состоянии, но при попытках делать это в режиме реального времени (постоянной синхронизации), из-за багов, разрывов сети и прочих причин может возникать несогласованность, которую сложно подфиксить теми же механизамами.
Хорошим решением тут будет иметь отдельный фоновый процесс сверки (reconciliation), который запускается раз в день или раз в неделю, и работает не с дифами, как синхронизация, а с полным представлением обеих БД, и пытается привести их к общему виду. Если это возможно автоматически - приводит, если невозможно - показывает уведомление пользователю: в локальной папке - так, в облаке - так, выбирай, где истина.
1. Оценки масштаба (количества пользователей всего и активных, размер хранилища, RPS, трафик) - без них решения берутся с потолка
Здесь я с вами соглашусь лишь частично. Умение все это считать - требование для Middle кандидата. Неопытные кандидаты очень часто тратят на оценки слишком много времени, игнорируя большую часть результатов этих оценок. Staff+ кандидаты не тратят время на оценки, если они не имеют прямого непосредственного влияния на конкретную часть дизайна, которая сейчас рассматривается. Если прямо сейчас кандидат обсуждает нужно ли шардировать базу - самое время сделать оценки масштаба для принятия этого решения, это разумно. Но если кандидат просто посмотрел 10+ шаблонных видео на ютуб, в которых все так делают в начале интервью и поэтому он сделает так же - чтобы выглядеть "как архитектур" - это бесполезно, опытный интервьюер легко это считает.
Вы правы, требования зависят от роли, на которую вы претендуете. В конце данной статьи подробно рассказываются примерные требования для Middle, Senior и Staff кандидатов (не буду цитировать, чтобы не перепечатывать в комментарии всю статью).
Конечно в разных компаниях (и даже у разных интервьюеров) они могут отличаться. Если у вас есть возможность узнать детали того как проходит System Design интервью именно в вашу целевую компанию - я всегда рекомендую кандидатам так делать. Это хорошо и для кандидата: он будет лучше готов, для него меньше неожиданностей. И для интервьюера: не нужно тратить время на объяснения, интервьюер за часовое интервью успевает собрать все сигналы по областям компетенций, которые необходимы для роли. Конечно в рамках того, что в принципе возможно собрать за час (но тут интервьюер находится в рамках процесса найма, установленных в компании).
Что касается функциональных, нефункциональных требований, структуры интервью, шаблонных и нешаблонных решений и их обоснований - это большая тема для обсуждения, ее невозможно рассказать в комментариях.
Хороший набор статей о том, как правильно готовиться и проходить интервью, как выбирать по-настоящему важные, интересные и нешаблонные темы для детальной проработки можно найти на платформе NowInterview.
Я не знаю, что вам ответить кроме цитаты из статьи относящейся к CDN:
Проблемы
CDN-сети относительно дороги. Для решения этой проблемы обычно используют стратегический подход к тому, какие файлы кэшируются и как долго. Можно использовать заголовок управления кэшем, чтобы указать, как долго файл должен кэшироваться в CDN. Также можно использовать механизм аннулирования кэша для удаления файлов из CDN при их обновлении или удалении. Таким образом, кэшируются только часто используемые файлы, и мы не тратим деньги на кэширование файлов, к которым обращаются редко.
Нет, проактивность - это всё хорошо. Но SD интервью - это обычно 1-2 часа времени максимум. Это не работа (которая длится неделями, месяцами, годами). Это попытка за сверхсжатое время, за разговором понять уровень кандидата. И не всегда успешная.
Я полностью с вами согласен. Лично мне, чтобы полноценно оценить коллегу нужно тесно проработать с ним 6 месяцев. При этом процесс найма в крупных технологических компаниях устроен так, как устроен - мне дают 1 час на интервью и я должен после этого заполнить scorecard по кандидату по всем областям компетенций, фактически лично определившись с ответом на вопрос hire / no hire. И ошибиться тут в обе стороны (нанять того, кого не следовало бы, или отказать хорошему кандидату) - очень просто.
При этом я понимаю и компании - другого способа определить кого нанимать, а кого нет кроме как 3-6 часовых секций с разными интервьюерами никто пока не придумал. Поэтому мы работаем в тех условиях, которые есть - имеем часовую секцию System Design и пытаемся к ней готовиться так хорошо, как можем.
ИМХО, интервьюер находится в "нечестном выигрышном положении", ведь он многие задачи либо уже решал (и не за один час лол, а за дни и недели ресёрча, обсуждений, тестов), либо изучал детальные разборы типа этого. А кандидат - как правило, нет.
Мне кажется, что не стоит воспринимать интервью как соревнование кто умнее, интервьюер или кандидат. Конечно интервьюер давал эту задачу десятки раз, слышал разные идеи и знает ее вдоль и поперек. Хороший интервьюер - это peer, коллега, который помогает кандидату если тот застревает, теряет фокус или уходит не туда. Цель интервьюера - за один час собрать как можно больше сигналов по тем компетенциям, которые ожидаются от роли на которую собеседуется кандидат.
Я не знаю, сколько ticketmaster платит senior+, если это от $400k, то свёрхжесткие требования оправданы. Но ведь этот подход могут взять на вооружение и компании помельче, с значительно более скромными бюджетами. В результате таких собесов наиболее выигрышным будет смотреться кандидат, который каким-то образом вызубрил и насобачился именно к такому типа собеседования и вопросам, нередко - за счёт откровенного жульничества (привет "осознанным меркантилам" и прочим "волкам").
Это обучающая статья, ее цель - дать максимально полное представление о том, что важно\интересно\сложно в этой задаче по System Design.
Я надеюсь что после ознакомления и проработки кандидаты будут увереннее чувствовать себя на интервью, если им попадется эта или похожая задача.
Я провел десятки интервью и могу сказать из личного опыта - если кандидат хотя бы немного подготовился к интервью по тем материалам, которые ему дал рекрутер - это хороший кандидат. Как минимум это показывает, что кандидат обучаем, ответственен и сознателен настолько, чтобы немного поресерчить компанию, в которую идет. Я бы сказал что это уже выше среднего.
Я плохо знаю концепцию "осознанных меркантилов" и "волков", не могу сказать ничего по существу.
Но я твердо уверен, что готовиться к интервью (в том числе по System Design, узнавая с какими инженерными сложностями столкнулись разработчики популярных систем) - лучше, чем не готовиться.
Это обучающая статья, ее цель - дать максимально полное представление о том, что важно\интересно\сложно в этой задаче по System Design.
Я надеюсь что после ознакомления и проработки кандидаты будут увереннее чувствовать себя на интервью, если им попадется эта или похожая задача.
Да, интервью по System Design обычно длится 1 час (конечно, есть вариации в разных компаниях). Приблизительные требования для разных уровней кандидата описаны в конце статьи.
Для Middle кандидата ожидается High-Level дизайн, закрывающий функциональные требования + знание концепций и технологий + способность ответить на вопросы интервьюера.
Для Staff+ кандидата ожидается самостоятельная проработка 3+ из 6 рассмотренных в статье погружений в детали.
Предположу, что автор имел ввиду анализаторы типа тех, которые он упомянул в статье: RefactoringEssentials.
Не берусь судить странные они или нет.
Но большинство из них занимает менее 100 строк кода. Еще 100 — на CodeFix.
Мне кажется нужно сильно постараться, чтобы потратить на это больше одного человекодня.
Не спорю, что могут быть более сложные диагностики, анализирующие dataflow/controlflow, references, type inference и так далее, но даже на такие у нас уходило максимум 2-3 дня на один язык (С#).
Еще от коллег из российского бигтеха я часто слышу "партиции" вместо "разделов".
Если кому то это не режет слух - я не против, но, пожалуйста, без меня.
Никакого категоричного "или" и никто не мешает. Сразу после упомянутой вами цитаты в статье объясняются сценарии использования Kafka и их категоризация для того чтобы менее посвященному читателю было легче понять, что для чего нужно.
А я бы (и надеюсь многие другие интервьюеры) продолжил бы разговор с кандидатом, который не удовлетворил вашим требованиям. Kafka - лишь один из компонентов, который может использоваться при построении систем на System Design интервью.
Хороший интервьер проверяет как кандидат мыслит и как подходит к решению возникающих вопросов.
Понятно.
Если прочитать статью, то в ней рассказывается какие проблемы, возникающие в распределенных системах решает Kafka, а так же для каких сценариев (и каких примеров задач) ее стоит рассмотреть на интервью:
Если на собеседовании вы можете спроектировать систему без Kafka, решив иным образом те проблемы, для решения которых она предназначена - имеете полное право на это.
Но будьте готовы к ситуации, когда интервьюер хочет услышать от вас именно понимание того зачем нужна эта технология (она с высокой вероятностью может использоваться в их компании). Поэтому если вы упорно полчаса решали задачи обеспечения обработки сообщений по порядку или обработки пиков нагрузки своими силами, у интервьюера может сложиться впечатление, что вы не слышали о Kafka и не знаете об общепринятых в индустрии способах решения этих проблем.
Запрос на получение presigned URL - это обычный HTTPS запрос, который под SSL. При генерации presigned URL в открытом виде есть только на сервере в момент генерации и на клиенте, как ответ на клиентский запрос. "В дороге" presigned URL зашифрован SSL.
Что касается похода с клиента уже в облачное хранилище, то
при прямом запросе в S3 presigned URL тоже защищён TLS, если ссылка c https. Query string с X-Amz-Signature не передаётся открытым текстом. Риск bearer URL не в пассивном сниффинге HTTPS-трафика, а в утечке самой ссылки из логов, истории, Referer, XSS, malware или TLS-inspection proxy.
Подменить presigned URL подписанный HMAC с секретным ключом? Я надеюсь вы шутите
Мне кажется вы не очень хорошо понимаете как устроен, как работает и что можно сделать с presigned URL. Вы меня извините, но это тема отдельной статьи.
Presigned URL в данном случае - стандарт индустрии, используемый в реальном Dropbox.
Впрочем, вы, конечно, в праве произвести революцию, если такое состояние дел вас не устраивает.
Данный вопрос подробно рассмотрен в статье, давайте я вам скопирую сюда
Настоящий Dropbox использует presigned URL. Я не встречал, если честно, таких обсуждений, где требования к безопасности для проектируемой на интервью системы должны быть выше чем у реального Dropbox. Если только это очень конкретная роль Security Engineer, и интервьюер хочет углубиться в эту часть.
Распишите подробнее векторы атаки, что вы делаете с перехваченными в url криптографически подписанными данными, с учетом того, что сами файлы в хранилище зашифрованы?
Да, вполне, интервьюера могут интересовать вопросы аудита и версионирования, особенно если кандидату придется иметь дело с чем-то похожим в реальной работе. Именно поэтому очень важно очертить требования на этапе их сбора в начале интервью и согласовать с интервьюером. В данном случае, мы явно проговорили, что версионирование за рамками задачи.
Смежный тут очень интересный вопрос - разрешение конфликтов. В данной статье рассмотрена простая стратегия "last write wins". Интервьюер может попросить вас углубиться в этом направлении, и в данной статье это не рассматривается.
Не хочется втюхивать вам рекламу платного ресурса, уж извините, но если вдруг интересно - тема разрешения конфликтов через операциональное преобразование или через CRDT рассмотрена в задаче Google Docs на NowInterview.
Лучшим решением будет реализовать и загрузку, и скачивание напрямую из/в S3 используя presigned URL, то есть с авторизацией.
Обычно на интервью достаточно сказать presigned URL и интервьюеру все понятно про суть решения и как обеспечивается авторизация. В статье 3 раздел "Погружений в детали" полностью посвящен обсуждению безопасности файлов, прочитайте, пожалуйста, еще раз.
Это распространненый паттерн, используемый во многих продуктах, подробнее про него есть в статье "Работа с большими файлами" на NowInterview, но она, к сожалению в Premium подписке.
А вот это хороший вопрос, и в статье он не рассмотрен явно.
Действительно, фактически у нас есть основная БД (на наших серверах) которая хранит источник истины для системы в целом, и вероятно, на клиенте есть небольшая БД этого клиента, которая все знает о локальных папках и файлах. Наша задача - поддерживать эти БД в согласованном состоянии, но при попытках делать это в режиме реального времени (постоянной синхронизации), из-за багов, разрывов сети и прочих причин может возникать несогласованность, которую сложно подфиксить теми же механизамами.
Хорошим решением тут будет иметь отдельный фоновый процесс сверки (reconciliation), который запускается раз в день или раз в неделю, и работает не с дифами, как синхронизация, а с полным представлением обеих БД, и пытается привести их к общему виду. Если это возможно автоматически - приводит, если невозможно - показывает уведомление пользователю: в локальной папке - так, в облаке - так, выбирай, где истина.
Я и видео на ютуб записываю как нейронка. Да и вообще стоит признать, что я, в известном смысле, нейронка.
Вам спасибо за комментарий, рад, что было полезно!
Здесь я с вами соглашусь лишь частично. Умение все это считать - требование для Middle кандидата. Неопытные кандидаты очень часто тратят на оценки слишком много времени, игнорируя большую часть результатов этих оценок. Staff+ кандидаты не тратят время на оценки, если они не имеют прямого непосредственного влияния на конкретную часть дизайна, которая сейчас рассматривается. Если прямо сейчас кандидат обсуждает нужно ли шардировать базу - самое время сделать оценки масштаба для принятия этого решения, это разумно. Но если кандидат просто посмотрел 10+ шаблонных видео на ютуб, в которых все так делают в начале интервью и поэтому он сделает так же - чтобы выглядеть "как архитектур" - это бесполезно, опытный интервьюер легко это считает.
Вы правы, требования зависят от роли, на которую вы претендуете. В конце данной статьи подробно рассказываются примерные требования для Middle, Senior и Staff кандидатов (не буду цитировать, чтобы не перепечатывать в комментарии всю статью).
Конечно в разных компаниях (и даже у разных интервьюеров) они могут отличаться. Если у вас есть возможность узнать детали того как проходит System Design интервью именно в вашу целевую компанию - я всегда рекомендую кандидатам так делать. Это хорошо и для кандидата: он будет лучше готов, для него меньше неожиданностей. И для интервьюера: не нужно тратить время на объяснения, интервьюер за часовое интервью успевает собрать все сигналы по областям компетенций, которые необходимы для роли. Конечно в рамках того, что в принципе возможно собрать за час (но тут интервьюер находится в рамках процесса найма, установленных в компании).
Что касается функциональных, нефункциональных требований, структуры интервью, шаблонных и нешаблонных решений и их обоснований - это большая тема для обсуждения, ее невозможно рассказать в комментариях.
Хороший набор статей о том, как правильно готовиться и проходить интервью, как выбирать по-настоящему важные, интересные и нешаблонные темы для детальной проработки можно найти на платформе NowInterview.
Здравствуйте, спасибо за комментарий!
Я не знаю, что вам ответить кроме цитаты из статьи относящейся к CDN:
Я полностью с вами согласен. Лично мне, чтобы полноценно оценить коллегу нужно тесно проработать с ним 6 месяцев. При этом процесс найма в крупных технологических компаниях устроен так, как устроен - мне дают 1 час на интервью и я должен после этого заполнить scorecard по кандидату по всем областям компетенций, фактически лично определившись с ответом на вопрос hire / no hire. И ошибиться тут в обе стороны (нанять того, кого не следовало бы, или отказать хорошему кандидату) - очень просто.
При этом я понимаю и компании - другого способа определить кого нанимать, а кого нет кроме как 3-6 часовых секций с разными интервьюерами никто пока не придумал.
Поэтому мы работаем в тех условиях, которые есть - имеем часовую секцию System Design и пытаемся к ней готовиться так хорошо, как можем.
Мне кажется, что не стоит воспринимать интервью как соревнование кто умнее, интервьюер или кандидат. Конечно интервьюер давал эту задачу десятки раз, слышал разные идеи и знает ее вдоль и поперек. Хороший интервьюер - это peer, коллега, который помогает кандидату если тот застревает, теряет фокус или уходит не туда. Цель интервьюера - за один час собрать как можно больше сигналов по тем компетенциям, которые ожидаются от роли на которую собеседуется кандидат.
Это обучающая статья, ее цель - дать максимально полное представление о том, что важно\интересно\сложно в этой задаче по System Design.
Я надеюсь что после ознакомления и проработки кандидаты будут увереннее чувствовать себя на интервью, если им попадется эта или похожая задача.
Я провел десятки интервью и могу сказать из личного опыта - если кандидат хотя бы немного подготовился к интервью по тем материалам, которые ему дал рекрутер - это хороший кандидат. Как минимум это показывает, что кандидат обучаем, ответственен и сознателен настолько, чтобы немного поресерчить компанию, в которую идет. Я бы сказал что это уже выше среднего.
Я плохо знаю концепцию "осознанных меркантилов" и "волков", не могу сказать ничего по существу.
Но я твердо уверен, что готовиться к интервью (в том числе по System Design, узнавая с какими инженерными сложностями столкнулись разработчики популярных систем) - лучше, чем не готовиться.
Это обучающая статья, ее цель - дать максимально полное представление о том, что важно\интересно\сложно в этой задаче по System Design.
Я надеюсь что после ознакомления и проработки кандидаты будут увереннее чувствовать себя на интервью, если им попадется эта или похожая задача.
Да, интервью по System Design обычно длится 1 час (конечно, есть вариации в разных компаниях).
Приблизительные требования для разных уровней кандидата описаны в конце статьи.
Для Middle кандидата ожидается High-Level дизайн, закрывающий функциональные требования + знание концепций и технологий + способность ответить на вопросы интервьюера.
Для Staff+ кандидата ожидается самостоятельная проработка 3+ из 6 рассмотренных в статье погружений в детали.
Не берусь судить странные они или нет.
Но большинство из них занимает менее 100 строк кода. Еще 100 — на CodeFix.
Мне кажется нужно сильно постараться, чтобы потратить на это больше одного человекодня.
Не спорю, что могут быть более сложные диагностики, анализирующие dataflow/controlflow, references, type inference и так далее, но даже на такие у нас уходило максимум 2-3 дня на один язык (С#).