Разработчик

На данный момент Разработчик .NET.

Мои компетенции и опыт

Что я умею

За последние несколько лет я работал как "Старший разработчик", "Ведущий разработчик", "Руководитель команды разработки", "Системный аналитик", "Технический ведущий разработчик", "Архитектор программного обеспечения", "Архитектор микросервисов". Работа на этих должностях позволила развить способности, о которых далее и подробнее.

√ Писать правильный код C# (backend)

Правильный - это значит "читаемый", управляемый, масштабируемый код, который легко поддерживать и тестировать. Шаблоны проектирования Repository, Unit of Work, Factory, Builder, Facade, а также практики SOLID, DRY, YAGNI, KISS при правильных подходах Clean Architecture, Vertical Slice Architecture, Domain Driven Design позволили реализовывать быстро и качественно требования бизнеса.

√ Делать разметку (frontend)

Есть опыт реализации приложений SPA использования ReactJS, Angular, Aurelia, KnockoutJS и jQuery, в том числе с ипользованием Redux. А после появления возможности создатьвать UI на C# использовал Blazor, MAUI

√ Логировать действия программы (микросервисов)

Логирование подразделяется на несколько уровней пользователей их читающих, а также важно подразделять уровни Develop и Production. Сбор информации о работе программы (микросервисов) я обычно использовал ELK, хотя бывали и Seq, и Jaeger, и Loki.

√ Генерировать и собирать метрики

Для бизнеса очень важно понимать как работает "бизнес". Метрические данные (OpenTelemetry) о течении бизнес-процессов являются основой для этого понимания. Я умею собирать данные при помощи Prometheus и визуализировать их при помощи Grafana. Это основные инструменты, которые я использовал обычно, хотя были и другие, например, Zabbix.

√ Писать Unit-тесты

Написание самих тестов теперь простая задача, если говорить в контексте ИИ - это "хорошие" тесты. А "правильные" тесты - это когда точно знаешь, где и что сломалось. Я использовал обычно xUnit с подходом разработки TDD, BDD.

√ Тестировать API и UI

Для тестирования REST API я обычно использeю Swagger, Scalar, Postman, Rest Client или Insomnia. У каждого из них есть свои "плюсы" и "минусы" по управлению/просмотру/анализу JSON и XML.

√ Управлять командой разработки

Обычно в команде разработки были backend-разработчики в количестве от одного до пяти, frontend-разработчики в количестве от одно до четырех, тестировщики - один два человека. Обучение, менторство, парное программирование - хорошие инструменты. Плюс к этому умение создавать презентации и обучающие видео ролики - отличный способ достичь взаимопонимания. Методологий по управлению коммандами и процессами разработки много, например, Agile, Kanban, Scrum. И у каждой есть свои "плюсы" и "минусы". Я для себя нашел самую эффективную методологию - LEAN, ее и пропагандирую.

√ Проводить исследования R&D

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

√ Проектировать архитектуру приложения

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

√ Проектировать микросервисы

Так получилось, что я реализовал несколько проектов с микросервисной архитектурой. Реализации были на платформе нужен доступ к резюме Core с использованием RabbitMQ очереди с надстройкой MassTransit или Rebus. В основу брал Event-driven architecture, которая считается более гибкой, но при этом может быть более сложной при большом количестве событий в системе.

√ Интергрировать ИИ

Есть опыт создания MCP-серверов для интеграции с ИИ. MCP - это открытый протокол Model Context Protocol, разработанный компанией Anthropic. Он позволяет языковым моделям (LLM) безопасно подключаться к внешним базам данных, файлам и API без необходимости создавать отдельные интеграции для каждого сервиса. Довелось встараивать контекст (базы данных) микросервисов (сервисов/модулей) в чат для ИИ.

√ Пилить "монолит" на модули

Модули - не всегда микросервисы, хотя и такое я тоже делать умею. Модули внутри монолита - это первый шаг к формированию правильной архитектуры. Обмен модулей данными через очередь сообщение - реальный шаг к микросервисам.

√ Проводить нагрузочное тестирование

Использовал K6 библиотеку, которая может так нагрузить сервер, что будет сразу понятно, на сколько RPS он готов к обслуживанию.

√ Оценивать производительность

Для тестирования на производительность код (методы, функции, версии платформы NET, использование памяти, использования процессора, а также другие аспекты качественного кода) я использовал BenchmarkForNet библиотеку. Использовал, чтобы оценить, какая конструкция языка эффективнее работает, какую библиотеку использовать, какой способ реализации.

√ Создавать фреймворки

Фреймворки, как базовый код, как основа разработки позволяет дисциплинировать разработчиков и привести их код к некому стандарту, который проще поддерживать и обслуживать. Правильный фреймворк может существенно ускорить процесс реализации требований и прикладных задач. У меня есть опыт создания фреймворков на нужен доступ к резюме Core, WPF, WinForms, Silverlight

√ Создавать библиотеки (nuget-пакеты)

Сборки или nuget-пакеты отлично ложатся в основу модульной разработки, универсализации фреймворк может существенно ускорить процесс реализации требований и прикладных задач. У меня есть опыт создания фреймворков на нужен доступ к резюме Core, WPF, WinForms, Silverlight

√ Строить диаграммы

Есть опыт создания UML-диаграм разных типов: Class Diagram, Sequence Diagram, Entity Relationship Diagram, Flowchart, State diagram, Gantt diagram, Mindmaps, Event Modeling Diagram, Radar, GitGraph Diagrams, Requirement Diagram и другие

√ Составлять и вести документацию

Документация разного типа - требует разные навыки. От "рисования" диаграм разного типа до понимание спецификаций, регламентов и правил оформления документов: Use Cases, User Flow, ТЗ, ФТ, НФТ, ADR и другие. Использовал обычно Confluence, но были и другие системы типы Notion, Jira, OneNote.

√ Моделирование процессов

Есть небольшой опыт использования BPMN для моделирования бизнес-процессов (BPM) на базе ELMA, которая является (BPMS).

√ Проводить собеседования

У меня подготовлен набор вопросов, которые разбиты на категории, а также разложены по уровням сложности. Более того, я написал программу на WPF, которая может формировать отчет по результатам собеседования.

√ Создавать презентации

Создать и провести презентацию - нет проблем. Опыт ведения своего канал на YouTube и Boosty способствует совершенствованию в этом деле.

√ Создавать видео

Создание видео - это отличный способ сохранить информацию для дальнейшего использования. Обычно я создаю видео для документирования фремворков, библиотек, архитектур, обучения сотрудников, для объяснения бизнесу, защита стека и/или архитектуры, а также для других подобных перечисленным случаям, потому что видео воспринимается проще и быстрее, чем чтение различного рода регламентов, спецификаций и правил.

√ Работать с Docker

В процессе настройки инфраструктуры для работы микросервисов пришлось наладить запуск её через docker compose на компьютере разработчика, чтобы отладка и разработка микросервисов не требовала наличия внешних сервисов и архитектуры. В инфраструктурные сервисы попали PostgreSQL, Redis, Prometheus, Kibana, Elasticsearch, OpenTelemetry и другие.

√ Настроить CI/CD

Есть опыт настройки CI/CD для своего блога, который работает на ubuntu и nginx. А публикуется после успешной сборки на Github Actions. Также есть который опыт настройки, хотя наверное честнее сказать, правки настроек и управления ими на Gitlab.