Почему (и как) я пишу код с помощью карандаша и бумаги

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

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

И не только это: опытные программисты могут указать вам на пачку листов формата А4, которые они сняли с офисного копировального аппарата, чтобы набросать особенно сложный алгоритм, над которым они работали.

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

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

Зачем это записывать?

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

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

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

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

Знай свой вопрос

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

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

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

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

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

Вопросы, с которыми мы работаем, не похожи на вопросы, которые решают физики или математики. Получают набор параметров и находят недостающие; наши вопросы также являются нашими результатами. Нам уже сказали, каковы наши результаты — нам нужно придумать, как их достичь. Вот почему крайне важно хорошо знать вопрос, потому что вы увидите результат.

Записывать или рисовать то, что вы хотите вывести, — один из лучших способов начать кодирование. Я понимаю, что в нашей быстро развивающейся отрасли ожидается, что мы должны сразу же перейти к программированию, запустив демонстрацию «Hello World». И здорово познакомиться с незнакомым синтаксисом и избавиться от беспокойства, связанного с тем, чтобы попробовать что-то новое.

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

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

Обрисуйте свой код

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

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

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

1. Пользовательский интерфейс для захвата подписи — HTML Canvas? WebGL?
2. Отключить события указателя на остальной части веб-страницы, когда пользователь подписывает
3. Преобразование и сохранение захваченного изображения в файл PNG — JS
4. Затем преобразуйте его в большой двоичный объект (возможно) и сохраните в таблице данных журнала посетителей.

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

Я настоятельно рекомендую набрасывать код для клиентских проектов. Напишите план вместе с вашими пользовательскими требованиями или на обратной стороне распечатанных вами каркасов.

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

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

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

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

Длинная запись против стенографии

Пора начинать кодить. Итак, что вы пишете? «Бдры» или «border-radius"; "div -> p, либо<div><p></div></p>"; "pl(), либоprintln()"; "q(), либоquerySelector()"?

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

Это действительно ваше дело.

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

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

Я постоянно забываю синтаксис. Например, я использую стрелочную нотацию для функций JavaScript с момента ее появления (потому что она короче), и я почти уверен, что если кто-то вдруг попросит меня определить функцию с помощью function ключевое слово, я могу даже перепутать круглые скобки или имя функции, что вызовет синтаксическую ошибку.

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

Непоследовательный поток кода

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

Большинство языков программирования интерпретируются, компилируются и выполняются, так что иногда предварительно написанный код в исходном коде выполняется позже при вызове. Мы делаем это в JavaScript, например, с вызовом функций — функции могут быть определены изначально, а затем выполнены. Экзаменуемые и интервьюируемые могут использовать это, чтобы сначала начать работу над критическим пунктом вашего ответа.

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

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

1. Получите ввод.
2. Вычислите число Фибоначчи.
3. Подведите итоги.
4. Распечатайте результат.

Все шаги в этом плане необходимы; однако 1, 3 и 4 являются более обязательными. Они необходимы, но не настолько важны, чтобы сразу на них сосредоточиться.

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

Потратьте свое время на написание кода, который фокусируется на сути проблемы.

Настоящие профессионалы могут пропустить вперед. Допустим, у меня есть клиентский проект, и мне нужно работать с геометрией треугольника — есть две стороны, противоположный угол, и нужно найти длину третьей стороны. И я решил для начала нацарапать на бумаге, а не открывать свой IDE.

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

Нет смысла записывать обязательные шаги, даже если они понадобятся мне в готовом к работе коде. Но все было бы по-другому, если бы мне пришлось писать это на бланке для ответов на экзамене. Я не могу пропустить другие шаги; тем не менее, я все еще могу начать с кода формулы.

Псевдо-код

Крис уже написал полезная статья о псевдокоде что я настоятельно рекомендую вам внимательно прочитать.

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

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

Вот небольшой псевдокод для макета сетки CSS:

Grid
5 60px rows
6 100px columns

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

Пространство и комментарии

Я считаю, что код на 90% состоит из ключевых слов и на 10% из вкладок. Без пробелов читабельность слов снижается. Отступы необходимы и для рукописного кода. Однако, пожалуйста, не используйте его для каждого уровня, потому что ширина бумаги будет вас ограничивать. Используйте пробелы разумно, но используйте их.

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

Однако, если ваше суждение говорит о том, чтобы подавить один, то сделайте это. Добавьте его в правую часть кода (поскольку вы не сможете вставить его между уже написанными строками, как вы могли бы, скажем, в VS Code). Используйте косую черту, квадратные скобки или стрелки, чтобы обозначить, что это комментарии.

Для испытуемых, которые не уверены в определенном синтаксисе, запишите комментарии. Таким образом, вы, по крайней мере, сообщаете человеку, оценивающему вашу статью, о вашем намерении с помощью этого неправильно отформатированного кода. И используйте только правильные разделители для обозначения комментариев — например, это будет косая черта для JavaScript.

Аналоговый против цифрового

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

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

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

Мои любимые инструменты для написания кода от руки

Подойдет любой карандаш и бумага! Но есть много вариантов, и вот несколько инструментов выбора, которые я использую:

Не существует способа «написать» код

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

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

1. Начните с записи (при необходимости с примерами данных) вывода вашего кода.
2. Напишите план кода. Пожалуйста, ограничьтесь тремя шагами для небольших или менее сложных проектов.
3. Используйте длинные обозначения. Разработчики, пишущие для себя, могут использовать стенографические обозначения, если написанное разборчиво и имеет смысл для вас, когда вы вернетесь к нему позже.
4. Когда вы ограничены во времени, рассмотрите возможность написания кода, который в первую очередь решает суть проблемы. Позже запишите вызов этого кода в нужном месте вашего последовательного кода.
5. Если вы чувствуете себя уверенно, попробуйте написать псевдокод, обращающийся к основной идее.
6. Используйте правильные отступы и пробелы — и помните о ширине бумаги.

Вот и все! Когда вы будете готовы попробовать писать код вручную, я надеюсь, что эта статья поможет вам начать. И если вы садитесь на экзамен или собеседование, я надеюсь, что это поможет вам сосредоточиться на правильном ответе на вопросы.