Вечные идеи в меняющейся индустрии
В начале своей карьеры я испытывал настоящий голод по профессиональной литературе. Я старался покупать и читать все популярные книги о программировании, какие только мог найти. Эта привычка, вероятно, зародилась ещё в школьном кружке по информатике. Тогда казалось, что секрет превращения в хорошего специалиста скрыт в какой-то сокровенной книге, которую нужно лишь найти и прочесть.
Однажды коллега спросила меня: зачем я читаю книги, если информация в них устаревает ещё до момента публикации? Её мысль была в том, что в нашей индустрии знания меняются слишком быстро, а значит, логичнее черпать их из цифровых источников — блогов, конференций, курсов и социальных сетей. Не помню, что я ответил ей тогда, но сейчас я с ней солидарен. Поэтому пару лет назад я раздал добрую половину своей библиотеки. Оставил лишь старое «старьё», которое никому не нужно (вроде книг по Pascal, Basic или Prolog), и действительно ценные экземпляры, с которыми не смог расстаться.
Я почти не вижу смысла сегодня покупать, например, справочник по Java Дэвида Флэнагана или толстенный том по Angular или React. Нет ничего хуже книги по конкретному языку или технологии. Нужно просто признать: времена «Языка программирования C» Кернигана и Ритчи ушли. Сегодня актуальную информацию о технологии или языке мы берём из онлайн-источников — официальной документации, стандартов, спецификаций, RFC, живых примеров и репозиториев. Языки и фреймворки меняются так быстро, что свежие данные появляются именно в сети. Даже такие относительно стабильные вещи, как HTML, прекрасно задокументированы онлайн. Непонятно, зачем издавать по ним книги — разве что для заработка или самоутверждения.
Другое дело, если вы эстет и вам нужна красивая профессиональная полка — это часть атмосферы, часть вашего рабочего «вайба».
Мне гораздо интереснее искать книги, которые не теряют актуальность с годами. Это, скорее, философские труды, нежели сугубо практические руководства. И мне кажется, что «Программист-прагматик. Путь от подмастерья к мастеру» Эндрю Ханта и Дэвида Томаса — как раз одна из таких книг.
Я люблю читать бумажные книги. Долгое время у меня не было этого издания, но недавно я приобрёл юбилейное переиздание. Хотя прочитал я его только сейчас, я был хорошо знаком со многими его тезисами и концепциями — они стали настолько популярны в индустрии, что на них бесчисленное количество раз ссылались другие авторы. В этом смысле читать книгу было любопытно ещё и «исторически»: увидеть первоисточник многих мыслей, которые давно разошлись на цитаты.
Знакомые концепции, ставшие классикой
Принцип DRY (Don't Repeat Yourself) о борьбе с дублированием кода был для меня одним из важнейших ориентиров очень давно. Конечно, сегодня его знают даже те, кто никогда не слышал о самой книге. Принцип ETC (Easy to Change) — писать функции и модули так, чтобы их было легко менять в будущем, — менее популярен как аббревиатура, но ему следуют все, включая меня. Я люблю говорить, что код должен быть как пластилин, чтобы мы всегда могли изменить его форму. Если убрать лозунг, то мысль проста: код живёт дольше решений, которые его породили, а значит, должен спокойно переживать смену контекста.
Я знал, что популяризация «теории разбитых окон» в разработке ПО тоже началась с этой книги. Авторы проводят аналогию между кодом и социологической теорией: если в доме разбито одно окно и его не чинят, скоро все окна окажутся разбитыми. То же самое происходит в кодовой базе: одна неисправленная ошибка, один небрежный кусок кода — и проект начинает скатываться в хаос. Иногда это даже не про баги, а про «норму»: команда постепенно привыкает, что «так можно», и планка качества опускается незаметно.
Размышляя над этим, я понял, что всех разработчиков можно условно разделить на три типа:
🔹 Первый — аккуратно обходит дом, находит дверь, входит и бережно поддерживает порядок. Он уважает существующую архитектуру, улучшает её точечно и не ломает то, что работает.
🔹 Второй — не тратит время на поиск двери. Он разбивает окно, чтобы попасть внутрь, а потом и вовсе прорубает топором дыру в стене. Результат есть, но какой ценой? Окна разбиты, стена повреждена, а технический долг растёт.
🔹 Третий — не хочет разбираться со старым домом. Он начинает строить новый. В итоге он действительно попадает в дом… но только другой и через год, ведь стройка — дело не быстрое.
Какой вы разработчик? И, что важнее, каким хотите быть?
Легендарная резиновая уточка на столе многих программистов тоже обязана своим появлением этой книге. Идея в том, чтобы был кто-то (даже неодушевлённый), кому можно адресовать вопрос, ведь правильно сформулированная проблема — это половина решения.
Утки были подарками на многих IT-конференциях, их продают на маркетплейсах в разных раскрасках и сеттингах. Это стало важной частью гиковской культуры, хотя, возможно, многие и не знают, откуда растут ноги у этого явления. Лично я не фанат этой концепции. Кажется, она была актуальна до появления Google, StackOverflow и ChatGPT. Теперь я могу задать вопрос им или коллегам — сегодня редко кто создаёт программы в полном одиночестве. Хотя сама практика «объясни проблему вслух» по-прежнему работает — уточка просто сменила форму.
Обновление, но не без огрехов
Юбилейное издание было значительно переработано спустя двадцать лет, хотя кое-где даже после актуализации мелькают упоминания устаревших технологий вроде Object Pascal, CORBA или Lisp. Это понятно — авторы люди той эпохи, и в последние годы они, скорее, связаны с академической средой, нежели с коммерческим программированием.
Некоторые советы, вроде:
Всегда отвечайте на сообщения электронной почты и голосовые сообщения, даже если ваш ответ звучит просто: "Я вернусь к вам с этим позже"
свели бы меня с ума, если бы я им следовал. Почта сегодня — это часто бездонная мусорка с невероятным количеством спама, рекламы и ненужных рассылок. Цифровой шум современности несравнимо громче, чем во время первой публикации этой книги. Кроме того, мгновенная «вежливость» иногда превращается в бесконечную доступность, а это уже не про продуктивность, а про выгорание.
Однако многие идеи в книге, лежащие вне конкретных технологий, не теряют актуальности и сегодня.
Ортогональность: независимость как основа стабильности
Ортогональность в контексте разработки ПО — это принцип проектирования, при котором компоненты системы максимально независимы друг от друга. Изменения в одном таком компоненте не вызывают волнового эффекта и не требуют изменений в других.
Противоположностью ортогональности является сильное сцепление (high coupling), когда компоненты тесно переплетены и любое изменение в одном влечёт за собой каскад правок в других.
Когда компоненты изолированы друг от друга, вы можете быть уверены, что изменение одного из них не затронет остальные. Неортогональные системы гораздо сложнее изменять и контролировать. Если составляющие системы отличаются высокой степенью взаимозависимости, то устранить неисправность на локальном уровне часто невозможно — приходится перекапывать огромные пласты кода. И что хуже — растёт «цена понимания»: прежде чем внести маленькое улучшение, нужно держать в голове слишком много деталей.
Забавно, что современное разделение на фронтенд, бэкенд и DevOps само по себе сделало системы эволюционно более ортогональными. Изменения в клиентской части, как правило, не влияют на серверную логику, а правки в бэкенд-коде могут не затрагивать базу данных или инфраструктуру развёртывания. Когда писалась книга, такого разделения на отдельные системы и специальности не было. Теперь веб-приложение можно заменить на нативное мобильное, не переписывая серверный и инфраструктурный код.
Конечно, это идеальная картина: в реальности контракты «текут», а границы ломаются. Но сам вектор развития индустрии — в сторону модульности, границ и договорённостей.
Трассировка и прототипирование: идеи vs реальность
То, что авторы называют «трассировкой», по сути, является stage- или UAT-сборками (User Acceptance Testing), которые прочно вошли в жизнь современной разработки. Это промежуточные среды, где код проверяется перед выпуском в production. Сегодня это ещё и способ управлять риском: не столько «проверить код», сколько проверить систему целиком — интеграции, данные, инфраструктуру, наблюдаемость.
С прототипированием всё не так однозначно. Сама идея очевидна: создать упрощённую, возможно, «грязную» версию системы, чтобы проверить гипотезу или показать идею. Но скажите, когда в последний раз организация тратила деньги на создание прототипа, а потом спокойно выбрасывала его в мусорную корзину?
На практике прототип сегодня редко бывает прототипом в чистом виде. Он может быть отдельной функцией или фичей (то, что в Экстремальном программировании называли Spike — термин, который, кажется, безнадёжно забыт), но не целого продукта или приложения. В современном IT прототип — это часто интерактивный дизайн в Figma, а всё, что делают разработчики, — это уже MVP (Minimum Viable Product). Как только идея находит отклик и привлекает инвестиции, прототип, который мог быть сделан на скорую руку, тут же становится фундаментом для будущего продукта. Да, так оно и есть. Поэтому я эмпирически отношусь к каждому своему прототипу как к потенциальному MVP и держу в голове, что именно этот «ящик» может лечь в основу всей будущей конструкции.
Авторы книги предупреждают:
Прежде чем приступить к любому прототипированию на основе кода, убедитесь, что все заинтересованные лица ясно отдают себе отчет, что вы собираетесь написать одноразовый код
Жаль только, что вне академических кругов, в мире коммерческого программирования, это почти никогда не работает. За 15 лет карьеры я ни разу не видел, чтобы прототип целостной программы оставался одноразовым.
А всё потому, что до недавнего времени цена создания большого прототипа была слишком высока. Теперь, вместе с появлением AI-инструментов вроде GitHub Copilot, Bolt.new и возможностей Figma Make, прототипы, возможно, снова станут действительно прототипами. Ведь генерация отдельного рабочего приложения-демо — это теперь вопрос пары сотен токенов и нескольких минут. Правда, у этого есть обратная сторона: если «собрать демо» стало слишком легко, то ещё важнее становится дисциплина границ — что именно мы выкидываем, а что переводим в «продуктовый» режим с тестами, наблюдаемостью и сопровождением.
Предметно-ориентированное программирование: пророчество, ставшее реальностью
Забавно читать о предметно-ориентированных языках (DSL) в эпоху промпт-ориентированного программирования (Prompt-Oriented Programming) и агентной инженерии (Agentic Engineering). По сути, это движение к одной и той же цели — языку самого высокого уровня. Им стал человеческий язык. Пусть пока не идеально и не детерминировано (хотя, возможно, в этой новой эре детерминированность и не нужна), но результаты уже впечатляют. Значительная часть этого веб-сайта создана с помощью человеческого разговорного языка, порой даже эмоционально окрашенного, с матюками и ругательствами.
Примеры из книги с Cucumber и RSpec сейчас кажутся архаикой. Насколько эти инструменты актуальны сегодня — вопрос открытый. Возможно, они стали промежуточным звеном в истории, мостом между кодом и языком, который мы сейчас переходим с помощью AI.
И, возможно, именно поэтому книга читается не как «инструкция», а как снимок того, как индустрия училась формулировать мысли о качестве.
В целом, книга прекрасно подходит именно для новичков в профессии. Читать некоторые главы про систему контроля версий, выбор редактора кода или оценку задач через декомпозицию спустя десятилетие коммерческого опыта, как минимум, неинтересно. Хотя, признаюсь, я не виртуозно владею Vim и в WebStorm многое делаю с помощью мыши, а не горячих клавиш. И уж точно не гурман UNIX-команд. Иногда это вопрос стиля и привычки.
Если бы у меня отобрали все IDE, я, конечно, выучил бы пару-тройку команд до автоматизма, но будем откровенны: от моей первой IDE Turbo Pascal, через Borland, Eclipse, IntelliJ IDEA, WebStorm и до Cursor Glow — задача этих инструментов на протяжении всей моей карьеры была в том, чтобы сделать взаимодействие с кодом более плавным, приятным и человечным.
Дэвид и Эндрю пытаются в книге коснуться всех насущных тем разработки ПО, пускай и поверхностно, но не без O-большого, асимптотической сложности, алгоритмов и TDD, при этом везде ссылаясь на более фундаментальные труды. Должна ли эта книга быть на полке каждого программиста?
«Программист-прагматик» — это не столько сборник готовых рецептов, сколько коллекция принципов и ментальных моделей. Она учит мыслить об архитектуре, качестве и процессе разработки. И в этом её непреходящая ценность, которая переживёт ещё не одну технологическую революцию. Это книга-компас, а не карта с размеченными тропинками. А компас, как известно, полезен в любом путешествии, даже если ландшафт вокруг постоянно меняется.