fbpx

Нельзя так просто взять и написать код. А почему? Да потому что рынок так быстро меняется, что подход “просто пиши код” уже не справляется, все что делаем сегодня, должно было быть сделано еще вчера и совершенно не так. Поэтому менеджеры и сами разработчики постоянно находятся в поисках эффективных подходов к разработке. Сегодня поговорим о некоторых из них. Это может здорово пригодиться вам на собеседовании.

Присоединяйся к HRPR в сетях

Допустим такую грубую классификацию в подходах к разработке:
– классические (пришел менеджер раздал всем задач, каждый отвечает за свою задачу, пилим, допиливаем, идем за новой);
– гибкие (пилим командой, обсуждаем, эффективность команды зависит от эффективности каждого игрока).
Гибкие методологии можно разделить на бережливые (избавляемся от “мусора” – все, что не добавляет ценности продукту) и экстремальные (плотно взаимодействуем с клиентом на каждом этапе).
Все подходы, заявленные в названии статье, относятся к условным гибким методологиям. То есть, они еще не являются подробно разработанными и описанными методиками, скорее, это профессиональные приемы разработчиков для решения конкретных, насущных задач. Давайте рассмотрим каждый из этих подходов подробнее.

Парное программирование – это вариант или одна из форм экстремального программирования (XP). XP предполагает поднятие уже устоявшихся подходов к разработке на “экстремальный уровень”, например, поставка кода частыми релизами, планирование с помощью игры, стремление к простоте кода и совместное владение кодом.
Парная разработка – один из приемов экстремального программирования. Описать этот процесс можно так: два программиста работают за одним столом (он может быть и виртуальным), один пишет код, другой внимательно следит за этим процессом, проверяет его, через определенный промежуток времени они меняются ролями, может быть через полчаса-час. Таким образом, задача того, кто пишет код – решать прикладную задачу в деталях, задача, того, кто читает – думать об общей цели и интеграции кода.

Преимущества:

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

Недостатки:

  • подходит не для всех задач, например, рефакторинг проще делать все же одному. Ну и сложные задачи, требующие глубокого погружения в контекст – тоже не подходят для парного программирования;
  • не всегда психологически комфортен для разработчиков, бывает тяжело убедить хотя бы попробовать. А если согласились, то в процессе могут даже подраться. И это не шутка;
  • утомляет, невозможно в таком интенсивном режиме невозможно проработать 6 часов, часа 2, ну 3 максимум;
  • успех зависит от уровня сплоченности команды и дружелюбности атмосферы в команде.

Парное применение, если команда столкнулась с трудностями при решении задачи, здесь очень хорошо подходит поговорка “одна голова хорошо, а две – лучше”. Это вид мозгового штурма для программистов. Также парное программирование часто применяют на собеседованиях

FDD (Feature driven development) – также один из гибких подходов к разработке ПО, который настроен на решение конкретной, уже известной задачи бизнеса, поставки реального рабочего функционала в заранее оговоренные сроки. Давайте опишем его так: у нас есть топ-разработчик, который в деталях представляет, какие задачи нужно решить и какой функционал реализовать. Он четко понимает, какой скоуп задач ждет команду на каждом спринте. При работе по этому методу, создается подробная дорожная карта продуктов, также разрабатывается довольно много документов для регламентации ведения проекта. Чаще FDD используется в продуктовых компаниях.

5 основных процессов FDD:

  1. разработка общей модели
  2. создание списка функций на основе общей модели, разбиение на конкретные feature
  3. планирование (как будут решаться конкретные задачи, с помощью каких технологий)
  4. непосредственно дизайн и разработка функций
  5. реализация разработанных функций

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

Чтобы рассмотреть следующий подход TDD (test-driven development) давайте пару слов скажем, что такое тестирование. Это одна из техник контроля качества кода. Тестировщики или разработчики пишут специальные тесты, эти тест запрашивают выполнение определенной команды программой, команда выполняется (или не выполняется – тест не пройден) и если это выполнение соответствует желаемому результату, то тест считается пройденным.
TDD, test-driven development – еще один гибкий подход создания ПО, при котором сразу пишутся тесты под определенный функционал, а потом уже пишется код, который способен пройти этот тест. Постоянно проводится рефакторинг (улучшение, причесывание кода для простоты внесения последующих изменений).

Основные процессы по TDD:

  1.  написать теста для нового функционала.
  2.  удостовериться, что этот тест не проходит.
  3.  написать код, который способен пройти тест.
  4. запустить тест, убедиться, что тест пройдет. Если нет, поправить код, повторить, пока тест не будет пройден.
  5. рефакторинг.
  6. перезапустить тест и убедиться, что рефакторинг ничего не сломал.

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

На занятиях в школе HRPR мы расскажем про методологии ведения проектов.

Чтобы вы уточняли у кандидатов на собеседовании, по каким они работали и нужно ли им обучение.

01

ИЮНЯ 2021

Старт группы HRPR. 125 часов занятий и подготовка вашего резюме для скорейшего входа в профессию.

Последнее из блога

One on one hrpr schoolITHR & IT-Рекрутингвопросы на зачет
14 июня, 2021

One on one – плюсы и минусы технологии

В IT отрасли по-прежнему спрос на кадры превышает предложение, по обороту кадров это лидирующая отрасль. В год такой оборот может составлять 15% и даже выше. И хотя некоторые компании заявляют,…
hrpr school blogITHR & IT-Рекрутингвопросы на зачет
11 июня, 2021

Фреймворки Python

Python находится в шаге, чтобы стать самым популярным языком в мире. Это объясняется его легкостью и универсальностью. На нем пишут игры, веб-приложения, различные ПО для задач бизнеса и науки, в…
hrpr school blogITHR & IT-Рекрутингвопросы на зачет
9 июня, 2021

Фреймворки PHP

Фреймворк PHP — это готовая структура для веб-приложения, которую программист дорабатывает исходя из задач проекта. Фреймворки облегчают работу специалиста и делают разработку сайтов надежнее и дешевле. PHP — это самый…
hrpr school blogITHR & IT-Рекрутингвопросы на зачет
8 июня, 2021

.NET рекрутеру: продукты, решения, перспективы

.NET разработчики — довольно востребованные специалисты. Вилка зарплат мидлов по СНГ варьируется от 1300 и до 3000 долларов США, верхняя планка зарплат для уровня Senior достигает 6000-8000 тысяч. Связано это…