Записки архитектора. Управление масштабными проектами, в которых не создаётся нового функционала

Думаю, все любят разрабатывать новый функционал приложений, сервисов, микросервисов и пр. И наверное, мало кто любит заниматься инфраструктурными работами. Например, портировать код на другую операционную систему или портировать код на другую микропроцессорную архитектуру, или же «отвязывать» вычислительную логику от графических интерфейсов (если вдруг приложение долгое время развивалось так, что отделение вычислений от графики никого не заботило)…

Тем не менее, инфраструктурные проекты тоже важны, и время от времени их приходится делать.

Мне довелось поработать над несколькими такими проектами в разных компаниях. И это был приятный опыт, ибо все эти проекты прошли довольно гладко и завершились успешно.

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

В этой статье мы, во-первых, разберём клинический пример, а во-вторых, поговорим про эффективные практики реализации масштабных инфраструктурных проектов.

Инфраструктурные проекты наиболее интересны в контексте больших – даже, пожалуй, очень больших! – приложений. Допустим, размера Фотошопа или какого-нибудь известного на весь мир компилятора. В этом случае в разработке приложения задействовано много команд, у которых, как правило, есть общий код. При этом код, разрабатываемый одной командой, зависит от кода, разрабатываемого другой командой, через вызовы функций или схожие низкоуровневые интерфейсы. На контрасте с «тяжёлыми» приложениями, инфраструктурные улучшения, например, небольшого web-сервиса размером в десятки тысяч строк проблем обычно не вызывают. Ибо над таким сервисом работает, скорее всего, одна команда. Причём у сервиса, вероятно, своя независимая вычислительная инфраструктура (допустим, пул виртуальных машин). И для других сервисов этот конкретный web-сервис доступен через очень высокоуровневый интерфейс (допустим, REST). Поэтому потребители сервиса даже не заметят, что внутри него происходят радикальные изменения, вроде портирования с Windows на Linux. Так что координации ни с какими другими командами, скорее всего, не потребуется.

Так что условимся, что мы здесь говорим про очень большие приложения – состоящие из миллионов строк кода. Также для определённости будем считать, что решается задача портирования приложения с одной операционной системы на другую: с Windows на Linux. Это ровно та ситуация, которая имеет отношение к обещанному мной «клиническому» примеру. Однако сказанное ниже будет справедливо и для многих других типов задач. И раз уж говорим о портировании с Windows на Linux, то условимся считать, что код портируемого приложения написан на довольно низкоуровневом языке, типа C++. Для совсем высокоуровневых языков конкретно задача портирования с одной операционки на другую выглядит менее интересно.

Я всегда считал, что проекты портирования кода на другую операционную систему или на другую аппаратную архитектуру – это относительно простые проекты. Мне самому посчастливилось участвовать в нескольких подобных проектах. И каждый из них только подтверждал тезис, что «портирование – это просто». Да, объем кода может быть большим; да, проект может быть относительно долгим. Но при этом довольно прямолинейным! В одном из проектов, в которых я участвовал, портировалось приложение «весом» более 10 миллионов строк кода. Однако даже такие объемы не кажутся проблемой, когда речь идёт о портировании. Поэтому я очень удивился, когда столкнулся с тем, что в весьма крупной компании годами не могут завершить портирование своего ключевого приложения.

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

Теперь к обещанному «клиническому» примеру. Приложение, которое нужно было портировать, имело вполне себе вменяемые размеры, по моим меркам. Сильно меньше 10 млн строк кода, но всё-таки больше миллиона. Как уже было сказано, портировать нужно было с Windows на Linux. Без графики, что важно, ибо портирование графических интерфейсов добавляет дополнительных сложностей, а там даже этих сложностей не было.

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

Может показаться, что если каждый сотрудник участвует не более, чем в одном проекте, то это очень даже хорошо. В некоторых условиях – так и есть. Человек не распыляется, полностью фокусируется на одной-единственной задаче…

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

Но вернёмся к примеру… Небольшому количеству людей поручили выполнить весь проект портирования, не занимаясь при этом ничем другим. Однако перед всеми остальными людьми, которые работали на той же кодовой базе и которых было в десятки раз больше, такая задача не стояла. То есть они «пилили» какие-то другие проекты. И в их интерес портирование кода на Linux не входило совершенно. Они занимались исключительно новым функционалом и продолжали писать код для Windows. Соответственно, получилась гонка: пока кто-то портирует конкретный модуль на Linux, кто-то другой льёт в этот модуль код, который подходит только для Windows. Через несколько лет – лет, Карл! – команда, занимавшаяся портированием, эту гонку всё-таки выиграла. В тестировании появилась полная рабочая сборка (билд – build) кода под Linux, и никто уже не мог влить код, который собирался бы только под Windows. Это сломало бы линуксовый билд. Но это был пока что только билд… А дальше надо было работать над стабильностью этого билда: чтобы функциональные тесты не падали и приложение, собранное под Linux, выдавало корректные результаты. А потом ещё и над производительностью надо было работать. И – сюрприз, сюрприз! – обоими этими направлениями работ снова занималась небольшая выделенная команда. И это опять получилась история на годы. Я даже не знаю, была ли она всё-таки закончена. Последний раз, когда я что-то слышал об этом портировании, оно длилось суммарно уже лет пять и было далеко от окончания. Таким образом, относительно простая по своей сути затея превратилась в многолетнюю эпопею с нерациональной тратой ресурсов. Ибо «гонки» разработчиков на общем коде приводят к дополнительной работе, которой можно избежать.

Хорошо: как не следует реализовывать масштабные проекты, мы увидели. А как следует? Приведу здесь сценарий, по которому на моей практике реализовывались успешные масштабные проекты. Для определённости снова будем говорить про портирование кода с Windows на Linux, чтобы была связь с приведённым примером. Однако на общие принципы этого сценария можно опираться и при решении многих других задач.

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

2. Высокий менеджмент устанавливает сроки окончания работ. Допустим, год. Кстати, такой срок был выбран в самом первом проекте портирования, в котором я участвовал. Размер кодовой базы превышал 10 млн. строк; на каждого разработчика приходилось примерно 40 000 строк. Особой спешки не было. Предполагалось, что работа по портированию должна пройти в «фоновом режиме», не сильно отвлекая людей от проектов по созданию нового функционала

3. Успешное завершение портирования должно попасть в годовые цели каждого привлечённого к портированию сотрудника. Каждого – от высоких менеджеров до стажёров. Понятно, что конкретные формулировки целей будут зависеть от должностей сотрудников. Например, директор по разработке может получить цель обеспечить портирование приложения/продукта целиком, а стажёр может получить цель портировать конкретный модуль кода

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

5. Далее в дело вступают уже все разработчики. Цель на этом этапе – сделать так, чтобы весь код без ошибок собирался под Linux. Как только кто-то из разработчиков заканчивает портирование очередного модуля, он сразу делает так, чтобы успешное компилирование этого модуля под Linux было зафиксировано с помощью тестирования. С этого момента не получится влить в этот модуль правки, специфичные для Windows (если только они не будут «спрятаны» под специальные директивы, исключающие эти правки из компиляции под Linux). При попытке влить Windows-специфичный код, не экранированный соответствующими директивами, будет падать тестирование линуксовой сборки. В какой-то момент все модули будут успешно компилироваться под обе операционные системы, и тогда можно уже будет заняться линковкой (linking) под Linux. Как только удастся довести её до ума, этот результат также будет зафиксирован с помощью тестирования, и с этого момента всё приложение всегда будет успешно собираться под Linux.

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

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

• начинать работу над стабильностью следует усилиями одного или двух тестировщиков, потому что при запусках на разных входных данных ошибки всё равно поначалу будут одни и те же. (Ошибки инициализации, ошибки при считывании и обработке входных данных и пр.) Привлекать большее количество людей на этом этапе нет смысла, потому что тогда они будут делать дублирующую работу по разбору и описанию одних и тех же багов;

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

Выше я сказал, что портирование даже очень больших приложений – задача относительно простая и прямолинейная. Здесь я немного слукавил. Это не всегда так. Ну, то есть сам процесс портирования довольно прямолинейный, но на пути к конечному результату могут вскрываться довольно серьёзные проблемы. И некоторые из этих проблем будут требовать решения здесь и сейчас. Как правило, эти проблемы не имеют отношения именно к портированию. Они существовали и до него; и могли вскрыться каким-нибудь другим образом; но именно в процессе портирования впервые вылезли на поверхность. Такие «сюрпризы» – довольно обычное дело для масштабных инфраструктурных проектов. Приведу пару примеров из собственного опыта. Так как это уже не основная тема, а скорее, «байки в тему», то убираю их под спойлеры.

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

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

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

На этом пока всё. Всем эффективных управленцев! 😁

Ссылки на предыдущие «записки»:
Записки архитектора. Как давать имена приложениям и сервисам
Записки архитектора. Чек-лист