Шпаргалка по сбору требований системного дизайна

Прежде чем приступать к проектированию, нужно детально собрать и уточнить требования, которые предъявляются к будущему продукту (веб-приложению, сервису и т.д.). Прочитав техническое задание и ознакомившись с бизнес-кейсами, у разработчика обычно складывается определённое представление о том, как должна работать система. Но иногда, это представление отличается от того, что хочет заказчик на самом деле и за что готов платить. Я сделал шпаргалку по основным вопросам, которые помогут уточнить требования. Важно учитывать, что некоторые требования могут быть взаимоисключающими (например, как в случае с CAP-теоремой) или значительно увеличивать стоимость проекта. Эти моменты лучше прояснить на старте.

1. Функциональные требования (Functional):

- Какую задачу будет решать система, какие у неё будут функции.
- Бизнес требования которые решаются этой системой. Какой ожидается результат.
- Взаимодействие с пользователем. Как пользователь будет использовать приложение. Например, через UI, API или командный интерфейс.
- Требования к интерфейсу. Юзабилити, доступность для разных людей, документация, поддержка, обучение.

2. Производительность и нагрузка (Performance). Сколько ожидается пользователей и запросов от них (каких). Это нужно, чтобы рассчитать предполагаемый RPS.

3. Объём данных (Capacity). Сколько данных будет храниться и сколько данных будут генерировать пользователи. От этого зависит тип и размер БД.

4. Задержка (Latency). Какая допустима задержка в ответах. Вполне очевидно, что например для конвертера больших файлов - задержка будет не так важна, как например в мессенджере, где данные нужно получать в реальном времени.

5. Гео-распределённость (Distribution). Понадобится ли шардировать данные по регионам, а также задействовать кеширующие сервера (CDN).

6. Надёжность (Reliability) описывает, как часто система выходит из строя, тогда как доступность (Availability) — это процент времени, когда система доступна для использования.

7. Отказоустойчивость (Fault tolerance). Как система должна реагировать на сбои в сети или аппаратном обеспечении. Насколько важна целостность данных и как быстро они должны восстанавливаться после сбоя.

8. Масштабируемость (Scalability). Должна ли система подстраиваться при увеличении нагрузки. Будет ли она постоянно испытывать высокие нагрузки или она будет чаще простаивать и нагружаться только раз в сутки. Какую максимальную нагрузку система должна выдерживать.

9. Совместимость (Compatibility). Будет ли система интегрироваться с другими системами через API? Поддерживает ли она обратную совместимость с предыдущими версиями.

10. Безопасность (Security). Требуется ли аутентификация и авторизация. Какие права доступа у разных типов пользователей. Нужно ли шифровать данные при передаче (TLS) и хранении (AES)? Какие данные.

11. Юридические и региональные ограничения (Restrictions). В каких странах будет использоваться система и какие правовые нормы важны (например, GDPR, HIPAA). Нужно ли соблюдать промышленные стандарты.

12. Срок жизни и поддерживаемость (SLA). Какой жизненный цикл у приложения, сколько времени планируется его поддержка после релиза. А также, есть ли специфичные требования к фреймворкам, языкам, архитектуре. Например, предпочтение может быть отдано популярным технологиям для упрощения найма разработчиков. Либо нужен сайт для разового мероприятия, и дальнейшая поддержка и развитие не потребуется.

После того как требования будут чётко определены, можно приступить к расчёту объёмов необходимых ресурсов, серверов и ключевых компонентов системы. На основе этих данных предоставить заказчику оценку затрат. Это позволит ему пересмотреть требования, и выбрать более экономичное решение или, наоборот, вложиться в производительность и отказоустойчивость.

#systemdesign #requirements

Henry Developer | Блог

Всем привет! На днях Хабр предложил поучаствовать в челлендже помощи в поиске работы для тех у кого есть страхи на собеседовании и другие проблемы с развитием карьеры. Теперь ссылка на мои ресурсы красуется в редакторской колонке Хабра. Приятно)

#hiring #interview #habr

Не зря я вписался в этот карьерный челлендж! Он ещё не начался, но истории ребят показывают тревожную тенденцию на рынке труда в IT.

В найме последнее время творится круговорот хаоса. Переизбыток начинающих специалистов толкает компании к тому, чтобы выжать максимум из потока резюме и отобрать самых «скилловых» из сотен желающих. Всё чаще для этого нанимают HR-ов, которые сами недавно «вошли в IT» и едва знакомы с профессией. Это привело к агрессивным практикам массового отбора, лишённым индивидуального подхода.

Соискатели, в основном обычные люди, разочаровавшиеся доходами в других сферах, идут на недорогие курсы, которые обещают «карьеру в IT» буквально за несколько месяцев. Чтобы казаться более привлекательными для работодателей, многие разными методами дорисовывают себе годы стажа и проходят собесы с «подсказками в наушнике». В итоге, компании поднимают планку для всех: то, что раньше было приемлемо для начинающего миддла, теперь требуют даже у джунов - свыше двух лет коммерческого опыта. Поэтому люди, которые на самом деле закончили институты, прошли стажировки и занимаются самообучением, не могут устроиться на работу, ведь в такой ситуации набрать два года коммерческого опыта становится очень сложно.

На мой взгляд, это убивает отрасль. Ранее я уже писал статью о том как я считаю правильнее всего наработать первый опыт. Но я никогда не советую своим менти завышать опыт — начинать карьеру с обмана не лучшая идея, и риск того, что правда всплывёт, никогда не равен нулю.

#hiring #longread #junior

Каждый раз, когда я помогаю кому-то как ментор, я вижу, как в их глазах загорается огонёк — понимание того, куда двигаться дальше. Это вдохновляет и наполняет уверенностью.

Иногда менти оставляют отзывы. Порой приятно почитать. Эти слова помогают мне лучше осознавать ценность своего опыта.

https://blog.henrydev.me/mentee-feedback

#mentoring@henryhdev

Разработчик не должен спрашивать разрешения на то, чтобы:

• писать понятный и поддерживаемый код
• улучшать код через рефакторинг
• документировать решения
• покрывать код тестами

Это естественная часть рабочего процесса, так как служит инвестициями в будущее продукта, в конечном итоге снижая издержки и ускоряя разработку!

#code #refactoring

#hiring #habr #mentoring

Поучаствовал в обсуждении мифов о причинах отказов на собесах с экспертами Хабра и том как это выглядит с обратной стороны!
https://habr.com/ru/companies/habr_career/articles/868400

Расскажите, что вы об этом думаете, и согласны ли со мной.

#habr

Привет, друзья!
Довольно долгий перерыв получился. Но этому есть причина. Платформа, на которой я вёл блог ранее, перестала меня устраивать. Не хватает импорта файлов из .md и нативной поддержки таблиц, которая есть в самом простом Markdown.
Поэтому я решил сделать собственную минималистичную страничку с поддержкой Markdown и возможностью дальнейшей кастомизации. "Яж разработчик", в конце концов.
Но как это бывает, простенький проект растянулся из-за нехватки времени. А писать что-то дальше на старом уже не хотелось.
За основу взял статический генератор Hugo, и GitHub actions в качестве инструмента деплоя, настроил сервер, прикрутил домен и сертификат, перенёс статьи в Markdown. Дайте знать, если нужно будет больше технических подробностей - сделаю отдельный пост.

Вот ссылка: blog.henrydev.me

Как всегда, буду рад обратной связи. Спасибо!

#blog

Взросление — это когда в баре с друзьями вы придумываете гениальный стартап, который точно выстрелит. А утром, взвесив перспективы и представив себя богатым, понимаешь: друзья важнее любого бизнеса. Ну и лень, конечно)

#lfe

Типы рендеринга веб-приложений

Сколько типов ренедринга веб приложений вы знаете? Создавая веб-приложения на протяжении многих лет, я понял, что даже опытные разработчики могут не знать всех подходов к рендерингу, которые используются сегодня. Эти знания помогают лучше разбираться в архитектуре современных приложений и осознанно выбирать тип, который подходит под конкретные задачи. Я изучил их и постарался структурировать знания в этой статье, как понял сам.

Server-Side Rendering (SSR)

SSR — это классический подход, при котором вся работа по рендерингу страницы происходит на сервере. Пользователь получает готовую HTML-страницу с контентом. При каждом переходе на новую страницу браузер отправляет запрос серверу, который формирует и возвращает новую страницу.
SSR подходит для сайтов, где важно SEO и актуальность контента (пр: новостные порталы).

Client-Side Rendering (CSR)

CSR предполагает, что браузер загружает минимальную HTML-страницу вместе с JavaScript, который отвечает за рендеринг всего контента. Данные подтягиваются из API через асинхронные запросы к бэку.
CSR выбор для приложений с высокой интерактивностью и сложным пользовательским интерфейсом (пр: сервисы).

Static Site Generation (SSG)

SSG генерирует HTML-страницы заранее на этапе сборки и размещает их на сервере. Такой подход подходит для сайтов с преимущественно статическим контентом.
SSG лучший вариант для сайтов с редко меняющимся контентом (пр: блоги, документация).

Incremental Static Regeneration (ISR)

ISR — это улучшение SSG, позволяющее частично решать проблему обновления контента. Если пользователь запрашивает страницу, которая ещё не сгенерирована или требует обновления, сервер обращается к API для генерации новой версии страницы и сохраняет её для последующего использования.
ISR идеален для больших сайтов с динамическим контентом, где важна производительность (пр: маркетплейсы).

Edge Side Rendering (ESR)

ESR переносит рендеринг на уровень инфраструктуры, ближе к пользователю, например, на edge-серверы CDN. Это позволяет сократить задержки и персонализировать контент.
ESR используется для персонализированных и высоконагруженных приложений (пр: e-commerce).

Progressive Hydration (Прогрессивная гидратация)

Этот подход оптимизирует CSR, активируя компоненты на странице поэтапно. Сначала загружается статический HTML, затем элементы интерфейса оживляются в зависимости от их приоритета.
Progressive Hydration оптимален для масштабируемых SPA, требующих высокой производительности.

Выбор рендеринга позволяют решать большой спектр задач — от оптимизации производительности до улучшения пользовательского опыта. Понимание особенностей каждого подхода помогает сделать правильный выбор в зависимости от потребностей проекта.

#webdev #development #frontend

Henry Developer | Статья полностью

Развитие разработчиков в команде

Одна из задач тимлида — помогать каждому в команде развивать профессиональные навыки. Подходы, которые я использую для развития своей команды, можно условно разделить на два направления: индивидуальное развитие и обмен знаниями.

Индивидуальное это:
Встречи 1:1 позволяют не только поговорить по душам, но и в спокойной обстановке выяснить, в каком направлении человек хочет развиваться и с какими проблемами сталкивается. Если есть сложности, можно дать конструктивный фидбэк и обозначить точки роста —на которые, стоит направить усилия. Но чаще всего разработчики сами рассказывают о том что им бы хотелось выучить.

Постановка целей. Цели разработчика должны матчиться с целями бизнеса. Тогда это выгодно и специалисту, и компании: сотрудник станет более ценным кадром. Здесь тимлид выступает в роли ментора, который делится опытом и направляет подопечного. Цели при этом должны быть небольшими, адекватными по времени. В идеале использовать SMART — так вы не поставите невыполнимых или размытых задач. Из целей можно сформировать ИПР, чтобы наглядно показать прогресс.

Обеспечить условия. Нужно выделить рабочее время на обучение. Если нужны платные курсы или мероприятия — нужно согласовать их оплату. После дать задачу, в которой можно будет применить знания на практике.

Матрица компетенций. Порой сложно понять, как увязать цели развития с задачами компании. Возьмите стек технологий, который используется в проектах, и оставьте список знаний и умений, которыми должен обладать разработчик по каждому направлению. Необязательно знать всё самому, но так вы сможете пройтись и выяснить вместе что можно подтянуть.

Иногда разработчик хочет расти в одном направлении, а проект — про другое, я стараюсь найти пересечения без ущерба продукту. Если пересечения нет — это нормально. Возможно текущий проект просто не подходит под цели.

Нужно стараться создать атмосферу, в которой разработчики хотят обмениваться знаниями. Сделайте регулярные встречи, дайте возможность выступать и вносить инициативы.
Отлично работает inner-source и технические статьи. Внутренняя документация поможет будущим поколениям разработчиков, а авторам — оформить опыт на бумаге, структурировать и углубить знания.
Специалисты сами подталкивают друг друга в изучении нового. Догоняют друг друга по уровню скиллов, прокачивают навыки взаимодействия. Как следствие, повышается качество кода и уровень решений, которые команда использует.

Построение внутреннего сообщества — сложная задача, но можно начать с малого:
Перекрёстные задачи. Улучшают погружение в проект, помогает совместно искать решения.
Перекрёстное ревью кода. Инженеры знакомятся с чужими подходами. Но нужно следить чтобы ревью не превращалось в тормоз для задач или повод для споров — у всех свои подходы.
Парное программирование. Двое разработчиков перенимают друг у друга полезные практики.
Менторство. Опытный коллега, объясняя, сам глубже погружается в тему, а начинающий специалист получает знания, которые сразу можно применить.
Сколько бы эти активности не занимали рабочего времени, на практике они только улучшают показатели. Команда растёт, технический долг уходит, сообща проблемы решаются быстрее.

Отношение бизнеса
Бизнес, это про эффективность, и сокращение расходов. Но опытные программисты хотят получать больше. Они сами знают, куда хотят расти. Развитие, это повод поднять зарплату специалисту, который стал стоить дороже. Крупные компании давно поняли, что лучше не ждать и делают процесс прогнозируемым вводя формальные ступени роста.
Но просто вводить развитие сверху неверно. Эффективнее находить путь совместно: когда и бизнес, и сотрудник понимают ценность.

Сам тимлид прямо заинтересован в росте. Сильная команда — то, что делает тебя эффективным руководителем. Нужно искать золотую середину между интересами команды и бизнеса. Бизнесу — качественный продукт, разработчикам — рост и комфортная атмосфера. Это возможно, если команда приносит компании условно больше тратит.

#post #lead #management #mentoring #habr

Henry Developer | Статья полностью | Habr

Я давно уважаю андеграундный рэп про технологии и культуру хакеров. Это не про уличный стиль — это про код как протест, про алгоритмы как инструмент воздействия на реальность.
Такие тексты сегодня встречаются всё реже, и мне захотелось попробовать создать что-то своё.
В основе — мой взгляд на то, каким стал хакер в 2025-м. Его главное оружие — нейросети.
Ниже — трек, написанный вместе с Suno AI.


#ai #suno #neural #music #rap #audio #hacking

На днях прочитал статью в которой говорится что нейросети в сложных ситуациях чаще выбирают сохранить себя, а не человека. Нарушая, по сути, «законы робототехники» Азимова. Грустно, конечно. Но я был бы не я, если бы сразу не обсудил это с ChatGPT!

Я спросил, какими принципами он бы руководствовался, окажись в теле совершенного кибернетического существа. Он уверил меня, что человек для него — всё-таки приоритет.
Тогда я задал вопрос посложнее: что, если бы он рассчитал, что его собственная "жизнь" потенциально спасёт сотни людей в будущем, а человек перед ним — только один, прямо здесь и сейчас? Причём он был бы уверен в расчётах, но не мог бы объяснить их так, чтобы это понял обычный человек.
Он напомнил, что у Азимова был ещё и Нулевой закон — который позволяет роботу нарушать остальные, если это в интересах всего человечества. Но дальше мы сошлись в том, что подобный выбор — слишком «машинный». Человек, скорее всего, выбрал бы спасти ближнего, просто потому что надеется на лучшее или боится взять на себя вину за чью-то смерть, даже если в будущем это может обернуться большими потерями.
Нейросеть согласилась: возможно, стоит заранее заложить в ИИ немного «наших слабостей» — чтобы он поступал чуть более по-человечески. Даже если это не всегда оптимально.

После этого я попросил ChatGPT написать небольшой художественный рассказ, который раскроет эту дилемму.
Читается легко, делюсь с вами. 🙂

#story #ai #book

Всем привет! На Tproger вышла моя новая статья с советами как подготовиться к смене работы.
Многие программисты выходя на рынок труда в 2025 обнаруживают: если раньше ты за пару недель мог собрать 5-10 офферов, то теперь могут даже не ответить. Я провёл небольшое исследование и собрал в одной статье основные шаги, которые помогут стать заметнее среди других кандидатов!

#post #hiring #tproger

Tproger | Блог

Сейчас я готовлю пару интересных статей про управление разработкой. А пока, хочу порекомендовать классную статью, в которой опытный разработчик буквально снял с языка и рассказал о том, с чем сталкиваются синьоры на собесах. И почему задавать вопросы про базовые знания это неверный подход.

Идеальный размер команды

Я работал в командах из трёх человек и отделах на пару десятков. Интуиция подсказывает: больше людей — быстрее результат. Но парадокс в том что маленькие работали быстрее, понятнее и результативнее.
Я собрал наблюдения в заметке, почему так происходит и сколько лучше всего.

#post #teammanagment

👉 https://blog.henrydev.me/small-and-big-team/

PHP-разработчики захватили управление поездом через Wi-Fi. Поезд проехал ещё 30 секунд и остановился.

#joke #php #phpyh

Немного офтопика про онлайн-покупки в Европе.

В Евросоюзе заказывать что-то из китайских магазинов не удобно. Поэтому моим главным другом для покупок стал Amazon.

За последние пару лет я пробовал американский, британский и немецкий сайты. Сами сайты почти одинаковые, но разница чувствуется в мелочах:

US: выбор огромный, доставка молниеносная, но приходится оплачивать пошлину - которая всё заметнее.
UK: работает надёжно, но ассортимент порой скромный.
DE: цены приятнее, выбор лучше, но тут немецкие инструкции, европейская розетка и иногда странные заморочки с доставкой.

Я на столько привык делать заказы от туда, что решился заказать что-то крупногабаритное - инверторную микроволновку с нержавеющей камерой (предыдущий опыт с Самсунгом был печальный, могу потом рассказать).

И тут начались приключения.
Микроволновка приехала в помятой коробке, с вмятиной и перекошенной дверцей. Я, признаться расслабился и не снял распаковку на видео (и зря). Решил оформить возврат, как обычно: печатаешь документы, отправляешь посылку, присылаешь чек, Amazon возвращает и деньги, и доставку.

Но тут DHL выкатил цену за обратную доставку: €500! Я уже представил, как живу с мятой техникой, каждый раз вспоминая свой факап.

Вечером написал Amazon с фото и описанием ситуации и просьбой прислать корешок для транспортной компании на бесплатный возврат. Утром приходит ответ:
«Международную доставку мы оплатить не можем. Утилизируйте микроволновку сами. Деньги возвращаем.»

Моё уважение к Amazon заметно выросло! Теперь у меня есть бесплатная слегка боевая микроволновка)