exam05 5 - stankin/design-part-1 GitHub Wiki

Основные приёмы экстремального программирования. Парное программирование и ревизия кода (Code Review).

Реферат к лекции 5. Проектирование и разработка программных средств.

Выполнил Дмитренко Сергей Сергеевич, ИДБ-18-07

Проверил Маслова Яна, ИДБ-18-07

Основные приёмы экстремального программирования.

Экстремальное программирование (XP) – это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований.

XP — это agile-методология, но она опирается на свои ценности:

  • Простота - Упрощение кода и процесса работы.
  • Коммуникация - Не быть отшельником, а взаимодействовать с коллегами, чтобы быстрее искать решения проблем.
  • Обратная связь - Постоянно общаться с заказчиком и следить за изменениями требований.
  • Смелость - Не бояться рисковать и использовать новые непроверенные практики.
  • Уважение - Уважать себя, коллег, правила и цели проекта.

Как и у любой другой методологии, у XP есть свой набор практик, на которых строится вся работа. Практики могут быть объединены в четыре группы:

1. Короткий цикл обратной связи (Fine-scale feedback)

  • Разработка через тестирование (Test-driven development)
  • Игра в планирование (Planning game) — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими.
  • Заказчик всегда рядом (Whole team, Onsite customer)
  • Парное программирование (Pair programming) — предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего.

2. Непрерывный, а не пакетный процесс

  • Непрерывная интеграция (Continuous integration) — интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают.
  • Рефакторинг (Design improvement, Refactoring) — подразумевается, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан.
  • Частые небольшие релизы (Small releases) — версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени.

3. Понимание, разделяемое всеми

  • Простота (Simple design) — в процессе работы условия задачи могут неоднократно измениться, а значит, разрабатываемый продукт не следует проектировать заблаговременно целиком и полностью. Проектирование должно выполняться небольшими этапами. В каждый момент времени следует пытаться использовать наиболее простой дизайн, который подходит для решения текущей задачи.
  • Метафора системы (System metaphor) — разработчикам необходимо проводить анализ архитектуры программного обеспечения для того, чтобы понять, в каком месте системы необходимо добавить новую функциональность, и с чем будет взаимодействовать новый компонент.
  • Коллективное владение кодом (Collective code ownership) – означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы.
  • Стандарт кодирования (Coding standard or Coding conventions) — необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицированно, как один человек.

4. Социальная защищённость программиста (Programmer welfare)

  • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

none

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

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

Парное программирование

Парное программирование (pair programming) — методика, при которой весь разрабатываемый код пишется двумя программистами на одном компьютере. Сейчас метод активно используют во многих ИТ-компаниях, как в больших, например, в Facebook, Pivotal Software, Grockit, так и в растущих, в таких как Drizly.

В паре две роли, назовем их «Штурман» и «Водитель». В руках «Водителя» клавиатура, он пишет код и его мышление сфокусировано на том, как здесь и сейчас написать некоторый код лучшим способом. Мышление «Штурмана», – стратегическое. Он думает о том, является ли оптимальным код «Водителя» для решения в целом, размышляет об альтернативах и способах упростить систему.

Роли в парном программировании используют по-разному в зависимости от стиля. Чаще всего разработчики меняют их в зависимости от ситуации.

Отсюда выделяют следующие стили:

1. Классическое парное программирование

Самый «старый» стиль.

  • Партнеры совместно прорабатывают решение на бумаге, доске, в miro; формируют общую ментальную модель. Еще не код, но уже не воздух.
  • «Водитель» пишет код и проговаривает свои действия, «Штурман» поверяет решение на прочность и смотрит на картину в целом
  • Через некоторое время, обычно 30 минут, партнеры меняются ролями Водитель мыслит тактически – пишет код и проговаривает свои действия. «Штурман» мыслит стратегически – проверяет решения «Водителя» на прочность, смотрит на картину в целом (первичные исследования работы мозга во время парного программирования показали, что уровень концентрации у «Штурмана» значительно выше, чем у «Водителя», что само по себе – контринтуитивно).

2. «Экскурсовод»

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

3. «Непрошеный советчик» или «штурман на заднем сидении»

Когда штурман не только следит за стратегией, но постоянно вмешивается в код.

4. «Пинг-понг»

Эта техника соответствует разработке через тестирование (Test-Driven Development (TDD) и подходит, когда задачи определены четко и могут быть покрыты тестовыми случаями.

  • “Пинг”: Разработчик 1 пишет тест, который не проходит.
  • “Понг”: Разработчик 2 пишет реализацию, которая позволяет тесту пройти.
  • Разработчик 2 затем начинает новый «Пинг», то есть пишет следующий тест, который не проходит.
  • Каждый “Понг” может сопровождаться совместным рефакторингом кода, прежде чем они начнут новый “провальный” тест. Таким образом, вы следуете стратегии “Красный — зеленый — рефакторинг”: пишете тест, который не проходит (“красный”), делаете так, чтобы он прошел по минимально необходимым значениям (“зеленый”) и далее делаете рефакторинг.

none

Парное программирование своим подходом дает ряд преимуществ перед одиночным программированием:

  • Большинство ошибок в программе выявляются на фазе программирования, а не тестирования и тем более не на фазе релиза программы.
  • Из первого пункта следует, что количество конечных ошибок намного меньше, чем при одиночном программировании.
  • Код получается короче и красивее, при этом не теряется его функциональность.
  • При командном подходе все проблемы решаются быстрее.
  • Один и тот же элемент программы понимают несколько членов команды, соответственно, теряется зависимость от конкретного программиста.
  • Улучшается коммуникация между членами команды.
  • Уменьшено воздействие стресса на программистов из-за возникающих проблем.
  • Ускоряется разработка программы.
  • Есть возможность быстро обучить начинающего программиста.

Парное программирование — это одна из методик экстремального программирования, которая «выталкивает» одиночных разработчиков из зоны комфорта. Поэтому при внедрении парного программирования нужно быть готовым к «сопротивлению» некоторых членов команды. Со временем это «сопротивление» спадет, как только программисты осознают все преимущества такого подхода.

Парное программирование требует от программистов навыки типа soft skills, а в частности:

  • умение работать в команде,
  • находить общий язык с другими людьми,
  • умение бесконфликтного общения.

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

Ревизия кода (Code Review).

Code Review - Это проверка кода на ошибки, неточности и общий стиль программирования.

Когда вы пишете новую функцию, она не попадает сразу в проект. Вместо этого ваш код отправляется на код-ревью (code review).

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

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

Code Review служит для проверки и обнаружения:

  • Ошибок.
  • Стилистики — пишете ли вы так, как принято в компании.
  • Оформления кода — соблюдаете ли вы отступы и табуляцию, чтобы код было легче читать.
  • Комментариев — если в компании принято комментировать ключевые моменты в коде.
  • Адекватность реализации — вы предложили изящное решение или решили всё грубой силой? А что уместнее в этой ситуации?
  • Влияния на проект — если вы полностью переписали формат передачи данных на сервер, то это значит, что другим участникам нужно будет подстроиться под вас и переписать свою часть. Это дорого.
  • Уязвимостей в безопасности — может ли что-то пойти не так, если злоумышленник решит использовать этот код в своих целях.
  • Если проблемы есть, проверяющий отправляет код на доработку. Если всё хорошо, код переходит на следующую стадию — как правило, в тестирование.

Существуют эффективные стандарты проверки кода, которые подчеркивают некоторые жизненно важные моменты, которые следует учитывать при проведении code review:

1. Код улучшает общее состояние системы

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

2. Быстрая проверка кода, ответы и отзывы

Прежде всего, не откладывайте добавление (слияние) лучшего кода. Не ожидайте, что код будет идеальным. Если он находится в состоянии, улучшающем общее состояние системы, примите его.

3. Обучайте и вдохновляйте во время проверки кода

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

4. При проверке кода соблюдайте стандарты

Всегда помните, что руководство по стилю, стандарты кодирования и подобные документы являются абсолютным авторитетом при проверке кода

5. Разрешение конфликтов при code review

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

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

Как рецензент кода, вы можете по крайней мере предложить, чтобы изменения (pull request) оставались совместимым с остальной частью кодовой базы в отсутствие руководства по стилю или стандартов кодирования.

6. Демонстрация UI изменений в рамках проверки кода

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

7. Убедитесь, что проверка кода сопровождается всеми тестами

Если это не чрезвычайная ситуация, запрос на изменения должен сопровождаться всеми необходимыми тестами, то есть модульными, интеграционными, end-to-end и т.д.

8. Когда вы сосредоточены, не отвлекайтесь на проверку кода

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

9. Просматривайте все и не делайте никаких предположений

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

10. Просматривайте код, помня о более широкой картине

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

11. Признавайте и поощряйте хорошую работу во время проверки кода

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

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

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

13. Объясните свои комментарии в code review и помните об объеме

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

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

Ссылки на источники:

❌ Нужно было сделать нормальные гиперссылки, а лучше расставить их в тексте. В целом реферат не лаконичен.

1. Экстремальное программирование.

2. Парное программирование.

3. Code Review.