В то время как сторонники современных гибких методологий разработки выдумывают все новые и новые практики, их оппоненты также не стоят на месте. На фоне разнообразных XDD (FDD — Feature Driven Development, TDD — Test Driven Development, BDD — Behavior Driven Development, ATDD — Acceptance Test Driven Development) они сформулировали свою методологию — JSDD (Job Safety Driven Development). Кому интересны детали, добро пожаловать под кат.
Что же такое Job Safety Driven Development?
Любая методология должна строиться на некоторых принципах и ценностях. Дальше из них получаются конкретные практики, а уже потом инструменты для эффективного следования практикам. Вот давайте с принципов и начнем…
Самый главный принцип JSDD — стабильная работа и надежный источник пропитания для разработчика. В наше нестабильное время технологии развиваются очень быстро и разработчик рискует остаться за бортом, упустив момент и отстав от рынка. А ведь у многих разработчиков есть семьи, которые надо кормить. Кто-то уже чует наступление возрастного барьера, после которого компании неохотно берут на работу некогда перспективного специалиста.
А еще и наступление Agile подходов со всех сторон лишь усугубляет положение. Надо быть общительным, социальным и прогрессивным, внедрять новые практики и подходы. А что если не получится? Что если вы не сможете больше быть высокоуровневым профессионалом на фоне остальных? Эти вопросы порождают страх и беспокойство, являясь толчком к конкретным действиям.
Сторонники JSDD стараются приложить максимум усилий, чтобы стабильность их положения ничего не могло поколебать.
Практики Job Safety Driven Development
Ниже представлены практики, которые помогают адептам JSDD добиваться своих целей.
Непрозрачное планирование — планирование задач должно быть как можно более коротким. Все детали и обсуждения откладываются на потом, в личное общение. Дизайн сессии не проводятся вовсе, считается что профессионал сможет сам придумать максимально подходящую реализацию под задачу, исходя из бизнес-требований. Эта практика помогает собирать доменные знания о продукте, архитектуре и дизайне исключительно в головах разработчиков. При этом ни один из них не будет обладать знаниями по чужим модулям, а это делает их труднозаменимыми на проекте.
Антирефакторинг — самая главная задача заключается в работоспособности кода, а не его понятности и простоте. Поэтому как только решение начинает работать, разработчик должен переходить к следующей задаче. Эта практика должна обеспечить возможность разбираться в коде только самому автору, что сильно уменьшает вероятность его увольнения.
Фреймворконенавистничество — не стоит использовать популярные фреймворки и библиотеки, гораздо лучше написать свое решение под конкретные задачи. Ведь потом надо поддерживать продукт и возможно на эту роль понадобятся новые более дешевые разработчики. Куда проще найти на рынке разработчика со знанием популярных фреймворков, чем способных разобраться с самописными. А это значит, что вы надолго обеспечены работой.
Незыблемость решений — архитектурные решения, которые принимаются на проекте, должны быть как можно менее подвержены изменениям. Они должны решать строго текущие задачи и ни на шаг больше. Любые изменения в будущем должны стоить дорого и сделать их без участия автора должно быть чрезвычайно сложно. Эта практика отлично маскируется под Agile практику «эволюционирущей архитектуры» и отказ от BDUP (Big Design Up Front). А это значит, что ее легко внедрить даже при применении «Agile подходов».
Отказ от тестирования кода — мы же профессионалы и так пишем работающий код. На тесты никто не выделяет времени, заказчик не будет за них платить и для тестирования есть тестировщики. Эти доводы и уверенность в собственном мнении легко позволят убедить всех остальных в вашей правоте. Отказ от тестирования на уровне модулей и их интеграции позволяет разрушить тот и без того хрупкий мостик, который мог бы помочь разобраться в существующем коде и внести в него изменения другим разработчикам. Теперь без вас уж точно не обойтись!
Индивидуальная работа — нет времени на то, чтобы сидеть и работать в паре или организовывать другие групповые активности. Надо быстрее делать рабочий код, нам за это платят деньги. Эта практика позволяет вам не делиться своими знаниями и навыками с другими, что дает вам возможность оставаться на том же уровне относительно коллег по команде. Также практика способствует узкопрофильности знаний в разных областях продукта и тем самым укрепляет вашу уверенность в завтрашнем дне.
Велосипедостроение — как только вы видите возможность реализовать где-то что-то с нуля, не пользуясь общеизвестными инструментами и подходами, вы не должны пропустить эту возможность. Помимо преимуществ от похожей практики фреймворконенавистничества вы существенно растягиваете сроки проекта. А чем дольше длится проект, тем большее влияние оказывают ваши остальные практики, делая ваше увольнение практически катастрофой для проекта.
Скорострельность — чтобы ваши аргументы были более вескими и другие практики внедрялись быстрее, вы должны уметь быстро реализовывать поставленные задачи. Естественно без заморочек на качество кода и прочие активности. Включаете поток сознания и вперед! Тогда у вас появится возможность упрекать остальных в медлительности и противостоять внедрению новых практик и подходов, а значит убережет ваше стабильное положение от посягательств.
Есть много других интересных практик в этой замечательной методологии. Вы наверняка сталкивались с многими из них в жизни и я буду рад увидеть их описание в комментариях. Также я специально пропустил секцию инструментов, чтобы дать поработать вашей фантазии…
Заключение
Если вы являетесь одним из сторонников Agile, то должны быть готовы к борьбе с альтернативными методологиями, одна из которых представлена в статье. В вашем арсенале обязаны быть статический анализ кода, ревью кода, парное программирование, простой дизайн и архитектура, твердое понимание процессов и принципов гибкой разработки. Только в этом случае вам удастся вычислить адепта JSDD, а потом либо привлечь его на свою сторону либо суметь избавиться от него. Иначе ваше внедрение Agile может остановиться, не успев начаться…
Автор: xpinjection
