Думайте, прежде чем писать код. Я даю этот совет каждому начинающему инженеру, с которым встречаюсь. Однако большинство молодых разработчиков с трудом ему следуют.
Уделяя время тому, чтобы замедлиться и подумать, вы станете более эффективным инженером и лучшим специалистом по устранению неполадок и решению проблем.
Давайте рассмотрим три сценария, в которых это актуально: при собеседовании на работу, при исправлении ошибок и при разработке функций.
Собеседования при приеме на работу
Распространенная ошибка во время собеседований у доски — начать кодить до того, как вы полностью поймете проблему. Скорее всего, интервьюер дал вам формулировку проблемы, в которой намеренно или ненамеренно упущены многие детали.
Например, какие предположения вы можете сделать? Каковы ваши ограничения? Можете ли вы предположить, что вам всегда будут предоставляться достоверные данные, или вам нужно защититься от недостоверных аргументов? Будет ли набор данных достаточно мал, чтобы вы могли использовать метод грубой силы, или вам нужно оптимизировать алгоритм для конкретных пространственных или временных ограничений? Задавайте вопросы до тех пор, пока не почувствуете, что полностью понимаете проблему.
Далее, какие тестовые примеры вы должны рассмотреть? Часто нет необходимости писать полностью функциональные тесты во время кодирования, но неплохо записать типы входных данных, которые вы хотели бы протестировать, и ожидаемый результат для каждого из них. Например, если вы пишете функцию, которая определяет, является ли строка палиндромом, то в качестве тестовых входных данных вам, возможно, понадобится как минимум следующее: racecar, noon, dog, moon, 42. С помощью этих пяти тестовых примеров вы можете рассмотреть, как ваш код должен обрабатывать палиндромы четной или нечетной длины (racecar и noon), строки четной или нечетной длины, которые не являются палиндромами (dog и moon), и недопустимый ввод (42). Я уверен, что вы можете придумать и другие тестовые случаи.
Наконец, можете ли вы написать псевдокод, чтобы проверить ваш подход на высоком уровне? Прежде чем вникать в тонкости реального кода, неплохо бы продумать, как вы можете решить проблему, чтобы на ранней стадии выявить проблемы в вашем подходе.
Исправление ошибок
При устранении неполадок неопытные разработчики склонны паниковать. Они начинают судорожно пробовать различные способы, пытаясь решить проблему. Это ошибка. Сделайте паузу и обдумайте проблему.
Что, по вашим данным, изменилось с момента, когда код работал, до момента, когда он перестал работать? Если вы обновили версию зависимого компонента, как выглядит журнал изменений между двумя версиями? Если код работает на вашей машине, но не работает в тестовой среде, что изменилось в этих двух средах? Если вчерашний релиз работал нормально, но в сегодняшнем релизе есть ошибка, какие коммиты были включены в сегодняшний релиз, которые могут быть виновниками? Если вы не знаете, с чего начать поиск первопричины проблемы, у кого вы можете спросить, кто может иметь представление о том, что происходит?
Даже если вы потратите всего пять минут на обдумывание проблемы, прежде чем приступите к ее устранению, в конечном итоге вы сэкономите часы.
Разработка функциональности
Разработка новой функциональности должна начинаться с плана. Каким критериям приемки вы должны соответствовать, чтобы должным образом удовлетворить потребности пользователя? Есть ли у вас тестовые примеры, написанные либо в виде реального исполняемого кода, либо в виде пустых пунктов для рассмотрения? Если вы разрабатываете конечную точку API, какими должны быть входы и выходы? Если вы работаете со сложными данными, какой тип структуры данных будет лучше всего представлять данные?
Потратьте время на проектирование кода, прежде чем приступать к работе. Возможно, вы торопитесь начать кодирование, но если потратить время на планирование, это избавит вас от мучительного переписывания кода в дальнейшем.
Заключение
Начинающие инженеры сразу же приступают к кодированию, не разобравшись в проблеме и не продумав возможные решения. Поэтому прежде чем начать бешено набирать текст, остановитесь. Подумайте, прежде чем писать.