Что такое двойное расходование в программировании

Парное программирование: какие преимущества оно даёт компании и разработчикам

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

Почему стоит использовать парное программирование?

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

Вот основные преимущества методики:

Повышается скорость работы. Разработчики гораздо меньше отвлекаются на побочные задачи, общение с коллегами (кроме напарника) и разного рода кофе-брейки и перекуры. Прокрастинации при таком способе нет.
Увеличивается скорость отладки. Два человека могут гораздо быстрее найти проблему в коде, чем один. У одного глаз может быть «замылен», а второй быстро обнаружит баг.
Растёт качество кода. Если программист, который кодит, допускает ошибки или качество кода падает, то второй это замечает и помогает исправить ситуацию.
Передача опыта и обучение. Парное программирование позволяет оперативно обмениваться знаниями и опытом, лучше использовать инструментарий и др.

Согласно данным ряда исследований, с одним из которых можно ознакомиться вот по этой ссылке, парное программирование позволяет снизить количество багов примерно на 10-20% плюс сократить объём самого кода. Кроме того, опрошенные в ходе исследования разработчики заявили, что они более уверены в результате, чем в случае одиночной работы. Такой ответ дали 95% опрошенных программистов.

Как всё это реализуется на практике

Команда проекта не начинает работу просто так — сел и поехал. Сначала задача обсуждается, намечается план (лучше на бумаге или в электронном виде), а потом уже все приступают к работе. Что касается пары разработчиков, то они каждые полчаса или час меняются ролями. Один пишет код, его роль принято называть «штурманом», второй этот код чекает, мониторит и составляет стратегию работы, его роль — «ведущий».

Рабочий процесс выглядит следующим образом:

у разработчиков должна быть чёткая задача
её нужно разбить на небольшие цели, которые фиксируются
пара должна меняться ролями, смена активности всегда помогает в работе
каждый должен заниматься задачей в рамках своей роли: если разработчик пишет код, то «стратегически» должен мыслить «штурман», а «ведущий» — работать с тактикой и деталями

Такой способ эффективен и в случае работы двух специалистов с примерно равным опытом, и в случае пары «новичок — опытный сотрудник». Речь идёт об опыте работы в самой компании, понятно, что пара «джун — мидл» хорошие результаты вряд ли покажет. Второй случай хорош для обучения и онбординга. Но именно знания и опыт работы с определённым стеком должны быть примерно равными.

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

Кстати, пара «джун — джун» тоже возможна. И она даже необходима, если задача не самая сложная. Дело в том, что в процессе работы оба программиста неплохо прокачают навыки и знания. Речь здесь как о хард-, так и софт-скилах.

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

Очень важно позаботиться и о состоянии рабочего места. В частности, жизненно необходимо:

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

Что делать, если в компании не практикуется парное программирование?

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

программирование
управление
управление разработкой
управление проектом

ЧТО ТАКОЕ DOUBLE SPENDING

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

Определение двойного расходования

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

Итак, double spending — это ситуация, при которой одни и те же активы тратятся два или более раз. Ей подвержены в основном криптовалюты, так как цифровые токены легко скопировать (это же просто информация), а при использовании физических денег стороны могут сразу же проверить подлинность платежных средств и подтвердить сделку.

Методы предотвращения двойного расходования

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

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

Поделитесь этим с друзьями!

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

Будьте первым, кто оставит комментарий

Пожалуйста, авторизируйтесь для возможности комментировать

30+ вопросов на собеседовании с разработчиками Blockchain

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

84% компаний пытаются внедрить технологию блокчейн в свою деятельность. Таким образом, вы можете себе представить растущий спрос на блокчейн разработчиков.
Фактически, согласно отчету за 2019 год, глобальный спрос на разработчиков блокчейнов вырос на 517% больше, чем в 2018 году. Аналитики прогнозируют, что рынок блокчейнов вырастет с 1,2 млрд долларов США в 2018 году до 23,3 млрд долларов США к 2023 году .

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

№1. Что такое блокчейн?
Блокчейн — это неизменная децентрализованная технология цифрового реестра, которую можно запрограммировать для хранения транзакционных записей с акцентом на прозрачность и безопасность. Записи транзакций называются «блоками», которые связаны или «связаны» вместе с использованием криптографии.

№2. В чем разница между блокчейн Bitcoin и блокчейн Ethereum?
Биткойн в основном представляет собой децентрализованную цифровую валюту, которую вы можете использовать в качестве средства обмена для финансовых транзакций. Это похоже на цифровой доллар.

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

№3. Какие бывают типы блокчейна?
Вообще говоря, существует четыре различных типа блокчейна.

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

№4. На каком принципе основана технология блокчейн?
По сути, главный принцип — децентрализация. Кроме того, он также направлен на обеспечение равных возможностей для всех в сети. Биткойну это удалось. Однако другие типы технологии блокчейн могут отличаться по своему подходу.

№5. Что такое технология распределенного реестра?
Распределенный реестр, или технология распределенного реестра, по сути, представляет собой базу данных, которая существует одновременно в нескольких местах. Более того, все данные распределяются, реплицируются и синхронизируются между этими местами. В нем нет централизованного хранилища данных или администратора.

№6. В чем разница между технологией распределенного реестра и блокчейном?
Блокчейн — это, по сути, разновидность технологии DLT или цифрового реестра. То есть все блокчейны являются DLT, но не все DLT являются блокчейнами.
Блокчейн в основном добавляет дополнительный набор функций к DLT. Более того, в блокчейне все данные распределяются между всеми участниками и защищены с помощью криптографической подписи, называемой хешем. Это делает информацию, хранящуюся в цепочке блоков, неизменной, что повышает безопасность и целостность.

№7. Как блокчейн может повысить доверие?
Блокчейн спроектирован таким образом, что никакая хранимая информация или записи не могут быть изменены или даже уничтожены. Кроме того, блокчейн способствует прозрачности и устраняет единый регулирующий орган. Это дает пользователям равный доступ к информации, не беспокоясь о нарушениях безопасности, поскольку все может быть изучено кем угодно.

Транзакционные записи.
Блокировать записи.

Децентрализованная система.
Распределенный реестр.
Безопасная и надежная экосистема.
Чеканка (miting).

№11. Что означает «блок» в блокчейне?
Блок — это часть транзакционной записи или данных, которые хранятся в базе данных цепочки блоков. Затем эти блоки связываются вместе, отсюда и название — блокчейн.

№12. Являются ли данные, записанные в блокчейне, неизменными?
Да, данные, записанные в блокчейне, практически неизменяемы. Как вы знаете, данные, хранящиеся в блокчейне, называются блоками. Каждый блок связан с хеш-значением. Теперь каждый блок содержит не только свое хеш-значение, но и хеш-значение предыдущего блока. Если в блок внесены какие-либо изменения, это изменит значение хеш-функции. Следовательно, если вы хотите вмешаться в данные в одном блоке, вам придется изменить всю цепочку блоков, что практически невозможно.

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

Proof of Stake : Proof of Stake — это альтернатива Proof of Work, где нет прямой конкуренции между майнерами и кто-то случайно выбирается для «проверки» блока. Вероятность стать валидатором увеличивается в зависимости от того, какая у вас доля в блокчейне, т.е. сколько токенов блокчейна у вас есть.

№14. Что такое идентификаторы блоков?
Блок в цепочке блоков можно идентифицировать с помощью хэша заголовка блока и высоты блока.

№15. Как деревья Меркла играют важную роль в блокчейне?
Дерево Меркла — это структура данных, похожая на двоичное дерево, и используется для хранения криптографических хэшей каждого блока в цепочке блоков. Здесь листовой узел представляет собой хэш блока транзакционных данных, тогда как не конечный узел представляет собой хеш содержащего его листового узла.

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

Централизованные сети.
Децентрализованные сети.
Распределенные сети.

№18. Зачем блокчейну для работы токены?
Вы можете использовать монеты или токены в блокчейне для реализации изменений между состояниями. В любом случае, каждая транзакция в блокчейне относится к изменению состояния, которое вы можете представить перемещением монеты с одного адреса на другой.
Помимо этого, монеты и токены также облегчают транзакции в цепочке блоков. Каждая транзакция означает изменение состояния, которое представлено изменением данных. Теперь токены и монеты в настоящее время являются единственным способом изменить состояние блока в неизменяемой цепочке блоков.

№19. Как работает одноранговое обнаружение в сети P2P?
Когда новый узел загружается, он не имеет информации о сети, потому что в блокчейне отсутствует центральный сервер. Таким образом, разработчик должен предоставить список доверенных узлов, непосредственно записанный в код узла, который он затем может использовать для первоначального обнаружения однорангового узла.

№20. Что такое scriptPubKey?
ScriptPubKey — это сценарий блокировки, который размещается на выходе транзакции. Он содержит определенные условия, которые необходимо выполнить для выполнения транзакции.

№21. Что такое RSA?
RSA, сокращение от Rivest-Shamir-Adelman, представляет собой алгоритм для подписи данных и шифрования. Кроме того, вы можете использовать его для защиты данных, реализуя асимметричный криптографический алгоритм, который работает с двумя разными ключами, а именно с открытым ключом и закрытым ключом. Открытый ключ может быть передан кому угодно, а закрытый ключ должен храниться в секрете.

№22. Что такое SHA-256?
SHA-256 является частью SHA-2 (Secure Hash Algorithm Version 2), который является собирательным названием для различных версий хеш-функций, включая SHA-224, SHA-384 и SHA-512. Следовательно, это в основном однонаправленная криптографическая хеш-функция, которая преобразует текст любой длины в уникальную строку, содержащую 256 бит или 32 байта.

№23. Что такое майнинг?
Майнинг — это процесс, с помощью которого транзакция проверяется в сети блокчейн. Более того, процесс по существу выполняет две функции:
Во-первых, майнинг создает новые монеты в сгенерированном блоке.
Во-вторых, он предоставляет доказательство работы сети блокчейнов, которая подтверждает транзакцию в распределенном реестре.

№24. Что такое двойное расходование? Как это остановить?
Двойное расходование относится к состоянию, при котором один цифровой токен расходуется несколько раз. Поскольку токены в основном представляют собой цифровые активы, состоящие из цифровых файлов, вы можете легко их клонировать. Следовательно, это может привести к множеству проблем для системы, включая инфляцию.

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

Ethereum.
Hyperledger.
Qtum.
EOS.
ЙОТА.

№27. Что такое атака 51%?
Атака 51% на блокчейн происходит, когда группа или отдельный человек в конечном итоге контролируют более половины (или> 51%) хешрейта майнинга или вычислительной мощности. В этом случае они могут управлять системой, отклоняя и одобряя транзакции, и даже могут выполнять двойное расходование.

№28. Что такое секретный обмен?
Это один из основных способов обеспечения безопасности данных в блокчейне. Кроме того, вы можете использовать его для разделения личной информации (или любой секретной информации) на несколько единиц. После этого вы можете отправить их пользователю.
Вы можете получить исходную информацию только тогда, когда участник, у которого есть часть секрета, соглашается объединить ее с остальной частью группы. Это дает много преимуществ безопасности технологии блокчейн.

№29. Что такое исполнительная бухгалтерия?
Исполнительный бухгалтерский учет — это особый вид бухгалтерского учета, специально разработанный для предприятий, которые предлагают услуги своим клиентам или клиентской базе. Кроме того, он не имеет верхнего предела для услуг, что позволяет предприятиям создавать и управлять любым количеством необходимых услуг.

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

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

RSA.
Тройной DES.
Blowfish.
Twofish.
AES.

№33. Что такое BIP?
BIP — это сокращение от протокола улучшения биткойнов.

№34. Что такое алгоритм консенсуса? Какие бывают типы консенсусных алгоритмов?
Алгоритм консенсуса — это в основном метод обеспечения того, чтобы все одноранговые узлы сети блокчейн находились на одной странице относительно текущего состояния распределенного реестра. Более того, алгоритм помогает установить надежность и доверие между двумя неизвестными одноранговыми узлами в распределенной вычислительной среде.

Вот несколько примеров популярных алгоритмов консенсуса:
Доказательство работы (PoW)
Подтверждение емкости (PoC)
Доказательство активности (PoA)
Делегированное доказательство ставки (DPoS)
Доказательство ставки (PoS)
Подтверждение полномочий
Доказательство прожига
Подтверждение веса
Доказательство истекшего времени

Экстремальное
программирование
(XP) не для слабонервных

Экстремальное программирование или XP, eXtreme Programming — гибкая методология разработки программного обеспечения. Как и у других agile-методологий, у нее есть особенные инструменты, процессы и роли. Хотя автор XP не придумал ничего нового, а взял лучшие практики гибкой разработки и усилил до максимума. Поэтому программирование и зовется экстремальным.

Автор методики — американский разработчик Кент Бек. В конце 90-х годов он руководил проектом Chrysler Comprehensive Compensation System и там впервые применил практики экстремального программирования. Свой опыт и созданную концепцию он описал в книге Extreme Programming Explained, опубликованной в 1999 году. За ней были выпущены другие книги, в которых подробно описывались практики XP. К становлению методологии причастны также Уорд Каннингем, Мартин Фаулер и другие.

XP отличается от других гибких методологий тем, что применимо только в области разработки программного обеспечения. Оно не может быть использовано в другом бизнесе или повседневной жизни, как scrum, kanban или lean.

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

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

13 практик экстремального программирования

1. Вся команда

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

2. Игра в планирование

Планирование в XP проводят в два этапа — планирование релиза и планирование итераций.

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

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

В XP если команда не успевает выполнить все задачи к дате релиза, то релиз не отодвигается, а режется часть функционала, наименее важная для заказчика.

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

3. Частые релизы версий

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

4. Пользовательские тесты

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

5. Коллективное владение кодом

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

6. Непрерывная интеграция кода

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

7. Стандарты кодирования

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

8. Метафора системы

Метафора системы — это ее сравнение с чем-то знакомым, чтобы сформировать у команды общее видение. Обычно метафору системы продумывает тот, кто разрабатывает архитектуру и представляет систему целиком.

9. Устойчивый темп

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

10. Разработка, основанная на тестировании

Одна из самых трудных практик методологии. В XP тесты пишутся самими программистами, причем ДО написания кода, который нужно протестировать. При таком подходе каждый кусок функционала будет покрыт тестами на 100%. Когда пара программистов заливают код в репозиторий, сразу запускаются модульные тесты. И ВСЕ они должны сработать. Тогда разработчики будут уверены, что движутся в правильном направлении.

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

Представьте двух разработчиков за одним компьютером, работающих над одним куском функциональности продукта. Это и есть парное программирование, самая спорная практика XP. Старая поговорка «одна голова хорошо, а две лучше» отлично иллюстрирует суть подхода. Из двух вариантов решения проблемы выбирается лучший, код оптимизируется сразу же, ошибки отлавливаются еще до их совершения. В итоге имеем чистый код, в котором хорошо разбираются сразу двое разработчиков.

12. Простой дизайн

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

13. Рефакторинг

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

Преимущества и недостатки XP

Методология XP вызывает много споров и критики со стороны тех, кто так и не смог ее внедрить в своей команде.

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

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

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

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

Принципы XP

В первой книге Кент Бек сформулировал такие принципы экстремального программирования: простота, коммуникация, обратная связь и смелость. В новом издании книги он добавил пятый принцип — уважение.

1. Простота

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

2. Коммуникация

В XP коммуникация между разработчиками ведется не посредством документации, а вживую. Команда активно общается между собой и с заказчиком.

3. Обратная связь

Обратная связь в XP реализуется сразу в трех направлениях:

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

4. Смелость

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

5. Уважение

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

Алгоритм внедрения методологии XP и процесс работы

Бек Кент рекомендует внедрять XP для решения проблем в проекте. Команда выбирает самую насущную проблему и решает ее с помощью одной из практик экстремального программирования. Затем переходит к следующей проблеме, используя еще одну практику. При таком подходе проблемы выступают мотивацией к применению XP и команда постепенно осваивает все инструменты методологии.

Чтобы внедрить XP в существующий проект, нужно постепенно осваивать его методики в области:

тестирования
проектирования
планирования
менеджмента
разработки

Тестирование.

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

Проектирование.

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

Планирование.

Команда должна перейти на тесное взаимодействие с заказчиком. На этом этапе важно донести до него преимущества работы в одной команде с разработчиками и интегрировать его в команду.

Менеджмент.

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

Разработка.

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

В проекте, который работает по методологии XP процесс построен таким образом:

По методологии XP процесс построен так

Кто использует XP

По данным исследования Versionone за 2016 год всего 1% agile компаний используют экстремальное программирование в чистом виде. Еще 10% работают по гибридной методологии scrum и XP.

Соотношение agile методологий и практик в компаниях

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

Самые популярные практики разработки в agile компаниях в 2016 г

Самые популярные практики разработки в agile компаниях в 2016 г.

Не так просто найти информацию о командах, которые применяют XP, но есть и те, кто афиширует, что именно эта методология — причина их успеха. Пример экстремального программирования — компания Pivotal Software, Inc.

Pivotal Software, Inc.

Американская софтверная компания, которая разрабатывает ПО для бизнес-анализа на основе big data и оказывает консультационные услуги. Продуктами Pivotal пользуются корпорации Ford, Mercedes, BMW, GAP, Humana, крупные банки, государственные учреждения, страховые компании и т.д.

Pivotal — адвокат agile методологий, как единственно возможных в современной разработке. Из всех вариантов гибких методологий компания выбрала XP как win-win подход для заказчиков и команд программистов. Каждый рабочий день начинается с собрания на ходу, и заканчивается ровно в 18:00 — никаких переработок. Pivotal использует игру в планирование, парное программирование, постоянное тестирование, непрерывную интеграцию и другие практики XP. Для многих практик у них есть собственное ПО.

Парное программирование в openspace компании Pivotal Software, Inc.

Что почитать, чтобы разобраться в XP

Экстремальное программирование,
Экстремальное программирование: планирование,
Экстремальное программирование: разработка через тестирование / Кент Бек

Книги по экстремальному программированию от создателя методологии Кента Бека. Начните с первой, в ней с примерами описывается концепция XP и обосновываются ее преимущества. Позднее автор выпустил еще несколько книг, где подробно описал отдельные практики XP.

Рефакторинг: улучшение существующего кода / Мартин Фаулер

Мартин Фаулер — программист и соавтор методологии экстремального программирования. В книге описаны основные принципы и приемы рефакторинга, а также 70 практических методов рефакторинга с примерами.

Экстремальное программирование: постановка процесса. С первых шагов и до победного конца / Кен Ауэр, Рой Миллер

Книга описывает практики XP и учит внедрять их на практике, жизненно и с примерами.

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

Приложения для внедрения XP в команде

Команды, работающие над проектами по методологии XP, применяют таск менеджеры и сервисы для agile проектов. На рынке много таких продуктов, мы рассмотрим несколько примеров.

Redmine

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

Basecamp

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

Jira

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

Worksection

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

Вердикт

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

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

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

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

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

Никто не обязывает внедрять XP по принципу «все или ничего». В конце концов, гибкие методологии должны быть гибкими и в плане применения — подстраиваться под нужды конкретной команды и проекта.