Team-Management

Представьте себе: сезон оценки производительности, и ваш менеджер скользит цветным дашбордом по столу. «Ну, Джонсон, ваша цикломатическая сложность зашкаливает, а покрытие кода едва достигает 60%. Это повлияет на ваш бонус в этом году». Звучит знакомо? Добро пожаловать в новый прекрасный мир, где алгоритмы могут решать, можете ли вы позволить себе дополнительную гуакамоле за обедом. Вопрос о том, должны ли метрики качества кода определять компенсацию разработчиков, подобен вопросу о том, должен ли термометр решать, здоровы ли вы....

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

Догадаюсь — когда вы прочитали этот заголовок, вы, вероятно, подумали, что я собираюсь посоветовать вам игнорировать стандарты кодирования, пропускать обзоры кода или развертывать изменения непосредственно в продакшн в пятницу днем. Сюжетный поворот: на самом деле я говорю о другом виде нарушения правил, который является гораздо более радикальным на большинстве рабочих мест — дерзком поступке делать перерывы. Я знаю, знаю. Революционные идеи, правда? Но прежде чем закрыть эту вкладку и вернуться к 47-му часу отладки утечки памяти подряд, выслушайте меня....

Представьте: вы сидите в конференц-зале и слушаете консультанта в идеально отглаженных брюках, объясняющего, как их «революционная» методология разработки программного обеспечения решит все ваши проблемы. У них есть диаграммы, аббревиатуры и, конечно же, внушительный счёт. Знакомо? Добро пожаловать в чудесный мир проповедников процессов, где каждый продаёт святой грааль разработки программного обеспечения, и, спойлер, его не существует. Вот неудобная правда, из-за которой сторонники процессов схватятся за свои методические руководства: не существует идеального процесса разработки программного обеспечения....

Пора признать: Agile-манифест не просто устарел — он стал настоящим пережитком прошлого. Это как тот коллега, который до сих пор настаивает на использовании Internet Explorer «потому что он нормально работает». Мы цепляемся за документ, которому уже 24 года, как за священный грааль разработки программного обеспечения. Но вот неудобная правда: Agile стал тем, с чем стремился бороться. Не поймите меня неправильно — я не собираюсь выбрасывать ребёнка вместе с bathwater. Оригинальный Agile-манифест был революционным для своего времени, освобождая от жёстких оков каскадной модели....