Программирование — это когнитивная работа, и мы, как программисты, лучше всего работаем в условиях интенсивной концентрации. Хотя существуют внешние факторы, которые могут повлиять на это, например, наличие тихого офиса, контролируемых способов общения и т. Д., Существуют также некоторые внутренние факторы, которые необходимо учитывать. На самом деле, то, как мы работаем, может больше всего повлиять на качество результата.
Состояние, в котором мы сосредоточены на 100%, в то время как чистая магия выходит из наших клавиатур, часто называют Зона , или поток Анкет
Поток нелегко попасть. Один прерывания достаточно, чтобы взорвать его, и, как только потеряно, обычно трудно восстановить. Обычно мне требуется полчаса, чтобы вернуться в зону с тем же уровнем интенсивности.
Поток также является важным компонентом для выполнения значимой творческой работы. В Творчество: поток и психология открытия и изобретения , психолог Михали Csikszentmihalyi идентифицировал девять элементов, которые могут заставить кого -либо в состояние потока:
- Есть четкие цели на каждом этапе пути.
- Есть непосредственные отзывы о своих действиях.
- Существует баланс между проблемами и навыками.
- Действие и осознание объединены.
- Отвлеки исключены из сознания.
- Там нет беспокойства о неудаче.
- Самосознание исчезает.
- Чувство времени искажается.
- Деятельность становится автотелической.
Разработка, основанная на тестировании или поведении (TDD/BDD), непрерывная интеграция и непрерывная доставка (CI/CD) могут помочь программистам усилить некоторые из этих элементов. В этом посте я постараюсь объяснить, как.
Есть четкие цели на каждом этапе пути
Прежде чем я начал практиковать TDD и BDD, я часто чувствовал себя в недоумении, когда сталкивался с новой большой функцией для разработки. Дело не в том, что я не мог этого сделать, это просто то, как я работал, часто был бы неэффективным: я откладываю, пытаясь решить, с чего начать, и как только я достигнут середины, я часто блуждал между разными Части неполной системы. После того, как эта функция была отправлена, слишком часто я осознавал, что пережил инженерную вещь, а также пропустил, чтобы реализовать хотя бы одну важную часть этого.
В BDD вы всегда начинаете с написания пользовательского сценария высокого уровня функции, которая еще не существует. Обычно не сразу не очевидно, что это за функция, поэтому уделять время продумать это и обсудить это с вашей командой, менеджером по продукту или клиенту, прежде чем написать какой -либо код — это хорошо потраченное время. После того, как у вас есть изложенная функция перед вами (например, в DSL, такой как Gherkin), у вас будет четкая цель, к которой вы сможете работать. Ваша следующая единственная цель должна заключаться в реализации этого тестового сценария. Вы будете знать, что вам удалось достичь этой цели, как только тестовый сценарий начнет проходить.
По мере того, как мы погружаемся в более низкие уровни реализации — для веб -и мобильных приложений, это обычно представление, а затем контроллер, модель, возможно, более глубокий слой бизнес -логики — мы всегда должны определять нашу следующую цель, написав для него тестовый пример. Каждая цель получена из реализации, которую мы только что завершили, учитывая цель высокого уровня, представленную первоначальным сценарием. Мы можем заново запустить сценарий высокого уровня (иногда также называемый тест на прием) всякий раз, когда нам нужен намек на то, как продолжить.
Для более практического тура о том, как сделать это на практике, ознакомьтесь с моим предыдущим постом:
Как построить Rock Solid Ruby на приложениях Rails с BDD
Марко Анастасов ・ 6 сентября ’18 ・ 7 мин читать
Есть немедленная обратная связь с вашим действием
Быстрые петли обратной связи необходимы во всем, что мы делаем, если хотим быть хорошими в этом. Обратная связь говорит нам, как у нас дела, а также где мы относимся к нашей цели. При отладке проблемы, которая включает в себя сетевые обработки и несколько файлов, и охватывает потенциально обширную область кода, ваша основная цель должна заключаться в сокращении цикла воспроизведения его максимально возможным. Это поможет вам потратить как можно меньше времени на печатание и/или нажимая между попытками воспроизвести проблему, чтобы увидеть, решили ли вы ее.
BDD и непрерывная интеграция — все о обратной связи. При программировании тесты, которые вы пишете, предоставляют вам отзывы о вашей текущей работе. Вы пишете тест, немного программируйте, запускаете тест и наблюдаете за результатом, возвращаетесь к рефактору, если он зеленый, или еще немного работайте над тем, чтобы его пройти на случай, если он красный.
Быстрое изготовление этого процесса имеет решающее значение, так как вы можете потерять фокус, если вам нужно ждать одного результата теста дольше, чем несколько секунд. Также полезно практиковаться в переключении между тестами и кодом, а также практически подсознательно запустить связанную часть тестов (ы). Например, в Семфор Мы все программируем в VIM и используем небольшой плагин запустить тестовый или тестовый файл под курсором с удобным ярлыком.
Одним из самых больших преимуществ непрерывного развертывания (CD) является то, что он обеспечивает быструю обратную связь для всей компании. Выпуск ежедневно гарантирует, что разработчики могут точно настроить реализацию, менеджеры по продуктам могут проверять решения и получать отзывы от пользователей, а бизнес в целом может быстро вводить новшества, учиться и корректировать курсы.
Для обсуждения того, что достаточно быстро CI, посмотрите:
Что такое правильная непрерывная интеграция?
Марко Анастасов ・ 4 октября ’18 ・ 3 мин читать
Существует баланс между проблемами и навыками
Если между поставленной задачей и нашими навыками существует фундаментальное несоответствие, ни один процесс не может помочь с этой проблемой. Тем не менее, TDD играет важную роль в качестве помощи в общем процессе разбивания большой задачи на многие мелкие, управляемые. Это помогает нам работать с небольшими приращениями. Предполагая, что мы работаем в знакомой области, может быть один сценарий высокого уровня, который далеко не завершен, но всегда есть, по крайней мере, некоторые тесты, которые мы можем пройти примерно через час программирования.
В некотором смысле, CI и CD помогают облегчить завоевание больших проблем. Хотя наша конечная цель может быть важной функцией, которая требует нескольких недель командной работы, непрерывной доставки — в комплекте с флагами функций, постепенным развертыванием и постепенной разработкой продукта, информированной по данным и обратной связи — помогает нам гарантировать, что наши подразделения работы всегда имеют управляемый размер Анкет Это также означает, что в случае, если оказывается, что то, что мы строим, не полезно, мы можем отказаться от него достаточно скоро, не выполняя бессмысленную работу.
Нет беспокойства о неудаче
Беспокойство о неудаче часто связано с социальной обстановкой. Тем не менее, есть огромная выгода от наличия комплексного набора тестов, который выступает в качестве защитной сети для всей команды. В процессе непрерывной интеграции мы минимизируем риск того, что фатальная ошибка будет оставлена незамеченной и развернута для производства путем автоматизации процесса выполнения тестов, а также выполнения стиля кодирования, безопасности и других проверок. Это помогает разработчикам работать без ненужного стресса. Конечно, это предполагает, что каждый участник следует основному правилу не подачи запроса на притяжение без адекватного тестового покрытия.
Если ваша команда практикует обзор кода сверстника (который я очень рекомендую!), То, что имею индикатор состояния сборки прямо в запросе на вытягивание, как это предусмотрено, например, например, Семфор , помогает рецензенту понять, что она может сосредоточиться на более полезных вещах, чем на работе кода.
В конце концов, давайте будем помнить, что основным преимуществом работы в состоянии потока является наше глубоко личное чувство достижения и самооценки, которое с ним связано. Это окончательная мера стоимости любого процесса или инструмента.
Оригинальная версия этого поста была опубликована на Семфор блог . Рад поделиться на dev.to — пожалуйста, отправьте свои отзывы в комментариях. ✌
Оригинал: «https://dev.to/markoa/creating-flow-with-tdd-and-continuous-delivery-jf5»