Помните, что вы делали вчера? А позавчера? Четыре дня назад? Месяц назад? Вряд ли вы сможете дословно вспомнить, что мелькало на 69‑й странице вашей любимой книги или какие точные реплики звучали в той серии того сериала. И это нормально — наш мозг сохраняет только то, что считает действительно важным, а всё остальное отбрасывает, чтобы не перегружаться.
Точно так же обстоят дела и с кодом. Когда вы возвращаетесь к проекту, чтобы починить баг или добавить новую функциональность, вы сначала читаете код заново: знакомые приёмы встречаются, но в целом вы анализируете каждую строчку.
Часто можно услышать, что код — это средство общения с компьютером: набор инструкций, например: «положи из X в Y». Но после компиляции в байт‑код и многочисленных оптимизаций от вашего исходника остаётся лишь упрощённый набор команд. Машине безразличны стиль, комментарии и даже длина имён — она выполнит любую версию кода.
А вот людям всё это куда важнее, поэтому правильнее сказать, что код мы пишем не только для компьютера (хотя это тоже важно), но и для коллег, для себя и для будущего «Я».
История знает немало исследований: например, ещё в 1989 году в IBM подсчитали, что больше половины рабочего времени разработчиков уходит не на новое кодирование, а на чтение и понимание чужого кода. Поэтому чем чётче выражена мысль в коде, тем быстрее команда поймет, как он работает, тем проще сопровождать и развивать проект.
Давайте сменим установку: думать не о том, как код поймёт машина, а о том, как его воспримут коллеги и мы сами в будущем.
Наша работа — это умственный труд, результатом которого становятся тексты: код, документация, сообщения в коммитах и комментарии. Вокруг нас много примеров того, как может быть написан текст по-разному: Научная статья — строгая. Пост в блоге — разговорный. Сообщение в мессенджере — короткое и по делу. Код — это тоже текст, просто со своей спецификой. И у него тоже есть читатель.
Чтобы понять, насколько важно, как написан текст, представьте себе такое письмо:
Здраствуйте Я ПРОГРАМИСТ с БОЛЬЩИМ апытом делал сайты и приложения для интирнета. Пишу код на джаве и пхп ещо умею с питон и руби. Работал в разны места делал всьо што гаварили. Харашо разбераюсь в компютерах и серварах, могу делать апдейт и чинить баги. Если вазьмёте меня, не пажелеете, я осен-осен стараюс.
Дочитывать не хочется, а приглашать на собеседование — тем более. Даже если письмо будет оформлено без ошибок, оно всё равно может произвести не лучшее впечатление:
Многоуважаемый господин! Сим доношу, что имею значительный опыт в делах программных: создавал сайты и приложения для сети, пишу на Java и PHP, равно как и с Python и Ruby знаком не понаслышке. Служил в разных местах, поручения исполнял добросовестно. В компьютерах и серверах разбираюсь, умею обновлять системы и исправлять неполадки. Аще примете — не пожалеете. Труд люблю, дело своё знаю.
Теперь это грамотно. Но стиль — перегружен, устаревший и странно напыщенный. Такое письмо вызывает уже не раздражение, а недоумение.
Теперь представьте: это не кандидат, а ваш код. Что будет, когда два таких специалиста объединятся в одну команду? Скорее всего, в кодовой базе появится нечто подобное:
Здраствуйте, господин! Сим доношу, что Я ПРОГРАМИСТ с БОЛЬЩИМ апытом делал сайты и приложения для сети. Пишу код на Java и PHP ещо умею с питон и руби не понаслышке. В компьютерах и серверах разбираюсь, Харашо разбераюсь в компютерах и серварах, могу делать апдейт и чинить баги. Если вазьмёте меня, не пажелеете. Труд люблю, дело своё знаю.
Так выглядит проект, где два разработчика и полная свобода. А теперь добавьте к ним в команду фаната "Звёздных войн", любителя Йоды, обожателя аббревиатур и экономного комментатора. Результат — код, который… ну, "вроде работает", но никто не понимает, как именно.
И дело не в грамматике, не в запятых. Проблема глубже: код теряет свою речь и становится полностью неестественным.
При этом менеджеры и продукт-оунеры оценивают таких кандидатов по совершенно другим критериям: затраченное время и стоимость труда. Я ни разу не слышал, чтобы разработчиков штрафовали или увольняли за работающий, но плохо написанный код. Порой даже некомпетентные руководители могут подталкивать к этому, говоря: «Закостыли», «Делай хоть как-то», «Потом перепишем». А со временем сами начинают смеяться над своими решениями от безысходности.
Единственный, кому по-настоящему нужен ясный код — это высокомотивированный разработчик, который хочет разобраться и сделать хорошо. Такой, как вы. Никто, кроме таких людей, как вы, не будет действительно заботиться о коде. Тимлиду проще настроить линтеры, ввести формальные код-ревью и регламенты, по которым без особого вникания будут ставить друг другу галочки. Но только увлечённый разработчик задаётся вопросом: удобно ли это читать, сопровождать, дорабатывать? Поэтому очень важно отстаивать своё мнение — ведь завтра именно вам придётся разбираться в том, что вы написали сегодня.
Не существует самого красивого человека на свете для всех, лучшей книги, лучшего сериала. Так же не существует и идеального кода. Даже в Open-Source проектах, за которыми следят тысячи разработчиков, всегда найдутся спорные решения или места, где можно было бы сделать лучше.
Но цель не в том, чтобы достичь идеала. Цель — в намерении. В желании писать так, чтобы код был понятен, аккуратен, приятен в работе.
Когда рядом есть люди, которые пишут с вниманием, с уважением к будущим читателям — это вдохновляет. Хочется и самому придумать название переменной чуть удачнее, структурировать код так, чтобы он читался легко. Такая культура — заразительна, и она создаёт особую атмосферу в команде.
Если вы возьмёте на вооружение практики, описанные в этой книге, — вы уже на голову выше большинства. Потому что стараетесь. Потому что старание видно в коде. И это не выдумка — это то, что действительно ощущается теми, кто читает и поддерживает проект.