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

Воспринимаемые зависимости

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

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

// get e-mails
// get defined categories
// classify e-mails

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

// get e-mails
emails = get_emails()
// get defined categories
categories = get_categories()
// classify e-mails
classifier = new Classifier(categories)
for email in emails:
    scores = classifier.get_score(email)
    category = get_top_category(scores)
    print email.title, category

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

def get_top_category(scores):
    return scores.keys()[0]

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

Не могу обернуть вокруг себя голову

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

Стратегия: Вторая пара глаз
Не все нужно решать самостоятельно. Если вам непонятно что, просто поговорите с коллегой, менеджером или клиентом. Если вы не понимаете, как это сделать, просто начните объяснять коллеге, почему вы не можете двигаться дальше.
Очень важной частью этой стратегии является необходимость объяснить и определить вашу проблему. Даже простое объяснение может решить проблему. В таком случае это называется Отладка резиновой уточки: объяснение вашей проблемы резиновой утке.

Выбор

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

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

  • Все, что уже предоставлено (например, URL-адреса API, соответствующая документация)
  • Требования
  • Важные условия (например, должно работать, когда устройство не в сети)
  • Возможные проблемы (например, может быть слишком много элементов для получения в одном запросе API)

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

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

Скучный…

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

Стратегия 1: Примите это
Иногда у вас много энергии, но вы не можете продвинуться вперед в решении проблемы (например, по одной из причин, упомянутых выше). Это идеальный вариант. время, чтобы сделать эту скучную задачу, которую вы откладывали. Это на 100% ясно, и каждая минута, которую вы потратите на это, действительно продвинет вас вперед.

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

  • расширенные функции поиска/замены в вашей среде IDE
  • найти/grep/sed в командной строке
  • автоматизация пользовательского интерфейса

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

Ошибки

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

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

Первоначально опубликовано как Как избавиться от тупика при программировании в моем блоге.