Писатели используют наброски, художники — наброски, а программисты — псевдокод.

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

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

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

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

При этом даже самые мощные инструменты подходят не для каждой работы. Когда структура кода очень жесткая, например, при использовании ORM, такого как Sequelize, для вызовов базы данных MySQL или настройке маршрутов API с помощью Express.js, псевдокодирование не так уж полезно. В этих примерах код должен быть написан очень особым образом. К моему удивлению, когда пришло время делать проект с использованием тяжелой серверной архитектуры Model-View-Controller (MVC), я почти не писал никакого псевдокода (хотя я потратил много времени на составление маршрутов).

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