Хотел бы я найти источник, но я где-то читал, что средний срок пребывания разработчика программного обеспечения в наши дни составляет 2,5 года. Частично это связано с тем, что большинство компаний довольно плохо справляются с сохранением конкурентоспособности вознаграждения, и лучшая стратегия для повышения вашей зарплаты — это смена места работы.

Еще один фактор в том, что 2,5 года — это как раз достаточно времени, чтобы превратить вашу работу в разочаровывающий беспорядок.

  • Первые три месяца проекта — дни салата. Кодирование течет свободно. Небо это предел. Вы продолжаете придумывать лучшие идеи, что можно добавить. Это взрыв.
  • Тогда вы попадаете в реальность. Есть вовлеченные пользователи. Они делают то, о чем вы не подумали. Вы узнаете реальные требования. Вы проводите следующие три месяца, взламывая его, чтобы покрыть все эти маленькие угловые случаи, которые вышли из дерева. Ковбои по-прежнему спешат.
  • Примерно через год вы построили что-то, что стабилизировалось в производстве. В их гениальности руководство вытягивает большую часть ресурсов из этого проекта, чтобы работать над следующей блестящей вещью. Если вы были основным разработчиком этого проекта, обслуживание остается за вами. Вы начинаете работать над следующей вещью, но обслуживание старого проекта не покидает вас. Вспеньте, промойте, повторите.
  • В 2,5 года у вас уже есть два вспомогательных проекта, отнимающих ваше время, и, поскольку вы так перегружены работой, новые люди, которые заменяют других, которые сбежали, начинают работать над новыми вещами. Вы остались позади. Все, над чем вы работаете, — это большой шар спагетти. Это время выгорания.
  • И тут звонит рекрутер и предлагает гигантскую прибавку к зарплате. Вы переходите в следующую компанию и начинаете тот же цикл. А вы пишете статьи о том, что чистый код и SOLID — пустая трата времени.

Как менеджер, я не возражаю против того, чтобы в начале чьей-то карьеры в резюме было указано несколько рабочих мест. Вот как разработчики заботятся о своих семьях. Но долгая карьера в 2–3 года — это тревожный сигнал. Возможно, этот застройщик постоянно убегает из горящего здания, где они зажгли огонь. Не пускайте поджигателей в свою команду.

Содержите свой код в чистоте и порядке

Способ избежать этого цикла и удержать ваших разработчиков достаточно долго, чтобы они приобрели реальный опыт в предметной области, — это никогда не создавать этот беспорядок в первую очередь. Чистый, хорошо организованный, хорошо спроектированный код с полным набором автоматических тестов намного легче поддерживать. Починить что-то — не такой уж кошмар. Вы не живете в страхе перед правилом гончарного амбара (вы его нарушаете, вы его купили). Вы не боитесь рефакторинга для удобства чтения или упрощения.

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

Никто не хочет работать в беспорядке.

Это на управлении. Это все их вина. Слишком много менеджеров продвигают ковбойский подход к кодированию. Просто сделайте что-нибудь и перекиньте стену, чтобы мы могли перейти к следующему делу. Нет понятия профессионализма или гордости за свою работу. Они любители; они просто ответственны.

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