КОРОТКАЯ ПЕТЛЯ ОБРАТНОЙ СВЯЗИ ДЛЯ СОЛО-КОДИНГА

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

О петлях обратной связи

Полковник ВВС США Джон Бойд разработал концепцию петли OODA, которая является аббревиатурой «наблюдать, ориентировать, решать, действовать» (observe, orient, decide, act). В военных операциях это иллюстрирует процесс принятия решений, основанный на постоянном приеме новой информации.

Наблюдать: получить необработанную информацию о происходящих обстоятельствах и текущей обстановке.

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

Решать: составить план движения к своей цели.

Действовать: выполнить план.

Так как это цикл, этап действия ведет прямо к этапу наблюдения. Это критическая концепция обратной связи, которая позволяет проводить все более успешные итерации. Он широко применим за пределами военных операций: вы можете распознать его как источник метода PDCA (plan-do-check-act).

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

Цикл обратной связи команды разработчиков

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

1. Указания от владельцев продукта или отзывы пользователей.

2. Ежедневные схватки / ссоры со всей командой.

3. Расстановка приоритетов с командой разработчиков.

4. Индивидуальное кодирование и тестирование.

5. Развертывание и мониторинг производительности.

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

Индивидуальный цикл обратной связи с разработчиком

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

1. Построить дисциплину.

2. Уточнить конкретные цели высшего уровня.

3. Расставить приоритеты и спланировать цели среднего и низкого уровня.

4. Автоматизировать свою работу.

5. Заблокировать время для проверки кода.

6. Заблокировать время для обзора процесса.

7. Обновить ваши цели и процессы с результатами ваших обзоров.

Построить дисциплину

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

Почему дисциплина так важна? Потому что, когда вы решаете завершить проект в эту пятницу вечером, вы не собираетесь писать хорошее сообщение о коммите. Вы не собираетесь убирать комментарии к коду. Именно в эти моменты дисциплина позволяет вам не упускать возможность практиковаться, учиться и улучшать ваш рабочий процесс. Дисциплина помогает вам избежать коммитов.

Уточнить конкретные цели высшего уровня

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

Когда обсуждаете новый проект с клиентом, всегда говорите о конкретных достижениях. Это может принять форму выполнения определенной функции к определенной дате или принятия решения о том, как MVP (минимальный жизненный продукт) выглядит для пользователя. Это важно так же для разработчика, как и для клиента. Согласовав в письменной форме, что будет достигнуто и когда, вы с клиентом четко определили цели высшего уровня и можете оценить, как продвигается проект.

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

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

Расставьте приоритеты и спланируйте цели среднего и низкого уровня

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

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

1. Завершите приложение JavaScript.

2. Создайте интерфейс и таблицу стилей.

3. Проведите локальные тесты.

4. Настройте облачный сервер.

5. Разверните приложение в облаке.

6. Делайте тесты.

7. Добавьте репозиторий в GitHub.

8. Публикация на сайтах хакерских новостей.

9. Прибыль.

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

1) исследования облачных провайдеров;

2) выбор сервиса и регистрацию;

3) настройку сервера / экземпляра;

4) добавление интеграции;

5) тестовое развертывание.

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

Автоматизируйте свою работу

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

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

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

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

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

Заблокировать время для проверки кода

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

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

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

Проведите исследование основных лучших практик того, над чем вы работаете. Установите себе ограничение по времени и возьмите то, что вы прочитали, с долей соли. В этой области много кроличьих нор. В качестве отправной точки я бы порекомендовал узнать о DRY-коде и посмотреть, что требует профессионализма в разработке программного обеспечения.

Контрольный список проверки кода

Вот шаблонный контрольный список проверки кода, основанный на некоторых общих рекомендациях.

[] Это решает высокоприоритетный предмет.

[] Это полная реализация, которая следует спецификации.

[] Не по теме изменения не были включены и были добавлены в отставание.

[] Имена переменных имеют смысл и не имеют магических чисел.

[] Правильные и полезные сообщения об ошибках возвращаются при каждой возможности.

[] Отладочных операторов печати не осталось.

[] Этот код является СУХИМ и модульным.

[] Этот код безопасен. Частный и открытый код хорошо разделены.

[] Этот код является собственной документацией или документация обновлена.

[] Пятилетний ребенок мог бы следить за этим, серьезно, это так легко читаемо.

[] Юнит-тесты успешно пройдены.

[] Мастер был объединен с веткой и протестирован.

[] Форматирование соответствует рекомендациям по стилю.

[] Я не могу найти дальнейшие крайние случаи или известные дефекты.

[] Я был бы рад, если бы этот код был публично приписан мне.

[] Я полностью понимаю, что делает код, и влияние изменений, которые я сделал.

[] Я действительно проверил, что он действительно делает то, что сказал.

Вот отличный пример очистки кода с учетом некоторых из вышеперечисленных моментов.

Заблокировать время для обзора процесса

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

Для краткосрочных проектов хорошая отправная точка для планирования процесса рассмотрения находится на каждой половине отметки – один раз в середине и снова после завершения. Долгосрочные проекты могут иметь отзывы на каждой четверти.

Процесс обзора вопросов

Процесс обзора может быть простым, как краткий список вопросов.

1. Каковы были мои главные цели на этот период? Я с ними встречался?

2. Каковы были мои цели среднего и низкого уровня на этот период? Я с ними встречался?

3. Мне бы лучше служили другие или более конкретные цели? Почему?

4. Успешно ли я удалил или автоматизировал препятствия?

5. Я придерживался своего графика проверки кода? Почему или почему нет?

6. Как я могу устранить препятствия в следующий раз?

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

Обновите ваши цели и процессы с результатами ваших обзоров.

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

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

Список литературы:

1. Angerman W.S. Coming full circle with Boyd`s OODA loop ideas: an analysis of innovation diffusion and evolution // Air Force Institute of Technology, 2004. – 141 p. / [Электронный ресурс]. – Режим доступа: https://apps.dtic.mil/dtic/tr/fulltext/u2/a425228.pdf.
2. Boyd J.R. A Discourse on Winning and Losing. – Unpublished Briefing Slides, 1992.
3. Boyd J.R. Patterns of Conflict. – Unpublished Briefing Slides, 1986.
4. Brehmer B. The dynamic OODA loop: Amalgamating Boyd’s OODA loop and cybernetic approaches to command and control // 10th International Command and Control Research and Technology Symposium. – McLean, VA, 17–21 June 2005. – 15 p. / [Электронный ресурс]. – Режим доступа: http://www.dodccrp.org/events/10th_ICCRTS/CD/papers/365.pdf.
5. Coram R. Boyd: The Fighter Pilot Who Changed the Art of War. – New York : Little, Brown, 2002.
6. Hammond G.T. The Essential Boyd. / [Электронный ресурс].  – Режим доступа: www.belisarius.com/modern_business_strategy/hammond/essential_boyd.htm.
7. Hammond G.T. The Mind of War – John Boyd and American Security. – Washington, D.C : Smithsonian Institution Press, 2001.
8. Joint Publication 3-13.1 “Joint Doctrine for Command and Control Warfare (C2W)”. – Washington, 7 February 1996. – 101 p. / [Электронный ресурс]. – Режим доступа: http://www.iwar.org.uk/rma/resources/c4i/jp3_13_1.pdf.
9. Mitchell Mark E. Strategic leverage: information operations and special operations forces // Naval postgraduate school Monterey, California. – 1999. – 231 p. [Электронный ресурс]. – Режим доступа: https://apps.dtic.mil/dtic/tr/fulltext/u2/a360007.pdf.
10. Osinga F. Science, Strategy and War. The Strategic Theory of John Boyd, Abingdon. – UK : Routledge, 2007.
11. Richards Chet. Certain To Win: The Strategy Of John Boyd, Applied To Business. – Philadelphia : Xlibris Corporation, 2004.