Если ты в чем-то и виноват, Билли, так в том, что не встретил хороших людей…

(c) к/ф Человека с бульвара Капуцинов

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

Однажды фраза из к/ф «Человек с бульвара Капуцинов» навела меня на размышления о моем пути в ИТ-профессии. В отличие от Билли, мне повезло: я не просто встретил хороших людей, а прочитал умные книги, которые эти люди написали. Когда я вспоминаю годы, когда только становился программистом, отчётливо вижу те издания, которые заложили мой будущий фундамент. Это были не просто инструкции, а встречи с людьми, которые изменили мой взгляд на программирование и управление. Удивительно, насколько сильно несколько толковых книг могут повлиять на судьбу человека!

Refactoring Мартина Фаулера научил меня профессиональному отношению к коду и привычке доводить детали до совершенства. Не писать идеально с первого раза невозможно. Но постоянно улучшать, рефакторить, делать код чище и понятнее. Это не про перфекционизм, а про уважение к тем, кто будет читать этот код завтра. Фаулер однажды сказал: «I am not a good engineer, I am an engineer with good habits«. Эта фраза стала для меня ключевой. Я понял, что хороший код это не про талант, а про привычки. Про то, что ты делаешь каждый день, даже когда никто не смотрит.

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

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

Эти книги стали для меня чем-то большим, чем просто инструкции. Это тот багаж, который помогает принимать решения и как разработчику, и как руководителю. Когда я перестал писать код (больше десяти лет назад) и перешел к управлению компанией, я не забыл эти принципы. Я просто изменил способ их применять. Моя задача теперь не в том, чтобы ревьюить каждую строчку, а в том, чтобы создать среду, которая воспитывает качество. Среду, где привычки Фаулера становятся естественной частью работы команды. Кстати, все эти книги хранились в моем офисе. Но за последний год первые две исчезли безвозвратно. Дай бог, кто-то еще встретил «хороших людей».

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

Я не сижу и не читаю каждый pull request. У меня нет на это времени, да и не в этом моя роль. Вместо этого я задаю вопросы. Простые, но важные вопросы, которые заставляют команду думать о качестве.

«Сколько тестов вы написали для этой фичи? Покрытие выше 80%?» Этот вопрос скорее не про контроль, а про то, чтобы разработчики сами задумались: а как проверить, что это работает? А что будет, если завтра кто-то изменит этот код?

«Новичок придет через месяц. Как он поймет, что делает этот модуль? Где документация?» Вопрос про долгосрочность. Код живет годами. Люди, которые его писали, могут уйти. Но код останется. И кто-то должен его понять.

«Когда последний раз вы рефакторили этот модуль? Он не стал сложнее за последний год?» Вопрос про технический долг. Он накапливается незаметно. Один раз не почистили, второй, третий. И вот уже модуль превратился в лабиринт, в котором страшно что-то менять.

«Если завтра ты уйдешь в отпуск, кто сможет поддержать этот код?» Вопрос про знание кодовой базы. Если код понятен только одному человеку, это риск для компании. Знания должны распределяться.

Эти вопросы я задаю время от времени не только тим лидам, но и любому спецу, которого я встречаю на кухне. Но регулярно! И команда знает: качество кода это не опция, это часть культуры в моей компании.

Проблема больших компаний: почему новички пишут плохой код

В той статье автор объясняет, почему в больших компаниях появляется плохой код. Высокая текучка: средний сотрудник работает один-два года. Большинство изменений вносят «новички» — люди, которые пришли в компанию, перешли к этой кодовой базе или даже на новый язык программирования за последние шесть месяцев. Ветераны перегружены. Они могут проводить ревью и отлавливать очевидные проблемы, но у них не хватает времени на личное ревью каждого изменения. А если тратить всё время на ревью, компания накажет за недостаточно большой личный вклад. Экспертиза не накапливается. Разработчиков переводят на другие сервисы, и они либо выполняют обязанности «ветерана» на добровольной основе, либо становятся относительными новичками в новой системе. Но это не приговор для всех, ведь в небольшой компании можно выстроить процессы иначе, и я стараюсь это делать.

Преимущества небольшой компании

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

Например, в моей компании используется подход documentation as code: документация живет рядом с кодом, версионируется вместе с ним, обновляется при каждом изменении. Такая структура документации помогает находить связи между разными частями системы, отвечать на простые вопросы новичков, не отвлекая старожилов. Эдакая живая база знаний вместо разрозненных файлов. Замечу, знания не теряются, когда уходит какой-то человек. Они остаются в коде, в документации, в процессах. И новые люди могут их подхватить.

Ветераны как носители культуры

В моей компании есть человек, которого я называю Employee Number 1. Миша. Он написал первые строчки наших продуктов, когда-то 10 лет назад. Он же заложил фундамент и новой архитектуры, после того как я осознал, что первое поколение продуктов пора переписать с нуля. И знаете что? Он по-прежнему пишет код. Более десяти лет. У него нет подчиненных. Он ни на что не отвлекается, редко ходит на митинги. Он просто делает то, что умеет лучше всех: создает технологические решения. И его присутствие в офисе вдохновляет молодых сотрудников. Ведь нет такой задачи, которую Миша не может решить. Покряхтит немножко, бороду погладит, и вуаля. Казалось бы невозможная задача уже решена. У нас с Мишей, кстати, много общего: он тоже работает стоя и любит подтягиваться на турнике, мы оба свободно говорим по-немецки и любим в лифте перекинуться яркими словечками. Миша несёт культурный код компании и уже одним своим присутствием в офисе вдохновляет молодых сотрудников на новые свершения.

Внутренняя академия: выращиваем своих

Руководители направления разработки работают в моей компании уже больше десяти лет. Два staff-инженера прошли путь от джуна до текущего уровня зрелости. Это не случайность. Это результат долгосрочной работы. Когда я вместе с HR-директором посмотрел вглубь существующего состава, удивился, кто в команде играет «в основе». Оказалось, что большинство ключевых людей выросли внутри компании. Старички передают знания новичкам и выращивают их. Не через формальные процессы и документацию, хотя и это важно. А через ежедневную работу: код-ревью, обсуждения архитектуры, совместное решение сложных задач. Когда рядом работает человек, который видел, как система эволюционировала, это бесценно.

Почему это получается? Пять принципов, которые я использую:

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

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

Проекты «в бою» — постепенное увеличение сложности задач и роли в продукте. Не искусственные учебные проекты, а реальная работа над реальным продуктом.

Поддерживающая среда — я даю людям ошибаться, экспериментировать и проявлять инициативу. Ошибка — это не провал, это урок.

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

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

Почему офис важен для качества

Я люблю повторять своим ребятам: «Я знаю 10 верных способов разрушить хорошую команду, но ни одного верного, чтобы её гарантированно создать». Том ДеМарко в Peopleware писал об этом: достаточно физически и организационно разъединить людей и лишить их нормальной коммуникации, и команда начнёт распадаться. Полная удалёнка — зло для командной работы. Скажу честно: удалёнка мне не нравится от слова совсем. Но после ковида удаленка прочно вошла в соцпакет, и вернуть всех обратно в офис оказалось непросто. Не все рады настойчивым приглашениям: кому-то комфортнее дома, кто-то экономит время на дорогу. Но я много усилий трачу, чтобы вернуть людей в офис, и терпеливо убеждаю: «Чем больше времени проводим вместе, тем быстрее двигаемся». Постепенно процесс идет, и ребята возвращаются в офис.

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

Философия: среда воспитывает

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

Вместо заключения

Я не знаю универсального рецепта, как гарантированно создать команду, которая пишет хороший код. Но я знаю, что это возможно! Хочется верить, что в небольшой компании, где есть понимание ценности качества и готовность инвестировать в долгосрочную экспертизу, это работает. Мартин Фаулер говорил про привычки, а не про талант. Макаренко говорил про среду, а не про педагога. ДеМарко говорил про людей, а не про процессы. Может быть, в этом и есть секрет: не искать волшебную формулу, а методично создавать правильную среду. Задавать правильные вопросы. Инвестировать в людей. Думать на десятилетие вперед, а не на квартал. И тогда качественный код станет не исключением, а естественным результатом работы правильной команды в правильной среде.