Планирование вашего кода имеет гораздо большее значение, чем вы думаете.

Если вы заядлый пользователь Python, возможно, вы знакомы со знаменитой поэмой «Дзен Python». Он был написан Тимом Питерсом (одним из первых разработчиков языка), и его можно полностью прочитать, введя команду import this в интерпретаторе Python.

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

В целях данной статьи хочу обратить ваше внимание на следующие две строчки из стихотворения:

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

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

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

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

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

1. Как специалист по данным, вы получите преимущество на рабочем месте

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

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

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

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

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

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

Быть конкурентоспособным кандидатом на работу сводится к одному простому вопросу: можете ли вы предложить востребованный набор навыков, который трудно найти?

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

Овладейте обоими. Стать желанной.

2. Вы избежите крайне раздражающих ошибок в будущем

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

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

Видеть результаты было, по общему признанию, немного забавно. Многие из студентов раньше не писали больших программ и наивно заявляли, что рассчитывали потратить всего 6–8 часов на написание всего кода. Я предупредил их, что это серьезная недооценка.

Как я это узнал? Ну, я (и многие мои коллеги) работали над многими проектами, где на исправление одной ошибки уходило более 8 часов.

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

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

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

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

3. Вы будете разрабатывать более удобный и расширяемый код

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

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

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

Когда этот день наступит, произойдет одно из двух:

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

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

Нужно ли мне сказать больше?

Заключительные мысли + Резюме

Если у вас есть привычка писать код без какого-либо планирования, пришло время внести изменения. Вот краткое напоминание о причинах для этого:

  1. Карьерные очки. Если вы специалист по данным, овладение навыками правильного планирования своего кода даст вам серьезное преимущество среди коллег.
  2. Спокойствие. Разрабатывая и проверяя точность на ранних этапах — когда ваши структуры данных и алгоритмы все еще написаны на человеческом языке — вы уменьшите вероятность появления досадных ошибок в дальнейшем.
  3. Преимущества во всем. Хорошее планирование = хороший код. Это, в свою очередь, означает счастливых коллег, счастливых будущих работников и счастливую компанию. Написать проектную документацию. Распространяйте счастье.

Удачи в ваших начинаниях по программированию!

Хотите преуспеть в Python? Получите эксклюзивный бесплатный доступ к моим простым и понятным руководствам здесь. Хотите читать неограниченное количество историй на Medium? Зарегистрируйтесь по моей реферальной ссылке ниже!