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

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

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

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

  1. Понять проблему
  2. Составьте план
  3. Выполнить план
  4. Подумайте об успехах/неудачах плана и о том, что вы могли бы сделать лучше

Гораздо легче сказать, чем сделать! Ниже приведен список моих собственных стратегий (многие вдохновлены этой книгой), которыми я недавно поделился с учеником здесь, в 20spokes.

При отладке

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

  1. Я действительно определил проблему? Могу ли я четко изложить эту проблему коллеге?
  2. Разбил ли я проблему на мельчайшие части? Могу ли я решить любую из этих частей по отдельности?
  3. Я перечислил все возможности того, что может быть основной проблемой? Попробуйте изолировать эти возможности. При необходимости создайте одноразовый код, чтобы изолировать сценарий.
  4. Нужны ли неизвестные для решения этой задачи? Устраните как можно больше неизвестных.
  5. Подтвердил ли я свой ввод? Каков мой ожидаемый результат?
  6. Подтвердил ли я свой поток через приложение? Задействую ли я все функции/пункты приложения, на которые рассчитываю? Используйте такие инструменты, как Pry для Ruby или Debugger для Javascript, или просто старый добрый console.log.
  7. Искал ли я в нужных местах потенциальные подсказки, такие как консоль браузера, журналы сервера или сетевые журналы?

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

Об общей стратегии

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

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

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

  1. Как это решение может измениться со временем?
  2. Является ли это решение СУХИМ (не повторяйтесь)? Буду ли я размещать аналогичные функции в нескольких местах? Я хочу избежать этого, насколько это возможно.
  3. Имеет ли это решение единственный источник истины? Например, буду ли я искать одни и те же данные в разных местах?
  4. Поддерживают ли это решение другие разработчики? Как разработчик, новичок в этом проекте, интерпретирует этот код? Поймут ли они название этой функции?
  5. Исследовал ли я проблему в Интернете, чтобы узнать, как другие люди подходят к подобным вопросам? (Конечно, вы не хотите брать старый ответ, который видите в Интернете. Примените тот же метод к этим найденным решениям.)
  6. Проверил ли я документацию, чтобы убедиться, что определенные решения возможны/невозможны? (Проверил ли я документы?)

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

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