Многие шаги лучше, чем один - в решении проблем
В своем последнем посте я сформулировал для себя основное правило: всегда в качестве первого шага разбивать проблему на управляемые шаги. Я должен сделать это до того, как начну записывать какой-либо код.
Соответственно, записав это «основное правило» в качестве сообщения в блоге, я сознательно придерживался его на протяжении последней недели программирования - третьей в четырехнедельном предварительном курсе Makers Academy. Конечно, было несколько моментов, когда я упал. Но всякий раз, когда я замечал, что трачу время на повторение одной и той же проблемы снова и снова, я также понимал, что еще не изложил свои спецификации.
Разбиение на проблему - жизненно важный навык, и быстрый поиск на Medium подбрасывает много статей, которые подчеркивают его важность в программировании. Они также действуют как хорошие руководства, объясняющие, как разделить бриф на более мелкие задачи. Многие из этих советов включают ввод ключевых слов в поиск Google, запись ваших шагов в виде комментариев в коде и, если проблемы не исчезнут, формулирование гипотез со всеми доступными доказательствами (привет, вывод ошибок). Однако, помимо этих предложений, у меня есть еще несколько практических советов для себя:
Напишите / нарисуйте на бумаге
Когда я пишу код, у меня всегда есть блокнот и ручка рядом с компьютером. Я использую его, чтобы вручную записывать свои спецификации, прежде чем приступать к программированию.
Для меня составление спецификаций позволяет мне видеть, что моя программа должна делать на детальном уровне. Более того, есть некоторые вещи, которые я хочу, чтобы программа делала, но я никогда не смогу объяснить их словами. В таких случаях я могу рисовать диаграммы в своей записной книжке, где-то записывая идеи. Я использую много стрелок, которые соединяют условия с возможными результатами или указывают вверх и назад на самих себя. Отсюда я смогу увидеть, какие методы мне могут понадобиться или какие объекты я могу захотеть использовать. Стрелки показывают, какие условные выражения мне могут понадобиться и какие части программы нужно выполнить в цикле.
После этого шага я возвращаюсь в текстовый редактор и записываю свои шаги в виде комментариев.
Решите проблему
Этот совет был вдохновлен недавно прочитанной мной статьей Джастина Розенштейна, соучредителя приложения для повышения производительности Asana. Хотя статья, озаглавленная Хаки для повышения продуктивности: как преодолеть прокрастинацию, столкнувшись с дискомфортом, больше посвящена общей производительности, чем программированию, я действительно думаю, что ее основной тезис помог мне стать лучшим программистом.
Бывают дни, когда, даже после разбивки проблемы на мельчайшие возможные шаги, даже они кажутся невозможными. В таких случаях полезно четко указать, в чем именно заключается проблема и почему она сохраняется как проблема. Лично я говорю это вслух, например (вот вчерашний) «Результатом является массив чисел с плавающей запятой, а не целых чисел, а ката запрашивает массив целых чисел».
Отсюда вы можете понять, почему проблема является проблемой. Затем вы можете разбить проблему еще дальше, покопавшись в почему исходной проблемы. Возможно, это потому, что вы ранее пошли по неправильному пути в своем коде, или, может быть, это потому, что вы неверно истолковали возвращаемое значение определенного блока.
В этом случае очень полезен совет, о котором я упоминал ранее - чтение сообщения об ошибке.
Сходите на обед или просто ложитесь спать
В конце концов, мы все люди. Еда, вода, сон и упражнения важны для мозга. Слишком долго зацикливаясь на проблеме, я становлюсь голодным, устаю, обезвоживаюсь. Как только я сижу перед компьютером, не делая ничего конструктивного, самое время встать и утолить один из моих основных инстинктов. Если сейчас около 12 часов, то это еда. Если ночь, пора спать. Если беспокойство, то это упражнение.
Если текущая задача может подождать, обычно лучше отойти от компьютера и использовать это время для обновления.
