1. Общие положения

1.1. Назначение и область применения документа

Настоящий документ «Руководство по стилю кода и техническим стандартам» (далее – Руководство) устанавливает единые требования к разработке, оформлению, документированию и ревью кода для всех сотрудников, выполняющих функции по разработке программного обеспечения (Fullstack, Backend, Java, Go, .Net, 1С) в компании «Генеральная» (далее – Компания). Руководство является обязательным к применению при создании новых продуктов, поддержке существующих систем, а также при проведении всех видов контроля качества кода. Цель документа — обеспечить высокое качество, читаемость, предсказуемость и безопасность разрабатываемого кода, сократить время ввода новых разработчиков в проекты и минимизировать количество ошибок на этапах тестирования и эксплуатации.

1.2. Нормативные и методические основания

Руководство разработано на основе стандартов Oracle/Google Java Style Guide, Effective Go, Microsoft .NET Coding Conventions, а также внутренних стандартов Компании в области управления качеством и информационной безопасности. Документ базируется на принципах «Чистый код» (Clean Code), SOLID, ключевых постулатах «Патерны проектирования» (Design Patterns) и требованиях к документированию API. В случае противоречия между данным Руководством и отраслевыми стандартами, применяются положения Руководства как более детализированные для специфики Компании. Интерпретация и актуализация Руководства возлагается на Технический комитет (Архитектурный совет).

2. Цель и задачи должности (Разработчик ПО)

2.1. Миссия роли

Разработчик ПО в Компании обеспечивает бесперебойную и эффективную работу информационных систем через создание качественного, расширяемого и поддерживаемого программного кода на стеке технологий (Java, Go, .Net, 1С). Миссия заключается не только в поставке функциональности в срок, но и в обеспечении долгосрочной стабильности архитектуры, минимизации технического долга и повышении инженерной культуры в команде. Разработчик выступает одновременно исполнителем, консультантом и экспертом по техническим решениям.

3. Подчиненность и взаимодействие

3.1. Административное подчинение

Разработчик ПО находится в прямом административном подчинении у Руководителя отдела разработки (Team Lead) либо Руководителя проектного офиса (PM). Вопросы дисциплины, отпусков, больничных листов и выполнения внутреннего трудового распорядка решаются с непосредственным руководителем.

3.2. Функциональное взаимодействие

В рамках функциональной деятельности разработчик взаимодействует с Архитектором (при решении принципиальных технических вопросов), Аналитиками (для уточнения требований и бизнес-логики), Инженерами по тестированию (QA) в рамках процесса исправления дефектов, а также с Администраторами баз данных и DevOps-инженерами по вопросам развертывания и настройки окружений. В матричной структуре проектов разработчик подчиняется Техническому лидеру проекта (Tech Lead) по вопросам реализации конкретных спринтов.

4. Должностные обязанности

4.1. Разработка и реализация программного кода

Разработчик обязан выполнять работы по созданию, модификации и рефакторингу программных компонентов на закрепленных языках программирования. При этом строго соблюдаются принципы SOLID и рекомендуемые паттерны проектирования (фабрика, стратегия, наблюдатель, внедрение зависимостей и др.) для обеспечения гибкости и переиспользуемости. Код должен быть написан в едином стиле: отступы — 4 пробела (табуляция запрещена), максимальная длина строки — 120 символов, фигурные скобки размещаются на той же строке (K&R стиль для Java/C#, для Go — стандартный gofmt). Все публичные методы, классы и сложные алгоритмы снабжаются комментариями формата Javadoc/XML Doc. Разработчик обязан проверять свой код статическими анализаторами (SonarQube, Checkstyle, SpotBugs) до отправки на ревью.

4.2. Работа с системой контроля версий и управление конфигурацией

Все изменения в коде производятся исключительно через систему контроля версий (Git) с использованием модели ветвления Git Flow. Commit Message должны быть осмысленными и начинаться с типа изменения (feat, fix, docs, style, refactor, test, chore). Разработчик обязан поддерживать актуальность своей ветки относительно целевой (master/main) и разрешать конфликты слияния. Слияние в основные ветки производится только через Pull Request с обязательным прохождением пайплайна CI/CD (сборка, тесты, статический анализ).

4.3. Проведение код-ревью (в роли рецензента)

Разработчик принимает участие в проверке кода своих коллег в объеме не менее 4 часов в неделю. В ходе ревью необходимо руководствоваться чек-листом код-ревью, который включает проверку: архитектурной целостности, читаемости, наличия тестов, обработки ошибок, безопасности (SQL-инъекции, XSS), производительности (алгоритмическая сложность, использование кэшей), а также соблюдение корпоративных стандартов кодирования. Комментарии должны быть аргументированными, конструктивными и направленными на улучшение кода. Ревью считается завершенным только после утверждения (approve) всех изменений.

4.4. Документирование и описание API

Разработчик обязан сопровождать разработанный функционал технической документацией. Для бэкенд-сервисов (Java, Go, .Net) документация ведется в формате OpenAPI (Swagger) для REST-эндпоинтов, либо gRPC-документация (proto-файлы). Для внутренних модулей и библиотек — README-файлы с описанием назначения, зависимостей, способов сборки и примеров вызова (code snippets). Документация должна обновляться синхронно с изменениями в коде при каждом релизе.

4.5. Оптимизация производительности и рефакторинг

Разработчик систематически анализирует существующий код на предмет узких мест и «запахов» кода. Предлагает и внедряет рефакторинг для улучшения структуры (устранение дублирования, упрощение сложных методов, разделение ответственности). При работе с базами данных — оптимизирует запросы, использует индексы и пулы соединений. При работе с памятью в Go/Java/C# — следит за утечками, корректным освобождением ресурсов (Close, Dispose, defer). По итогам рефакторинга обязательно обновляется документация и запускается полный цикл регрессионного тестирования.

4.6. Обеспечение качества и тестирование

Разработчик несет первичную ответственность за качество кода. Обязательно покрытие юнит-тестами (JUnit, NUnit, Go test) всех критических и бизнес-логических функций с целевым уровнем покрытия не менее 80%. Пишутся интеграционные тесты для проверки взаимодействия модулей и внешних систем. В процессе отладки и локальной проверки разработчик использует отладчики (IDE) и инструменты профилирования (JProfiler, dotMemory, pprof). Выявленные баги фиксируются в трекере задач (Jira/YouTrack) с приоритезацией, после исправления — дефекты перепроверяются через CI и демонстрируются QA.

5. Права разработчика

5.1. Право принятия технических решений

Разработчик имеет право предлагать и обосновывать изменение технических решений (выбор библиотек, фреймворков, архитектурных паттернов) в рамках своего уровня компетенции. Окончательное решение утверждается Техническим лидом (Tech Lead) после обсуждения на архитектурных комитетах.

5.2. Доступ к информации и ресурсам

Разработчику предоставляется доступ к корпоративным репозиториям, документации, базам знаний, инструментам CI/CD (Jenkins/GitLab CI), тестовым и продуктивным средам в объеме, необходимом для выполнения должностных обязанностей. Уровень доступа определяется матрицей прав и политиками безопасности Компании.

5.3. Запрос на повышение квалификации

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

5.4. Приостановка слияния изменений

При обнаружении критических нарушений стандартов кодирования, падения тестов или угроз безопасности, разработчик-ревьювер имеет право наложить вето (veto) на слияние Pull Request'а до полного устранения замечаний. О подобных случаях уведомляется Tech Lead.

6. Ответственность

6.1. За качество кода и нарушение стандартов

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

6.2. За сохранность информации и безопасность

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

6.3. За соблюдение сроков и выполнение обязательств

Разработчик несет ответственность за своевременную сдачу задач в рамках спринта. В случае возникновения рисков срыва сроков (форс-мажор, некорректная оценка) обязан своевременно уведомлять руководителя проекта и предлагать пути сокращения времени без потери качества (декомпозиция, исключение необязательных фич на данный релиз).

7. Квалификационные требования

7.3. Сертификация и дополнительные требования

Приветствуется наличие сертификаций: Oracle Certified Professional (OCP), Microsoft Certified: Azure Developer Associate, Golang Certified Developer. Обязательно владение английским языком на уровне чтения технической документации (Intermediate). Для работы с 1С — знание встроенного языка, объектов метаданных, умение оптимизировать запросы и отладку форм.

8. Условия труда

8.1. Режим рабочего времени

Работа осуществляется в соответствии с правилами внутреннего трудового распорядка Компании, в гибридном формате (удаленная работа / офис). Рабочая неделя — пятидневная, с двумя выходными. Допускается гибкий график в интервалах времени, определенных техническим заданием проекта (встречи, daily scrum).

8.2. Техническое обеспечение

Разработчику предоставляется рабочая станция (ноутбук или ПК) с необходимым программным обеспечением (IDE, Docker, системные утилиты). Дополнительно — доступ к корпоративным VPN-сетям, внутренним вики-страницам и чатам (Slack/Teams).

8.3. Охрана труда и санитарные нормы

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

9. Ключевые показатели эффективности (KPI)

9.1. Качество кода и плотность дефектов

Целевой уровень покрытия тестами — от 80%. Количество критических замечаний в ходе код-ревью на 100 строк кода — не более 1. Индекс технического долга (по данным SonarQube) — не выше 5% от объема изменений. Плотность дефектов в Production — менее 0.5 ошибок на 1000 строк кода в месяц.

9.2. Производительность и скорость поставки

Средний срок выполнения задачи (Lead Time) — в пределах плана спринта. Процент завершенных Story Points спринта — не менее 95%. Скорость отклика на инциденты (MTTR) — по SLA проекта. Доля переделок из-за неверного понимания требований — менее 10%.

9.3. Вклад в командную культуру и знания

Активность в проведении ревью (количество проверенных MR в месяц — не менее 10). Участие в технических митапах (выступление с докладом минимум 1 раз в полугодие). Наличие / поддержание актуальной документации по своим модулям.

10. Бизнес-процессы, чек-листы и сценарии рабочего процесса

10.3. Сценарий рефакторинга и модернизации модуля

Инициация рефакторинга происходит по результатам анализа технического долга или по запросу Архитектурного совета. Процесс включает: аудит текущего кода (утилиты-анализаторы), написание недостающих тестов (Test Harness) до рефакторинга для сохранения поведения (Golden Master), пошаговое изменение кода с применением паттернов (например, выделение интерфейсов для замены зависимостей, внедрение фабрик), регрессионный прогон автотестов, повторное ревью и финальную выкатку в стейджинг.

10.4. Работа с «легаси» кодом (устаревшие системы)

При работе с устаревшими системами, написанными без соблюдения современных стандартов, разработчик должен руководствоваться правилом «Не навреди» (Boy Scout Rule): «Оставляй код чище, чем он был до тебя». Изменения вносятся только с обязательным покрытием тестами изменяемого участка. При внесении критических изменений (миграция версий фреймворка) обязательно составляется план отката (Rollback Plan) и создается резервная копия кода/БД.

10.5. Порядок действий при обнаружении критической уязвимости

Если в процессе разработки или ревью обнаружена уязвимость, разработчик обязан немедленно уведомить об этом Tech Lead'а и группу Security Response, создать задачу с критическим приоритетом (Critical). До устранения уязвимости запрещается выполнять релизы и сливать код в основные ветки. Исправление должно быть протестировано на уязвимость (например, SAST-сканером) и выпущено внеочередным патчем.