-
Notifications
You must be signed in to change notification settings - Fork 17
exam05 5
Основные приёмы экстремального программирования. Парное программирование и ревизия кода (Code Review).
Реферат к лекции 5. Проектирование и разработка программных средств.
Проверил Маслова Яна, ИДБ-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)
Предназначение экстремальное программирование — снизить уровень неопределенности в проектах и по-настоящему гибко реагировать на изменения требований к продукту. Это одна из самых трудных для внедрения методологий, поскольку она включает целых двенадцать практик!
Немногие компании рискуют работать по чистому XP, но его практики разработки — самые популярные в agile проектах. И это весомый довод в пользу их эффективности.
Парное программирование (pair programming) — методика, при которой весь разрабатываемый код пишется двумя программистами на одном компьютере. Сейчас метод активно используют во многих ИТ-компаниях, как в больших, например, в Facebook, Pivotal Software, Grockit, так и в растущих, в таких как Drizly.
В паре две роли, назовем их «Штурман» и «Водитель». В руках «Водителя» клавиатура, он пишет код и его мышление сфокусировано на том, как здесь и сейчас написать некоторый код лучшим способом. Мышление «Штурмана», – стратегическое. Он думает о том, является ли оптимальным код «Водителя» для решения в целом, размышляет об альтернативах и способах упростить систему.
Роли в парном программировании используют по-разному в зависимости от стиля. Чаще всего разработчики меняют их в зависимости от ситуации.
Отсюда выделяют следующие стили:
1. Классическое парное программирование
Самый «старый» стиль.
- Партнеры совместно прорабатывают решение на бумаге, доске, в miro; формируют общую ментальную модель. Еще не код, но уже не воздух.
- «Водитель» пишет код и проговаривает свои действия, «Штурман» поверяет решение на прочность и смотрит на картину в целом
- Через некоторое время, обычно 30 минут, партнеры меняются ролями Водитель мыслит тактически – пишет код и проговаривает свои действия. «Штурман» мыслит стратегически – проверяет решения «Водителя» на прочность, смотрит на картину в целом (первичные исследования работы мозга во время парного программирования показали, что уровень концентрации у «Штурмана» значительно выше, чем у «Водителя», что само по себе – контринтуитивно).
2. «Экскурсовод»
Применяют, если нужно во время работы обучать напарника: более опытный «водитель» успевает и писать код, и рассказывать штурману, почему и как он это делает.
3. «Непрошеный советчик» или «штурман на заднем сидении»
Когда штурман не только следит за стратегией, но постоянно вмешивается в код.
4. «Пинг-понг»
Эта техника соответствует разработке через тестирование (Test-Driven Development (TDD) и подходит, когда задачи определены четко и могут быть покрыты тестовыми случаями.
- “Пинг”: Разработчик 1 пишет тест, который не проходит.
- “Понг”: Разработчик 2 пишет реализацию, которая позволяет тесту пройти.
- Разработчик 2 затем начинает новый «Пинг», то есть пишет следующий тест, который не проходит.
- Каждый “Понг” может сопровождаться совместным рефакторингом кода, прежде чем они начнут новый “провальный” тест. Таким образом, вы следуете стратегии “Красный — зеленый — рефакторинг”: пишете тест, который не проходит (“красный”), делаете так, чтобы он прошел по минимально необходимым значениям (“зеленый”) и далее делаете рефакторинг.
Парное программирование своим подходом дает ряд преимуществ перед одиночным программированием:
- Большинство ошибок в программе выявляются на фазе программирования, а не тестирования и тем более не на фазе релиза программы.
- Из первого пункта следует, что количество конечных ошибок намного меньше, чем при одиночном программировании.
- Код получается короче и красивее, при этом не теряется его функциональность.
- При командном подходе все проблемы решаются быстрее.
- Один и тот же элемент программы понимают несколько членов команды, соответственно, теряется зависимость от конкретного программиста.
- Улучшается коммуникация между членами команды.
- Уменьшено воздействие стресса на программистов из-за возникающих проблем.
- Ускоряется разработка программы.
- Есть возможность быстро обучить начинающего программиста.
Парное программирование — это одна из методик экстремального программирования, которая «выталкивает» одиночных разработчиков из зоны комфорта. Поэтому при внедрении парного программирования нужно быть готовым к «сопротивлению» некоторых членов команды. Со временем это «сопротивление» спадет, как только программисты осознают все преимущества такого подхода.
Парное программирование требует от программистов навыки типа soft skills, а в частности:
- умение работать в команде,
- находить общий язык с другими людьми,
- умение бесконфликтного общения.
Эти навыки важны, потому что при парном программировании очень часто будут возникать недопонимания между партнерами в каких-нибудь мелочах. Умение выходить из конфликтов поможет сохранить и улучшить взаимоотношения в парах разработчиков. При парном программировании главное — соблюдать равноправие и свободу мысли каждого отдельного программиста.
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. Экстремальное программирование.
- https://qaevolution.ru/metodologiya-menedzhment/xp/
- https://studfile.net/preview/9572084/page:3/
- https://worksection.com/blog/extreme-programming.html
- https://skillbox.ru/media/management/ekstremalnoe_programmirovanie_ili_upravlenie/
2. Парное программирование.
- http://agilemindset.ru/парное-программирование/
- https://trends.rbc.ru/trends/education/5f8ea4969a7947094887f9bf
- https://codernet.ru/articles/drugoe/parnoe_programmirovanie_kak_eto_rabotaet_i_naskolko_effektivno/
3. Code Review.