Кент Бек — разработчик программного обеспечения, создатель таких методологий разработки ПО как экстремальное программирование (XP) и разработка через тестирование (TDD); в данный момент работает на Facebook. Вашему вниманию предлагается перевод набросков идей о том, как можно было бы сделать свою работу эффективнее. Разделение программистов на мастеров и подмастерьев, используемое на протяжении статьи, взято Кентом Беком из книги «Программист-прагматик» Эндрю Ханта и Дэвида Томаса.

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

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

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

Время

• Разбивка задач (slicing). Возьмите большой проект, порежьте его на «тонкие» кусочки и переставьте их между собой так, чтобы они устроили вас с учетом ваших обстоятельств. Я всегда способен разделить проект на еще более мелкие задачи, и я всегда могу найти новую перестановку этих задач, которая будет отвечать другим потребностям.
• Одно дело за раз. Мы настолько сосредоточены на эффективности, что стараемся уменьшить число циклов обратной связи в попытке уменьшить «оверхед» (накладные расходы). Это приводит позже к появлению затруднительных случаев отладки, предполагаемая стоимость которой будет больше, чем накладные расходы от цикла, которого мы избежали ранее.
• Сделайте, чтобы это заработало; сделайте, чтобы это было написано правильно; сделайте, чтобы это работало быстро (make it run, make it right, make it fast) (Здесь следует привести примеры «Одного дела за раз», «Разбивки задачи» и «Простоты изменений»)
• Простота изменений. Когда вам встречается сложное изменение, сначала сделайте его простым (осторожно: это может оказаться трудным делом — не исключен рефакторинг и выплата технического долга), затем сделайте простое изменение (используйте разбивку задач, изменение одного дела за раз, концентрацию и изоляцию). Чаще всего здесь подразумевается разбивка задачи на более простые.
• Концентрация. Если вам необходимо изменить несколько элементов, сначала переделайте свой код так, чтобы изменение требовалось сделать лишь в одном элементе.
• Изоляция. Если вам требуется изменить только часть элемента, то извлеките эту часть, чтобы изменялся весь подэлемент целиком.
• Измерение базового уровня (baseline measurement — точное измерение функционирования процесса перед тем, как будет осуществлено любое изменение). Начинайте проекты с измерения текущего состояния мира. Это идет вразрез с нашими инстинктами инженера, предпопределяющими сразу же что-то «фиксить» — но только после того, как вы проведете базовое исследование проекта, вы поймете, действительно ли вы что-то исправляете.

Обучение

• Знайте, что хотите сделать. Перед запуском кода, сформулируйте явное предсказание того, что произойдет.
• Конкретные гипотезы. Если программа дурно себя ведет, точно и ясно выразите мысль о том, что по-вашему в ней не так, прежде, чем сделать изменение. Если у вас есть одна или более гипотез, вам поможет дифференциальная диагностика.
• Убирайте посторонние детали. Когда репортите баг, найдите кратчайший путь из необходимых шагов для его воспроизведения. Когда изолируете баг, найдите минимальный тестовый кейс. Когда используете новое API, начинайте с самого простого примера. «Вся эта ерунда не имеет значения» — дорогое предположение, которое может обернуться против вас, когда в итоге что-то пойдет не так. Пример: если вы видите баг в мобильном приложении — попробуйте воспроизвести его при помощи curl.
• Пробуйте различный масштаб. Свободно перемещайтесь между уровнями «масштабирования» проекта. Возможно, вы имеете дело с проблемой проектирования, а не тестирования. Возможно, проблема связана с людьми, а не с технологией [читерство, поскольку это утверждение всегда истинно].

За гранью логики

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

Риск

• Список развлечений. Когда к вам «по касательной» приходят «левые» идеи, просто запишите их и быстро возвращайтесь к работе. Пересмотрите этот список идей чуть позже — после того, как в текущем деле вы достигните места, где можно остановиться.
• Прикармливайте идеи. Идеи похожи на мелких птиц — их также легко спугнуть; и если пугать их регулярно, то они перестанут прилетать к вам. Когда у вас появляется идея, «покормите» ее немного. Убедитесь в несостоятельности идеи (то есть инвалидируйте ее) настолько быстро, насколько сможете — но обосновывайте свой отказ взяться за нее при помощи данных, а не из-за нехватки самооценки.
• 80/15/5. Тратьте 80% вашего времени на работу с низким уровнем риска/достаточной отдачей. Тратьте 15% вашего времени на работу с высоким уровнем риска/с высокой отдачей. Тратьте 5% вашего времени на то, что не дает вам покоя, невзирая на потенциальную отдачу. Обучайте следующее поколение делать 80% вашей работы. К тому времени, когда кто-то готов взять этот груз на себя, один из ваших 15% экспериментов (или, что случается реже, один из 5% экспериментов) отплатит результатом и станет вашими новыми 80%. Затем повторите всё сначала.

Заключение

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