Когда я только пришел в мир IT, для меня, как и, наверняка, для вас, было много чего непонятного и неизученного. Это было мостиком моей мотивации, удерживающим меня в этой индустрии, но по мере того как ты завязываешь в узелок все свои накопленные знания, появляется уверенность в кое-какой стабильности, а следовательно — новый вопрос.

А что теперь?

Ну теперь вы, вроде, полноценный винтик среднего звена, так называемый middle developer, теперь хочется расти еще выше, в лиды --> архитекторы --> CTO.

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

Создайте систему

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

• Например, организуйте определенную инструкцию, как работать с Git, определенную систему ветвления по типу feature/bug/hotfix — название продукта в названии ветки; если таковых несколько, нужен отдельный стиль написания (camel case или snake). В Bitbucket, например, можно легко отфильтровать ветки, если в названии есть feature etc, таким образом можно быстро собрать статистику. Название ветки также намного важнее, чем описание коммита, так как всей команде совершенно очевидно, над какой задачей кто-то когда-то работал.

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

• Далее выработайте стиль написания фитчей: здесь уже все в большей мере касается архитектуры проекта и, конечно, в первую очередь его простоты: все должно быть интуитивно понятно; изолируйте свою сущность в папку вместе с контроллерами, сервисами, репозиториями и прочими вещами, к ней относящимися. А после определите поэтапно, как разработчик должен писать фичу, начиная от создания ветки до pull request. Эту инструкцию расшарьте разработчикам и следите за четким её выполнением.

Представьте: вы собрали базу из предыдущих пунктов и что-то даже написали с командой.

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

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

Работа над задачами

Четко организуйте работу с задачами, используйте такие инструменты, как Jira, Git Board, Notion и другие доски. Очень важно правильно организовать столбцы, правильно объяснить, когда, что и куда передвигается.

У вас столбцы могут иметь разные названия и смысл, но я для примера объясню на таких:

• Analysis

• To Do

• Development

• Block

• Development Done

• Testing

• Testing Done

• Production

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

Для того чтобы положить задачу в этот блок, надо объяснить обстоятельства, обозначить ответственного, если такой человек есть, отметить дату и время блока, что впоследствии может снять с разработчика ответственность и сохранить нервы вам, как ответственному за выполнения задач человеку.

Конечно, стоит обратить внимание на появление задач в бэклоге и их оценку, но это крайне обширная тема с индивидуальным подходом, поэтому я ограничусь парой советов:

• Формирование задач менеджерами и их детальное описание.

• Занесение задач в бэклог, когда они понятны любому программисту.

• После этого задачи распределяются разработчикам в блок Analysis, они должны быть назначенными.

• Все задачи, которые попали в блок Analysis, должны оценить разработчики, после чего — сместить их в блок To Do.

• Разработчик смотрит на критичность задачи по приоритету и перетаскивает самые горячие из них в блок Development. Если приоритеты у всех задач одни, разработчик разбирает задачи по своему усмотрению.

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

Задачи также могут быть связаны, поэтому разработчик может начать делать задачу 1, переключиться на задачу 2 и вернуться к задаче 1.

Programming, Analysis, Control

Программируй, Анализируй, Контролируй

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

Контроль качества

Ну а теперь дело за вашими техническими возможностями, софт-скилами ментора и умением работать в команде.

Когда задача завершена, разработчик должен открыть PR, а вы должны научить его работать в вашей системе. Я не говорю сейчас про оптимальность решения, но про стиль написания проекта, определенные правила кода, каким вы привыкли его видеть: простым, понятным, чистым.

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