Дж. Х. Рейнвотер «Как пасти котов»: по ту сторону разработки



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

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

    Определение требований и спецификации


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

    За смешение двух ролей часто ратуют разработчики, которые по нашей классификации относятся к породе ковбоев – они тоскуют по «гаражным» временам, когда крошечные команды делали весь продукт от и до и потребности во внешнем взаимодействии не возникало. Автор спешит развеять все иллюзии на этот счет: в современных условиях взаимодействие между техническими и не-техническими группами должно происходить регулярно, в течение всего жизненного цикла приложения. Первые встречи проходят за совместной подготовкой спецификаций. Руководитель разработки (или один из ведущих разработчиков) ознакомляется с описанием продукта, исключает все то, что представляется ему неоправданным или нереалистичным с технической точки зрения и забирает итоговый план, чтобы перевести его на язык технологий. Далее группы время от времени встречаются, чтобы «сверить часы» и убедиться, что реализация не слишком отклоняется от первоначального замысла.

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

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

    Прежде чем соглашаться брать новую функцию в работу, следует задать себе ряд вопросов:

    • Какое влияние предполагаемое изменение окажет на архитектуру системы в краткосрочной и долгосрочной перспективе?
    • Как предполагаемое изменение подействует на сетевую инфраструктуру, в которой будет проводиться?
    • Как предполагаемое изменение повлияет на способность пользователя эффективно и продуктивно взаимодействовать с данным продуктом?
    • Какое влияние предполагаемое изменение окажет на действия сотрудников, которым придется с ним работать вплотную – реализовать, сопровождать?

    Подобные размышления помогут выявить подводные камни и зададут общие направления для диалога с другими группами.

    Проектирование


    Когда требования утверждены и благословлены всеми участниками процесса, приходит время того, что Рейнвотер называет координацией архитектурных и проектных решений. Иными словами, техлиду нужно обрисовать ту систему, которая будет выполнять оговоренные на этапе спецификаций функции, и продумать компоненты, отвечающие за конкретные процедуры. Критически важно действовать именно в таком порядке:
    Сначала архитектура, затем компоненты.

    Автор подчеркивает это многократно, потому что в эту западню попадаются многие разработчики, еще не знакомые с искусством проектирования продукта. Кажется логичным взять список требований, прописать для каждого нужные компоненты и считать продукт простой их совокупностью. Но в реальности этот механистический подход порождает ригидных, хаотично организованных чудовищ, которые высасывают все соки из разработчиков, занятых поддержкой проекта. Чтобы этого избежать, нужно идти другим путем, от целого к частному. У вас уже есть общее функциональное видение продукта с перспективой развития – нужно «отзеркалить» его в общем техническом видении с перспективой развития, то есть архитектуре.

    Построение архитектуры

    Если прибегнуть к избитой метафоре, архитектура – это скелет продукта, на который потом наращивается плоть из частных решений по реализации процедур. Немного оживим эту метафору, добавив уточнение: скелет должен быть заточен под то, чтобы отращивать новые конечности. Два основных требования к архитектуре – это четкая логические организация компонентов и гибкость, которая позволит добавлять новые по мере разрастания проекта.

    Данный этап в разработке, пожалуй, можно назвать наиболее ответственным – специалисты утверждают, что именно пренебрежение вопросами архитектуры чаще всего приводит к краху проектов. В числе распространенных причин неудачи они называют:
    • Непродуманность, неряшливую организацию (или полное ее отсутствие).
    • Излишнюю жесткость и прямолинейность системы, препятствующие ее расширению в соответствии с коммерческими потребностями.
    • Излишнюю взаимосвязанность компонентов, недостаток гибкости в конфигурации.
    • Излишнюю сложность на верхних уровнях, затрудняющую модификацию базовых компонентов.

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

    К окончанию работы на данном этапе у вас должны быть готовы ответы на следующие вопросы:

    • Как будет проходить взаимодействие пользователей с системой?
    • Какие компоненты требуется собрать для того, чтобы обеспечить функционирование системы?
    • Каков будет механизм взаимодействия компонентов, обеспечивающий функционирование системы?
    • Какие технологии в наибольшей степени приспособлены для создания данного приложения?
    • Как предполагается поставить систему клиенту?

    Планирование компонентов

    Когда общий фреймворк разработан, приходит время углубиться в частности и вживить в органическую структуру актуальные на текущий момент компоненты. Главная сложность здесь – выдержать нужную меру связанности. С одной стороны, не следует рассматривать компоненты как строго изолированные контейнеры для конкретных наборов операций – скорее как систему органов, каждый из которых сообщается с другими, но выполняет свои функции. Вместе с тем, нужно избегать сильной взаимозависимости между областями, в результате которой модификация одного компонента потянет за собой целую цепочку изменений, а то и неполадок по всей системе.

    Стек технологий был в общих чертах намечен на прошлом этапе, теперь вам предстоит осмыслить его во всех подробностях. В выборе языка, библиотек и как далее имеет смысл руководствоваться не только профессиональными, но и строго прагматическими мотивами. Скажем, будет ли у вас хватать компетентного персонала для сопровождения систем, построенных на основе передовых, редких или сложных технологий? И наоборот, если вы отдаете предпочтение технологиям постарше, насколько это перспективно – будут ли они оставаться рабочими на протяжении всего жизненного цикла, не начнут ли возникать проблемы с совместимостью? С такой же тщательностью следует обдумать и все вопросы, связанные с аппаратными решениями, созданию, конфигурации и сопровождению инфраструктуры.

    Разработка и контроль качества


    Итак, планирование наконец закончено и проект уходит в работу – начинается собственно разработка приложения. Роль технического лидера в этом процессе заключается в основном в наблюдении, чтобы все шло в соответствии со сроками и стандартами; напрямую в создание кода он вовлекается, как правило, только при форс-мажорных ситуациях. По большей же части, руководитель выполняет функции кодовой полиции, то есть проводит регулярные критические обзоры кода, чтобы удостовериться, что в них ничего не идет вразрез с архитектурным фреймворком и базовыми принципами программирования.

    В ходе проверок технический лидер может сталкиваться с разными типами ошибок. Рейнвотер сосредотачивает внимание читателя на двух разновидностях:

    • Нарушение стандартов. Сюда входит стилистика, именование, комментирование – в общем, все, что помогает стороннему лицу разобраться, что происходит в коде, а также небрежности в духе нескольких точек выхода или ненавистных операторов GoTo. Необходимо добиваться, чтобы все участники процесса разработки говорили на одном языке – это делает код прозрачным и позволяет быстрее распутывать ошибочные ходы. Названия параметров и переменных должны ясно указывать на их содержание, комментарии – помогать проследить код мысли разработчика, обосновывать его решения. К слову, если кто-то из команды упорно отказывается комментировать код, стоит задуматься почему. Нередко это просто лень или особенность мышления, но в некоторых случаях может оказаться симптомом того, что сотрудник сам толком не понимает, что он делает – запутался или просто копирует куски чужого кода на авось. Так же внимательно нужно наблюдать за теми, кто регулярно пренебрегает обработкой ошибкой: неумение выявлять источники багов – серьезный недочет для разработчика.
    • Слабая связность и сильная взаимозависимость — две области нарушений, которые допустимо рассматривать совместно, поскольку наличие одного предполагает наличие другого. Тут все фактически упирается в степень ветвления и его тип. При высокой степени ветвления по выходу функционирование процедуры предполагает обращение к множеству других процедур, что, естественно, нежелательно. Ветвление по входу, напротив, оказывает положительное воздействие, так как свидетельствует о строгой инкапсуляции. Если возникают сомнения при анализе кода по этим параметрам, неплохо бы составить диаграмму блоков с размеченной иерархией объектов. Она сразу обнажит все, что вам нужно знать: можно ли проследить родословную объекта, есть ли логика в расстановке стрелок или все выглядит сумбурно.

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

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

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

    Тестирование


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

    В остальном важно для обеспечения хорошего качества проверки необходимо позаботиться о том, чтобы продукт не варился все время в одной и той же группе – в идеале, его следует тестировать «на стороне». Если в компании несколько команд разработчиков, возможно, имеет смысл договориться с другими руководителями о создании смешанной группы.
    Цифровые Экосистемы
    131,17
    Переводим бизнес в цифру
    Поделиться публикацией

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое