Статья, которую Вы видите, была создана на основе анализа типичных заблуждений, очень распространённых у разработчиков программного обеспечения и их начальников. В русскоязычном Интернете почти нет ресурсов, где эта тема бы бы затронута достаточно глубоко, что и подвигло меня на её создание. Я пытаюсь обобщить свой почти 20-летний опыт разработчика, руководителя проектов и директора по ИТ на конкретных примерах. Возможно, Вы найдёте для себя что-то полезное.

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

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

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

Рассмотрим основные типы компаний, занимающихся разработкой программного обеспечения:

• Производитель оборудования.

Как правило, такая компания не продаёт своё программное обеспечение, так как оно не имеет самостоятельной рыночной ниши. Обычно, это ПО необходимо для работы с конкретным "железом". Очень часто отношение к такому ПО формируется как к бесплатному, отсутствуют планы развития, а ресурсы выделяются по остаточному принципу. Типичным является мнение, что не стоит вкладываться в то, что не продаётся и не приносит дохода. Как это часто случается, данное мнение ошибочно и подобный подход способен свести на нет все конкурентные преимущества самого изделия. Необходимо помнить, что ПО (в том числе и ПО верхнего уровня), фактически входит в состав изделия. В сложных изделиях (промышленные контроллеры, автоматизированные линии и т.д.) себестоимость ПО обычно соизмерима со стоимостью материальных объектов, а при мелкосерийном производстве - часто превышает её. Мне доводилось иметь дело с людьми, которые с энтузиазмом приступали к задаче замены в серийном изделии транзистора по цене 30 центов на аналогичный за 25, но при этом были совершенно равнодушны к сокращению трудозатрат на разработку ПО. А ведь затраты на любые модификации сложного программного комплекса обычно составляют не менее 70 центов за одну строку текста программы даже по российским ценам. К сожалению, такая ограниченность в мышлении встречается очень часто.
• Системный интегратор.

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

Этот тип можно было бы назвать "настоящими профессионалами", если бы не несколько опасных иллюзий, которые нередко являются фатальными:
• "клиент всегда прав", нужно делать то, что он хочет;

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

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

Как правило, инфраструктура заказчика имеет, с позволения сказать, особенности. А точнее - грубые ошибки, особенно если это касается его внутренней сети. Отсутствие требований вынудит Вас использовать только самые простые и примитивные технологии и инструменты. Это вызовет неоправданное увеличение стоимости разработки. Мне известна компания, которая в 2002-м году в новом(!) проекте ориентировалась на поддержку всей 32-битной линейки Windows, то есть даже Windows 95. К их чести, задуманное они выполнили, но к моменту выхода продукта Windows 95 окончательно сошла со сцены и огромное количество ухищрений разработчиков было затрачено впустую. Налицо ошибка менеджера, не захотевшего терять 5% рынка и тем самым усложнившего задачу в полтора раза. К счастью, компания не разорилась, но упущенную прибыль из-за затягивания сроков им никто не вернёт.
• нельзя накладывать требований к квалификации пользователей.

Любое изделие, в том числе программное, должно быть по возможности простым в использовании. К этому нужно стремиться, но минимальные требования к квалификации должны быть. Если этого не делать и не отметить в документации, то за замечательным в техническом отношении изделии может утвердиться репутация "глюкала". И обвинять в своих бедах будут не "криворукого" администратора или пользователя, а разработчика. И всё только лишь потому, что "своя рубашка ближе" и "бревно в глазу" никогда не мешает. Этот психологический момент нужно обязательно учитывать и, если есть такая возможность, то проводить обучение и сертификацию специалистов заказчика. Если такой возможности нет, нужно обязательно иметь средство протоколирования действий персонала, это даст возможность "ткнуть носом" заказчика при конфликтной ситуации на "разборе полётов".
• нельзя применять технологически сложных решений.

Часто руководитель компании в той или иной форме боится применять какие-то технические решения только лишь из-за того, основная часть сотрудников данными инструментами не владеет. Логика проста: сложные решения не позволят в дальнейшем использовать дешёвую рабочую силу. А если "умственно умный" разработчик ещё и в единственном экземпляре, то решение в 90% случаев будет не в пользу новых технологий. Я никак не могу комментировать данную ситуацию, но такой подход во многом и объясняет, почему хороших программных продуктов отечественного производства практически нет. Руководитель в этом случае не подтягивает "болото" под лидера, а топит его до уровня воды. Если Вы руководитель - не делайте так. Если Вы разработчик - увольняйтесь сегодня же ни на минуту не задумываясь.
• Windows Must Die!

Есть такие люди, в бедах которых всегда кто-то виноват. Обычно это происходит до определённого возраста, но случается, что подобное отношение к миру сохраняется до весьма серьезного возраста. Мне неоднократно доводилось пообщаться с такими деятелями: по их логике, если их проект был на Windows, то во всех его бедах был виноват Билл Гейтс. Мне так и видится как злокозненный миллиардер лично устраивает системе утечки памяти и указателей, а также вместе с подельниками мешает правильной синхронизации потоков ;-) В 99.99% всех случаев Гейтс тут, конечно, не при чём. Просто руки разработчиков "растут не оттуда". Эти ребята способны доказывать с пеной у рта по несколько часов, что "это - ошибка в MFC" или "механизм передачи сообщений в win32 работает совершенно неправильно". При этом приводятся аргументы "а вот в Linux" или "MacOS", или "SUN Solaris" в зависимости от личных предпочтений... Никогда не обращайте на это внимания, эти ребята - религиозные фундаменталисты. Никакие аргументы на них не подействуют, случай явно клинический и тут нужен доктор. Однако, иногда им удаётся убедить руководство в том, что виноват производить их компилятора или операционной системы. Такую фирму мне даже не бывает жалко :-)
Приведу свежий пример: в одной компании разрабатывали программно-аппаратный измерительный комплекс на C++ под Windows. Разработчики рвали на голове волосы, что в ядре win32 портится стек, пропадают сообщения GDI, а с загрузкой динамических библиотек и вовсе беда. То есть, налицо были происки вредителей от Microsoft и лично Гейтса.
В конце концов, ребята получили "добро" на переписывание всего проекта под Linux. Прошло полгода, а результатов нет - в тех модулях, которые уже успели сделать, память и иные ресурсы продолжают утекать с тем же энтузиазмом, как и на Windows. Не сомневайтесь - виноват будет по-прежнему Билл Гейтс, какую бы платформу для очередной переделки они не избрали ;-).

Как же рассчитать экономическую целесообразность и экономический эффект, особенно если программное обеспечение непосредственно товаром не является? Алгоритм расчёта несложен: возьмите любой проект сопоставимой сложности и трудозатратам из числа уже выполненных. Для него вы можете полностью посчитать по факту затраты предприятия. Грубо можно заработную плату всех задействованных сотрудников умножить на два за весь период создания и развития проекта. Далее вам понадобится прототип с использованием того самого нового подхода, который вам предстоит обсчитать. Обычно прототип представляет собой одну или несколько подсистем, функционально эквивалентных старым, но с переработанным (или написанным заново) кодом и внутренним наполнением. После этого несложно вычислить коэффициент как отношение количества строк в старой подсистеме к количеству строк в прототипе. Всё! Ваша задача решена, точность оценки вполне достаточна для оценки экономического эффекта и беседы с финансистом.
Из моего личного опыта, получаемый коэффициент очень близок к истине. Так в 2008 году я функционально повторил и даже перекрыл по возможностям систему верхнего уровня для нефтедобычи, состоящую из более 140 тысяч строк кода на C++. После глубокого реинжиниринга там осталось только 38 тысяч, коэффициент =3.68. Примерно во столько же раз теперь отличается трудоёмкость сопровождения этого комплекса, которая ранее вызывала слабость в коленях и дурные сновидения ;-) Теперь это любые изменения делаются играючи.

Необходимо отдельно остановиться на такой скользкой теме, как документация. Данная тема является традиционно больной для всей ИТ-индустрии, а не только разработки ПО. В 90% компаний документации либо нет совсем, либо лучше бы её не было. Это вполне объяснимо т.к. разработка хорошей документации по друдоёмкости сопоставима с разработкой программного продукта. Да ещё ведь за актуальностью документации надо постоянно следить, иначе пользы от неё не будет никакой. Конечно, всегда находится немало желающих на этом экономить, а результатом обычно является потеря управляемости проекта в самый неподходящий момент. Самое время привести критерии, когда без документации обойтись можно:

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

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

Не секрет, что любую идею можно довести до абсурда. Нередко к этому приводят внутренние принципы оплаты труда в компании. Например, нет ничего абсурднее требования чтобы "комментарии составляли не менее 40% текста программы" или "все используемые переменные должны быть описаны в заголовке файла". Как правило, к таким требованиям все относятся формально и пользы делу это не приносит. Мне как-то в руки попадал фрагмент кода одной крупной системы, разработчикам которой платили за написанные ими строки кода. Мало того, что весь исходник был искусственно раздут, так ещё в нём встречались блоки, куда управление заведомо никогда попасть не может ;-). Видимо, кто-то очень хотел срубить побольше денег и таким образом повышал свою "производительность труда". А теперь представьте себе, что Вам лет через 10-15 нужно что-то изменить в такой системе? Каково будет разбираться в той куче мусора, которая была "для денег"?!

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

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

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

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

© Пчелинцев А.В. 2009-2011. Использование материалов допускается только с разрешения автора.