Три типа программистов

Tri tipa programmistov

Предисловие: эта статья — часть цикла статей под условным названием «Не усложняй»: теоретических рассуждений и личных мнений про программирование вообще и программирование на Ruby в частности. Основная мысль проста: сложность — наш враг. Всё что мы делаем, всё чего мы пытаемся достичь при разработке софта — это справиться со сложностью, привнесённой требованиями, предметной областью и запросами пользователей. И всё же, некоторые из наших подходов, техник и библиотек привносят нежелательную сложность сами по себе — а это нехорошо. Такие дела.

Утверждение: я глубоко убеждён, что существует всего три типа хороших программистов:

  • а) программисты-инженеры: вся программа для них механизм, или даже чертёж этого механизма;
  • б) программисты-математики: вся программа — формула (или система формул), доказательство какой-то теоремы;
  • в) программисты-писатели: вся программа для них — текст.

(Ещё есть множество типов плохих программистов: программисты-руководители, программисты-бизнесмены, программисты-чернорабочие и так далее. Но о них мы говорить не будем. Вообще.)

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

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

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

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

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

Это утверждение сперва может показаться неочевидным, но, если вдуматься, оно станет совершенно понятным. Все эти споры и «священные войны», где разумные вроде бы люди задают риторические вопросы вроде «как вообще кто-то может писать большие объёмы кода на динамических языках»?, или «как вообще кому-то может нравиться Java?», или что такое правильное ООП (и что никто этого не понимает), или что ФП — единственный Ответ На Все Вопросы...

Не менее, чем в Утверждении 1, я убеждён, что язык программирования (а точнее язык + инструменты + инфраструктура + сообщество) навязывает способ мышления, и удовольствие разработчика от работы и его продуктивность сильно связаны с тем, насколько способ мышления разработчика соответствует способу мышления языка программирвоания и экосистемы, с которыми ему приходится работать.

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

Утверждение 3: Ruby — для типа (в), для программистов-писателей.

К счастью, это утверждение я доказывать не обязан: намного сильнее и чище, чем смог бы я, его доказывает создатель языка. В известной книге «Beautiful Code», глава, написанная Юкихиро Мацумото называется «Восприятие кода как эссе» ("Treating Code As an Essay") и излагает именно такой подход к Ruby как к языку программирования: он создан скорее для того, чтобы на нём писать, чем проектировать или вычислять. Этот подход или для вас, или нет.

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

В отличие от Матца, я не считаю, что «код в первую очередь предназначен для чтения» (и потому должен в первую очередь быть Хорошим Текстом) — это непреложное правило. Некоторые языки — хорошие языки — очевидно предназначены для написания скорее «чертежей»: больших и сложных цельных структур, которые читатель должен долго исследовать и разбирать, прежде чем поймёт. А на других языках можно написать мозговыносящую, зато компактную формулировку нового и невероятно сложного алгоритма.

Но Ruby, определённо — для писания текстов. Либо вы это понимаете, либо вы выбрали не тот язык.

Замечание: Естественно, все наши «тексты» имеют прагматическую цель. Мы пишем что-то работающее, расширяемое и поддерживаемое, решающее важные проблемы, а не просто самовыражаемся. В каком-то смысле, все мы — программисты на Ruby — пишем части одного большого текста. Поэтому руководства по стилю и coding convetions полезны. В конце концов, нет смысла пытаться смешать пять частей «Поминок по Финнегану» с одной частью «Чужака в чужой стране» и надеяться получить какой-то осмысленный результат.

Важный Вывод: Есть только один надёжный признак хорошего Ruby-кода, хорошей Ruby-библиотеки, хорошей Ruby-архитектуры:

На любом уровне кода — это чистый, читабельный, лаконичный, остроумный текст.

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

P.S. Важное замечание: По странной иронии, Rails — та самая штука, которая сделал Ruby популярным — не разделяют «писательский» подход. Они стремятся спрятать выразительность и свободу выбора средств под капот, а вместо того дают разработчику множество паттернов, соглашений, лучших (и единственных) практик и прочих знаков «инженерных» инструментов. Поэтому сегодня есть два разнонаправленных тренда: с одной стороны, многие Rails-разработчики переходят на другие языки и подходы, продолжая считать Rails крутой штукой (это, как раз, инженеры), а другие, продолжая испытывать нежность к Ruby, ищут другие подходы к ORM, роутингу и views, более «рубёвый», чем предлагали Рельсы.


Хочешь узнать больше?

Записывайся на курсы по изучению программирования вместе с опытным наставником! Мы учим и новичков, и уже опытных разработчиков. С чего начнём?

Выбрать курс Nastavnik po veb razrabotke